https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...
The HTML5 version is compiled from the same source that the App that goes to the Apple App Store (https://itunes.apple.com/us/app/papa-pear-saga/id572542612?m...).
What's so different? It is literally the same code base (minus some platform specific code).
It's tough to get developers to care about things like offline-first, because it's tough for them to convince managers to allow them to spend time on a feature that won't work on iOS (since it won't work in Safari, and Apple has banned other browser engines on their platform).
Ultimately it's users that lose out but also the web as a platform, as it pushes people, like the author of the article, towards walled-garden solutions like native apps.
Apple is looking for service worker use-cases, so if it's something you're interested in, let them know https://lists.webkit.org/pipermail/webkit-dev/2017-July/0292....
According to this, Facebook was 32 MBs 4 years ago. It's similar with Twitter.
It's their fault that they keep adding stuff to track you. And Facebook contains just about every library that has ever existed now.
It's used in a lot more than just hobby projects.
>Sixth, the most important reason.
Besides the fact that Flash is closed and proprietary, has major technical drawbacks, and doesn’t support touch based devices, there is an even more important reason we do not allow Flash on iPhones, iPods and iPads. We have discussed the downsides of using Flash to play video and interactive content from websites, but Adobe also wants developers to adopt Flash to create apps that run on our mobile devices.
We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.
This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.
Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.
Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.
Technically Apple does support offline via the older manifests mechanism (and "Add to Home Screen" which invokes it remains prominent in the safari share sheet) though it's a lousy (and pretty buggy) experience.
Interestingly they don't support any sort of web notifications on iOS despite having added local notifications ( https://www.w3.org/TR/notifications/) in macOS 10.8 and remote Safari Push Notifications (built on APNS) in macOS 10.9.
Safari should support Service Workers[1], because they allow you to safely intercept and modify navigation and resource requests, and cache resources in a very granular fashion, securely and on a different thread to your app JS. This is great for performance and offline/spotty reception.
The Web App Manifest[2] is the file that allows developers to "appify" the site, by prompting the user to add to their home screen (only once they hit a certain usage rate), show a splash screen etc. But that's a nice to have compared to Service Workers.
[1]: https://developer.mozilla.org/en/docs/Web/API/Service_Worker...
The overall vibes leaking from the Safari team on this matter have been arrogant, detached. I don't hold any hope.
Twitter's native app is heavier than their web app because Twitter has historically filled the native app with junk (like a fullscreen video just for the login screen, "moments", "highlights", hijacking browser URLs, a bunch of ads and ad tracking, etc). Facebook does the same, to an almost silly degree - https://news.ycombinator.com/item?id=8162342
The Twitter client could easily be ~3MB on Android, for instance, if they just stripped the garbage out. And similarly, if you take a web app, and embed all that same junk into it, it will suddenly be a heavy download too.
If native web apps are to be more of a universal thing, I believe there ought to be a blank-canvas "meta-browser" layer that sits above the browser and that all web apps (including today's browsers) are built on top of. Basically a lightweight, sandboxed pseudo-OS that offers a robust standard library, a URL scheme and easy networking support, some sort of bytecode, maybe a UI toolkit, etc. Web apps would still take up the same amount of space and would still be able to run without installing, but they would now be endowed with native performance, app-specific features, and a consistent, functional UI. (Quiz: how often do your back/forward buttons fail when using, for example, your bank's website? The fact that these two ubiquitous controls simply break the web more often than not should be telling.)
Shoehorning all that stuff into a hyperlinked, navigable document browser is insanity, and you can always feel it unless your web-app has basically reimplemented the DOM from scratch[1]. The web is currently layered upside-down and I think web apps won't lose their reputation until this is fixed.
Similarly Facebook is just fine without the app and I'm happy with it. It has notifications etc. I'd like it if it was offline first but I'm more than happy with it as is.
Part of that though is because they _don't_ allow PWAs. Contrast that with Android, where it's now entirely possible to make a PWA so deeply integrated into the OS that the average user can't even tell it's not a native app: https://blog.chromium.org/2017/02/integrating-progressive-we...
I suppose this is a compatible idea, but the PWA idea is based on everything going in the wrong direction generally. PWA aims to make everything "app" like even when it's not warranted. The vast majority of apps and PWAs don't need to exist at all. People don't need all this JavaScript interactive excess.
What I like about PWAs: a move away from everyone downloading ridiculous numbers of apps for each website. What I don't like about PWAs: turning websites into apps when not needed.
A11y is also being taken seriously.
https://webkit.org/blog/3709/using-the-system-font-in-web-co...
...and even if you get pixel-perfect between android and ios, you sacrifice "cultural-correctness" (ie: floating buttons v. top bar v. bottom bar, etc.).
Writing two pixel+cultural perfect apps on two platforms, keeping them in sync, making sure they're not buggy, attempting to share code, attempting to keep them both secure is incredibly expensive. If you don't believe me then do it yourself.
Making a PWA which gets 90% of the way there, and integrates as well as possible with the system (ie: fonts, location, notifications, accelerometer, etc.) is generally _less_ expensive than doing a single native app well, and has the chance to get you 90% of the way there on desktop and your "alternate" mobile platform.
PWA can be incredibly powerful (along w/ manifest.json-style support as android has), and I'm waiting for the day apple catches up to android on this one.
Further, the majority of US smartphone users download zero apps in a typical month. What's the point of making a "superior" app, if no one is ever going to see it? https://qz.com/253618/most-smartphone-users-download-zero-ap...
From a user perspective, I care less about whether the app is a PWA or native, and more about the "goal" I'm trying to achieve. If my goal is to find a new house, a PWA allows me to instantly see results (without first having to download an app), then use native-like features such as being notified when new properties are available. I can use these features after I visit a given website and am prompted to save the app to my homescreen.
Compare this to the random native apps that people accumulate on their phone until it slows down so much that they have to perform an "app purge".
However, Opera Mini has a “Mini mode”, where the parsing and JavaScript execution is done on Opera's server, which then compresses the data and sends it to the phone for display. In this mode, it does not use the WebKit framework. Opera Mini has been on the App Store since 2010.
https://techcrunch.com/2010/04/12/surprise-surprise-opera-mi...
I wonder if section 2.5.6 applies to apps that display web pages as one function among many, and not to web browsers. Maybe Apple figures that if the user hits a “Web Page” button in some app, they expect it to work just like Safari, but if they download Chrome, Firefox, or Opera Mini, they actually want the web browser to be different from Safari. But I haven't researched this yet.