Apple’s refusal to support Progressive Web Apps is a detriment to the future of the web
UPDATE: March 30th, 2018 — Service Workers shipped in Safari for iOS!
About 8 months after I published this, Apple finally shipped service workers for safari/webkit.
UPDATE: August 3rd, 2017
I almost can’t believe it, but it looks like this article may have actually helped things along: (https://bugs.webkit.org/attachment.cgi?id=317095&action=prettypatch)
Thank you to everyone who recommended this and shared on twitter — especially Alex Russell, for the original tweet that set this thing off.
This is an amazing sign, but it still doesn’t guarantee anything. There’s still no way to know if and when Apple will ship certain features in mobile Safari.
Original Article: July 24th, 2017
Progressive Web Applications (PWAs) are one of the most exciting and innovative things happening in web development right now. PWA’s enable you to use JavaScript to create a “service worker”, which gives you all sorts of great features that you’d normally associate with native apps, like push notifications, offline support, and app loading screens — but on the web! Awesome.
Except for one major problem — While Google has embraced the technology and added support for it in Chrome for Android, Apple has abstained from adding support to mobile Safari. All they’ve done is say that it is “Under Consideration.” Seemingly no discussion about it whatsoever.
I’ve been waiting for them to come around on their stance behind PWA’s, but so far, it just hasn’t happened. Since life is short, I’ve been learning React Native in the mean time. More on this later.
Why Native Apps are … Doomed?!
Yesterday I came across a particularly bold and outspoken article. In it, the author states:
“From now on, I won’t be building any more native apps. All my apps going forward will be progressive web apps. Progressive web apps are web applications which are designed to work even more seamlessly on mobile devices than native mobile apps.”
Immediately I thought, “How could he make such a bold statement when they don’t work on iOS, and may never work on iOS?” I mean, I’d LOVE to join him on that journey. What a grand world that would be — but it is simply not a realistic one.
That’s a high number, but only if you’re making apps for the global market — which I’m not, and which most people in the U.S. are probably not. And that number is probably fairly skewed because of countries with high populations or a higher rate of poverty.
The latest app I developed was for a large medical nonprofit which serves hundreds of thousands of doctors. When we polled them, we found that ~80% of them use iOS, and something like ~45% of them said that offline support would be useful to them since they don’t have reliable wireless connections in their office. I would have loved to make a PWA, but it just wasn’t feasible with those numbers — so we went with React Native (which turned out to be an amazing decision).
Google’s PWA Baseline is a Joke
I also recently came across a stack overflow post which was also trying to make the claim that Apple’s non-inclusion isn’t so bad. The author argued that Google has established a list of baseline PWA requirements, and that many of these are actually possible with mobile Safari:
- Site is served over HTTPS
- Pages are responsive on tablets & mobile devices
- The start URL loads while offline (can’t do this on iOS)
- Metadata provided for Add to Home screen
- First load fast even on 3G
- Site works cross-browser
- Page transitions don’t feel like they block on the network
- Each page has a URL
Seriously? This is not what should define a Progressive Web Application. This is what defines a standard responsive web application, which has been possible for quite some time.
Service workers are what allow you to do all the awesome and exciting things that PWA’s represent. Mobile Safari’s lack of support for them effectively kills the ability for PWA’s to work for half of all U.S. users — which in turn kills their feasibility as a whole.
Here are a list of things you still can’t do with mobile safari due to Apple’s refusal to support them:
- Create an app loading screen
- Use push notifications
- Add offline support
- Create an initial app UI to load instantly
- Prompt installation to the home screen through browser-guided dialog
Apple’s ‘Full Screen’ mode is riddled with bugs
I’ve tried pushing the apple ‘native-like’ experience in mobile safari as far as I could — but it has some serious bugs, and Apple just doesn’t care about them. They’ve dismissed my bug reports (marked them as duplicates with no comment months after I opened them) and ignored all of the public developer forum posts about them.
Some of the bugs I’ve found in mobile Safari’s ‘full-screen’ or ‘web app’ mode include:
- The loading screen doesn’t work (regression — close to 18,000 views, no response from Apple).
- Fixed headers flicker (my biggest pet peeve and ultimately why I disabled it on my product)
- The 300ms tap delay that was finally removed from mobile safari was not removed in full-screen mode (no response from Apple)
I’ll never forget spending a good deal of time implementing these features that are clearly documented (and still are), only to finally realize that they actually don’t work at all in later versions of iOS.
Apple’s response in their developer forums? None. Literal radio silence. It’s one of the most frustrating things I have experienced since dealing with early versions of Internet Explorer. And it’s pretty easy to figure out why:
Apple treats web apps like second class citizens because they don’t generate money like native apps in the app store.
Having to explicitly tell your users how to add your app to their home screen is a horrible way to have to go about things. In fact, after doing it a couple times, I stopped, because it makes your app look like a lower quality product.
What about Cordova?
What about it? I’ve personally never been a fan. It feels like a hack to run my app in a webview/native wrapper. I tried learning and using Ionic/Angular, and it just never felt right to me. When I see dev firms that have invested their time in the Ionic ecosystem, part of me feels like they may have hopped on the wrong train (to be fair though, React Native wasn’t an option a few years ago).
And as soon as you introduce a hybrid wrapper, you’ve still got to go through the app store. You’ll still have to play into Apple’s game and pay $100 to get access to the app store, and the 30% tax — but you’re still only running in a webview.
React Native to the Rescue
You do have one other option though, and it is an amazing one, from the engineers at Facebook: React Native.
One of the biggest things you have to do as a developer is decide where you are going to spend your time, and I can’t recommend learning React Native enough. It has already opened up a whole slew of new career opportunities for me and conversations with smart and successful people.
I’ve spent the last 6 months learning and using it for my last client project, and it has been absolutely incredible. Whereas learning Angular felt like I was fighting against the language, React instantly made sense to me. I haven’t had this level of programmer excitement…well, actually, ever — and the community behind it is truly awesome. The navigation is fluid and native-like, and the entire app feels like a real iOS app — because it is one.
But in the end, we launched with less features than we could have if we were able to make a PWA, and only on one platform.
Is the experience arguably better? Probably. But the web is never going to catch up with that attitude. I also wonder if we would be able to reach more people sitting in waiting rooms if they didn’t have to download it.
Apple got what they wanted though: Our $100, and control over the app in the app store.
The Apple Way
Apple thinks you should learn a completely different and more complex programming language (Objective-C/Swift) and maintain a completely separate code base for iOS. This effectively hurts small dev shops, stifles innovation, makes startups much more difficult to get going.
The idea that startups and small dev shops should focus their time learning Apple specific programming languages and ignore (or at best delay) an Android release in order to help their bottom line is ridiculous.
To be clear, even after everything I’ve just vented about — I’m not anti-Apple. I use an iPhone and develop on a MacBook Pro every day. I still consider their hardware as luxury and would never, ever, go back to using a PC/Windows.
And I don’t think most of the people at Apple are sitting around willfully ignoring this— rather:
There are likely a handful of higher ups / board members telling everyone not to spend any time on technologies that don’t align with the app store secret garden revenue model.
Is this just capitalism? Looking out for their own well being? No. Apple is filthy, filthy rich. I’ve yet to see any response from Apple whatsoever, and I doubt that it will happen any time soon. This article isn’t going to change their mind, but I hope that it will encourage discussion on the topic and help spread the word on the current situation.
One thing is for sure though: We can’t just hop on the PWA train and forget about native apps completely. We need to call this what it is — a detriment to the future of the web.
Hey there! I’m Greg, and I build web and mobile apps.
I’m a full-stack software engineer and consultant based in Philadelphia. I love using Ruby on Rails and React Native to build solutions for all types of businesses.
If you’re looking to build a beautiful product for your company, reach out to me at greg@phillydevshop.com, or find out more at www.phillydevshop.com.
