Publish your PWA to the iOS App Store
blog.pwabuilder.com
blog.pwabuilder.com
If you get lucky and get a lenient app reviewer, you might be able to sneak a PWA onto the App Store this way, but even if you do get approved, you're just as likely to get rejected when submitting a bug fix or compatibility update. (This has happened to me a number of times before.)
> 4.2 Minimum Functionality
> Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value or adequate utility, it may not be accepted. Apps that are simply a song or movie should be submitted to the iTunes Store. Apps that are simply a book or game guide should be submitted to the Apple Books Store.
> 4.2.2 Other than catalogs, apps shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.
A "web clipping" is Apple's way of referring to a web site zipped up in a WebView, and that's what rule 4.2.2 explicitly forbids.
Apple has rejected a bunch of PWAs wrapped up in WebViews like this over the years, and when they do, they're normally rejected under 4.2.2. Apple doesn't always notice, but they notice just often enough to make this an unacceptable risk for any app you actually care about.
IMO the big mistake PWA Builder is making here is that (per OP blog post) they do not offer any "iOS-specific integrations."
> Our template doesn’t include support for iOS-specific functionality like Apple Pay, Sign In with Apple, HealthKit, etc.
Those iOS-specific integrations are the only thing that would make these PWAs allowable under rule 4.2. I have gotten PWA games approved by pointing out that they support Game Center, for example.
Overall, I think PWA Builder is off to a good start, but they need a lot more work to be viable.
Their argument basically went like this: Your app is clearly a web clipping. It's just your web site wrapped up as an app. We can see your web site, it works fine, and this app adds no additional value to the web site. You need to add features to your app--iOS-specific features--to make it worthy of being in the App Store.
I think it's fair to say that you can interpret rule 4.2 (and especially 4.2.2, which doesn't define a "web clipping" in the guidelines) in a few different ways, and that the "strict" App Store reviewers I faced were being perfectly reasonable in their interpretation of rule 4.2.
(To be clear, I think rule 4.2 is not a good rule, but I think the individual reviewers I spoke with were making a reasonable attempt to interpret rule 4.2.)
The "strict" interpretation is reasonable, but your interpretation (which I would call a "lax" interpretation) is also reasonable. You could say "well, if the web site is app-like--if the app has good, useful features--then it has more than minimal functionality and is worthy of being in the store." Both interpretations make sense.
The problem occurs when you stake your deployment strategy on the hope that you don't get a hardline App Store reviewer, and now, all of a sudden, you can't push bug fixes or compatibility updates to your iOS app, and your users are pissed.
Still an incredibly dumb rule.
From an outside perspective it seems a fairly hard rule to enforce though. If you packaged gmails web interface up in to an app Id say that has a lot more utility than a flashlight app.
The AppStore review operates on a spirit-of-the-law basis, instead of the letter-of-the-law.
There's no such thing as PWA or PWA support. It's several dozen different standards of varying quality and usefulness. And people randomly chose arbitrary selections of those standards and claim that this selection is a true PWA support.
Thank god Safari doesn't allow notifications and it should continue not allowing them.
Apple's Appstore rules forbid push-notification for marketing/advertising, and I get way less useless notifications by default on iOS. On Android, I often get notifications from major Appmakers in the sort of "We haven't seen you for a while, checkout what you miss in our App!" or "There is a competition in our App, take part and win a free XXX). Yes, you can disable notifications as a whole for an App, but that would also disable those notification that I want to receive and are essential.
If you would allow PWAs installed from outside the Appstore to send push-notifications, major 3rd party app makers would abuse that as means to "increase engagement" (their marketing lingo for spam) with their users.
Furthermore, I think the motivating assumption behind the rule is that "repackaged websites" are different than (and worse than) "real" iOS apps. Thus, if your iOS app is a repackaged website, then it's not good enough for the App Store.
But I just don't share that belief. It turns out that websites can be pretty good nowadays! A "repackaged website" can just as good as an iOS app implemented in Swift.
Still, good luck convincing an App Store reviewer of any of that! As long as your app is, literally, a repackaged website, I really can't imagine how you'd argue your way out of a rejection.
In the long run, you're guaranteed to be rejected at some point if you're repackaging a website, and at that point, you're basically screwed.
The rule reads
> If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store.
It's not necessarily that a website is worse than an app, but it's the fact that a website is not an app (even if you give it a name like PWA). Not an app --> doesn't belong on the app store.
I disagree. Apple needs to improve their support for PWAs, so that PWABuilder becomes obsolete.
With one of my current contract, we have 2 people coding and ended up having to create a separate iOS app because there is no Notification support. We abandoned our proof-of-concept PWA because we had like 10% Android users and putting in the maintenance effort was not worth it. Without Android support, after a few months all Android users decided to ‘upgrade’ their phones to iOS devices.
Is the the future we want? Do we want to be forced into walled gardens and implicitly guiding users into it? If your team is small should you be forced into one specific platform or should your mostly-CRUD app be viably built for a cross-platform solution like PWAs which covers the major platforms and the niche ones like Linux phones.
Do I want a future with crummy PWAs instead of applications when appropriate? I want that about as much as I want Electron apps.
Now, with installation of PWAs, it'll become the same as the "apps" of old, just without a store in between.
PWA manifests etc
> Every website without fail that ever wanted me to allow push notifications did it just so they could spam me.
I think this is mostly due to iOS/Safari not supporting notifications. The more serious actors who want to provide actual value to the users have been strong armed by Apple to create a native mobile app. Conversely, if the only browser allowed on iOS actually supported push notifications, you would see more legitimate prompts for using the tech.
The typical non game application is mostly just a front end to services where there is no money being directly charged through the website/app anyway.
It came out in the Epic Trial that 70-80% of App Store revenue comes from games. Those would never be PWAs anyway.
I’ve never seen anyone explain to me why, as an iOS user, this is a good thing of preferable to a native app.
I’ve seen lots of pro-developer arguments. And anti-Apple’s tight control arguments.
But no one has ever explained to me why as a user I should want a PWA that isn’t some form of the arguments above.
I have an app like that... I make it by myself, and I have no desire to make 5 different GUIs. And yet thousands of people on iOS use it as a PWA. That seems pretty pro-user.
The downside is, my app performs worse in Safari than any other browser, so these iOS folks with high end iPhones are getting about the same experience as Android users with $100 phones. I bet I would have even more iOS users if Apple let them use a better web browser :)
Many of us hate iOS, Apple's taxation, and Apple's asinine rules with a burning passion. But we have no choice but to develop for the OS that 50% of Americans choose. It sucks.
It's as if AOL won and we had to build what Time Warner wanted and had to pay 30% of our revenues.
It's as if we're living in a Steve Baller hellscape, but everyone worships it because it was from the other Steve.
The modern tech ecosystem sucks.
Developers and their time matters more for the above since they're a smaller, minority population whose services are disproportionately necessary as opposed to users (who are more replaceable).
From purely a self-centered user's point of view, it doesn't matter, and might even be a negative since they don't get Apple's high-touch review. But it's not like Apple cares all that much about the opinions or user experience of the user either. One positive I can think of is more diversity and availability, there are just many more PWAs available. Another is time saved - if a user can start using your PWA in a couple seconds instead of painfully installing the app over a minute, then over a billion users you've saved very significant time.
I would even argue this sort of time saving might cause "natural" selection.
Then you want native apps, not websites.
It's significantly more efficient for the end user: fewer resources consumed on a few billion devices vs. a few dozen devs building separate apps.
Ah yes, the elusive unicorn of a "well built basic app"
> web app also grants significantly more consumer freedom of choice.
Literally nothing in this conversation up to this point mentioned consumer freedom and choice.
What about consumer freedom and choice not to approach the heat death of universe through the use of websites-as-apps (on of the most inefficient ways to make apps)?
Picture a maybe-for-legal-reasons-theoretical app that needs to be supported on android and iOS plus would massively benefit from the ability to preview the mobile app in a supporting Web portal.
PWA gives us :
- A unified codebase across 2 apps and a Web portal (same project produces the ios, Android and web builds, reuse of css styles, UI components etc)
- Significant reduction in effort developing and maintaining 3ish separate codebases for the same functionality (not quite 3x reduction, there are platform specific issues you have to resolve but still really great).
- Way easier time resourcing the project, one skillet for the 3 frontends and the team can swarm to the required work (This was amazing in the current high demand market)
- Access to the huge array of existing libraries and UI components
For larger more established companies then sure go native. But for companies that have to efficiently use capital, any money spent basically building the same thing twice is money not invested in further understanding the user's needs and improving their experience.
Isn't this just a definition that agrees with useful PWAs? Offline support using service workers and client side storage, notifications, mobile first ui, etc.
we didn't go the PWA way (because of app store), but something quite similar to the article
1. we have a symfony website with simple web pages but with a "app look" (yes no react , no api, like it's the 2000s all over again)
2. we have a think react native wrapper (at first 17 lines, no it's 90s as we support push notification, hardware back button etc.) that embed a react-native webview
so we have nearly no javascript, just modern css and we pay really attention to performance and it's a dream
1. no javascript removes a lot of hassle
2. no api removes a lot of hassle too
3. html+css and we support all platforms, so a good design and backend engineers is all you need
we're live for a year, have raised money and have customers. We've been through several store update (to keep react native up to date and put some changelog).
I call it "retrogressive-app"
I’ve recently started a project with just html/css and vanilla JS on the front end - no react etc and it’s very nice
I'd love to read more about your stack, so of you do a blog post, please let us know :)
Would love to see a video of your app in action, too!
Does this include in low-connectivity environments? The biggest advantage of api-driven PWAs is that it supports no-connectivity and low-connectivity nicely, assuming you put effort into enabling it (having an offline cache of data) and having loading indicators visible to the user. With a regular page-load-driven application, if i'm on 1 bar of 4G I might get the TTFB for a page load and then be waiting as page assets slowly load in, staring at a white or half-blank screen the entire time.
While most SPA will put you on a weird state (of course you can handle it nicely too, but it requires effort for something you had for free in the first)
1. html of that page, they never go over 30kb non gzipped, most svg assets are inline, so once you got it, you got it.
2. the tailwind.css file, that is cached after the first page.
so even if you feel fancy and you use graphql, you can't do less 1 http call right ?
Also see https://twitter.com/dhh/status/1254870450464686080?lang=en
Please consider a blog post with more details or even open source some of your stack (especially the react-native bits). Like others users here, I'm also very interested in your "retrogressive" approach!
Whether your webview app will get published in the app store depends on how "app-like" your PWA looks and if you get a strict app reviewer.
I instead add native components to the apps I create to make sure they look more like an app, which works well to get the app approved by Apple.
From my experience, push notifications are a very important feature too, almost all of my customers want that. I haven't found a way to reroute browser notifications to the app, so instead I use firebase to let my customers send notifications.
Seems Firebase is the way a lot of folks are achieving Push Notifications on iOS.
Yea, Firebase is pretty nice because you can use it on both Android and iOS and it's free :)
Would really like to get something like this as a proof of concept for our clients who just love mobile.
I'll get back to your co-worker shortly with a more detailed response tailored to your website!
I agree, but I also think that most of your customers don't want useless marketing/advertising push-notifications from your App. Based on my experiences, almost all larger 3rd party app makers will abuse push notifications for this at some point. An example would be Tinder, which sends you a notification like "There is someone new who likes you" and if you then check you learn that you can't actually do anything with that information, because that feature is only available to paying customers (but you will get the notification if you are a free user anyways). This is a clear sales/marketing dark pattern that users usually don't want.
From what I'm seeing my customers treat push notifications very responsibly and their app users love the feature :)
Receiving notifications while having them disabled is weird - I haven't had that happen to me yet luckily.
Capacitor supports notifications and would be more extendable going forward I think. Although maybe more work upfront?
Capacitor aims to give expose native functionality via runtimes and plugins. A kind of mixed web/native hybrid.
PWABuilder's aim is more limited in scope: to make PWAs great on iOS. We are not so much concerned about exposing native functionality, and more concerned about making PWA functionality work everywhere.
We address some of this in our iOS FAQs: https://blog.pwabuilder.com/docs/ios-faq
PWABuilder's goal is more limited in scope: take your existing PWA, no changes, and publish to app stores.
For some folks, Capacitor will be the right answer. But we think there's value in making PWAs as-is run well on iOS.
I am going to chat w/ Judah about this, already have a convo on github
I had strong negative experiences/opinions, all the way up until Capacitor. It's good tech and an undervalued option when compared to React Native.
Source: Have built mobile apps with PhoneGap, React Native, NativeScript, and Android.
I'm not a fan of React Native -- though my last experiences with it were many years ago so I'm sure much has changed.
Also I don't think most "native apps" need to be native apps. They want a place on the homescreen usually, not use of underlying hardware API's like accelerometers.
Most "native apps" should really be installable PWA's or using something like Capacitor IMO.
Would you mind sharing the app links and any documentation / blog posts to make the app efficient and approval process smooth.
My goal is to create a simple kids app that can be monetized via monthly subscription. I can build a traditional website, but don't have much clue on the easiest way to also publish it as an app (both for iOS and Android). Any recommendation on how to go about it if my skill is web development?
In the meantime, if you really need it, have a look at this project: https://github.com/khmyznikov/ios-pwa-wrap
It's a iOS PWA template that uses push notifications via Firebase.
We work with Google -- and even sync with them monthly -- on this platform. They are very cooperative and helpful.
And, PWAs published to Google Play can do push notifications and anything else PWAs normally do, using just standards-based code.
Google and Mozilla have supported the web push API for going on 6 to 7+ years now.
https://9to5google.com/2021/10/10/google-ios-apps-native/
Facebook realized years ago that true native apps and not a web wrapper was a better user experience.
Given the choice, I'd use Facebook messenger in my phone's web browser but they block it.
I don't agree that a native app is a better experience, as it gives less control to me the user.
Maybe it's a better experience for product managers who want to increase my engagement and collect as much information on me as possible.
[0] Ask someone who worked with computers in the late 90s and 2000s if you don't get the reference.
Capacitor can be added to an existing web app codebase and acts as a library with cross-platform APIs for functionality like Camera/etc and that would be compiled/linked into your app like any JS library. But it can also be used to wrap an externally hosted app by changing the server.url config value https://capacitorjs.com/docs/config
We provide push notifications along with a few more important things that you'd need to wrap your web-app with.
Full disclosure: I'm its founder and you can reach me on marvin@goose.red.
(If you reply to this thread, insisting that your customers don’t care, please tell us what your app is and how what value it provides customers that exceeds the website’s functionality.)
As a result of using native tech, I can offer a lot of very cool stuff, but I do know that many customers are fine with a far scruffier UX.
They just won’t get it from me.
I've learned not to slag others. I've learned not to say something like "X is bad," and, instead say "I don't like X, for myself, and here's why..."
A few posts ago, I said something about X Windows that wasn't really a put-down, but was not complimentary, and that was interpreted as a slag. Some of this stuff is really not worth the increased heart rate to argue about.
Apple tends to bring out the beast in people. We have some very strong feelings and opinions about it.
I do feel like my own approach to Apple is fairly balanced. I've had a lot of time to have the rough bits worn off.
Why should Apple invest in supporting Vulkan, exactly?
If they aren't going to make Metal available on other, non-Apple systems, they should make Vulkan available at least. If they want to attract more cross-platform software, they need to start supporting better dev tooling. If Vulkan was available for Macs, most devs could simply set their build for ARMv8, target MacOS and compile their apps the same way they do for Windows, Linux, PS5, Xbox, Switch, Android, and even WASM. As it stands though, maintaining a separate codebase for a fraction of your users isn't very viable from a developer's perspective, which becomes glaringly obvious when you look out on the seemingly infinite graveyard of depreciated MacOS apps and games.
It makes all the difference
> Apple has the resources to support two graphics APIs at once
Why should they?
> The game performance through MoltenVK says it all, really: perfectly powerful GPUs get imposed a 50-75% performance penalty when translating to Metal, which is pretty slow compared to similar systems
Why should Apple care? Their systems are selling like hot cakes, outpacing everyone.
> If they aren't going to make Metal available on other, non-Apple systems, they should make Vulkan available at least.
Once again, why should they?
> If they want to attract more cross-platform software, they need to start supporting better dev tooling.
I think they've been quite clear that they don't want more cross-platfrom software.
> from a developer's perspective, which becomes glaringly obvious when you look out on the seemingly infinite graveyard of depreciated MacOS apps and games.
The lack of games has always been the case, even when OpenGL was the only way to make gaming graphics on MacOS. Apple has never care about gaming on their desktops and laptops. And gaming is doing just fine on the iPhone.
The missing value is offline access to whatever data you need at the moment, for example your schedule for a conference - the cellular networks failing at large events due to overcrowding are common.
When you can run many apps directly from the browser why do I need write everything as an iOS app.
It's a shame that Apple is the only big player that does not even want to support PWA. Apple is truly a closed ecosystem for pure greed.
Or maybe you mean Apple doesn't support some standard that you randomly decided is a must for PWA?
Sigh.
Safari: is more-or-less on par with Firefox in the number of web apis shipped Firefox continuously takes a stance together with Safari against Chrome behaviour.
Web devs: why is Apple killing the web?
If it looks like a native app, and feels close to a native app.. it sounds like Apple lets it slide? Has anybody had experience publishing a b2b webview-wrapped-spa on the app store?
(and ofc, the risk of false negatives is present)
PWAs can alleviate the need to build 4 separate apps:
- Web app - Android app - iOS app - Windows app
With PWAs, you can build a Progressive Web App, and publish it everywhere. We recognize that this doesn't work for every scenario -- maybe you need to use some non-standard proprietary technology for instance -- but for a majority of apps, it works well and saves you development costs.
"Native" apps often bring their own file picker and their own camera control for no good reason.
Web apps use the native versions.
It's easy to run multiple instances of a web app simultaneously (maybe you need multiple logins or to refer back and forth between different screens). That functionality is likely missing in the native app.
Smoldesu is mad that Apple will not support Vulkan. Apple is pretty clear about wanting people to use Metal, their own 3D API so I think expecting them to support anything else is optimistic. Personally I am still using OpenGL on Mac and iOS, same code works fine on both. OpenGL is deprecated but still works great, plenty fast enough for my one 3D app, FlagWaver (Mac/iOS).
What do they think this is this, the future? The technical challenge is simply too great for Apple, they'll be lucky if it shows up on the 2027 Macbook Pro redesign!