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.
I mean, that's on the developer to actually build the PWA that does those things right? If you build an "app" as a PWA, there's no reason it shouldn't be approved? If you simply wrap a website these rules would apply. There's nothing here that bans PWAs as I read it.
Yeah, well, tell that to the App Store reviewers who rejected my games.
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.
There has always been a clear rule that an app can’t also be equally equivalent to a web site and easily available just as a web site. You have to make a choice that if you wrap your site as an app, and it’s the same, then the web site shouldn’t be accessible via the web browser.
What is said is that if you build something using web tech that is not available online it's fine, what you clearly did is duplicate what is already available on the web.
PWAs are websites, just ones with a lot of functionality, so by the letter of apples rules they are not allowed.
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.
This seems easy to solve given Apple's rejection of PWA support in Safari, just add a feature that doesn't matter much, like an (opt-in!) notification on updates. Safari (and therefore all browsers) on iOS don't support notifications, so you're doing something you couldn't do from the website.
I can actually understand Apples decision here to not allow push notifications on PWAs and would support it for now. I have two smartphones and am a dual user of iOS and Android. The issue with Android apps is the constant stream of unwanted/advertising notifications. Yes, you can configure them for each app and disable notification categories, but I just don't want to mess with that for each and every app (and their Updates which might change categories).
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.
> This seems easy to solve given Apple's rejection of PWA support in Safari
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.
I think you're forgetting an important stakeholder here: humanity. We as a unit need to do things in an efficient way so we can save our limited resources for other, more important things.
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.
It's not more efficient to build equivalent functionality for iOS, macOS, android, windows and several linux distros when a web app could solve the actual problem for all of them and allow users to pick different os'es for different devices.
For a basic app, well built for both platforms there should not be much difference. A web app also grants significantly more consumer freedom of choice.
> For a basic app, well built for both platforms there should not be much difference.
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)?
Because you don't always get a choice. Not all developers have the resources to make special UIs for iOS/Android/Windows/Mac/Linux. Sometimes it's either PWA or nothing. (Well, I know there are other cross platform technologies, but IMHO they're all even worse than PWAs.)
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 :)
We, as technologists, shouldn't have gotten herded like cattle into the abusive iOS ecosystem. It's extortion.
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.
A lot of young companies are hindered by the pain and overhead of developing and supporting multiple native apps (including patching, tracking & resolving separate bugs etc), spending their precious resources on solved problems rather than user-centric things like better understanding the users by rapidly improving the app and getting feedback etc.
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.
I am an iOS and Android dev but I so agree that Safari needs better support for PWAs. App Store apps are dependant on the review teams approving your app (plus the additional delay in the review process of a day or so). Websites don't have this problem and anyone can access pretty much any website without any gatekeeper.
The biggest companies and most performance sensitive application would still be built native. My biggest concern is how a CRUD app from a small company has no way to release a proper PWA on iOS with its handicapped support.
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.
As opposed to being forced to use web apps? Every website without fail that ever wanted me to allow push notifications did it just so they could spam me.
Do I want a future with crummy PWAs instead of applications when appropriate? I want that about as much as I want Electron apps.
Web apps provide stronger sandboxing, and protect the user more. There's a reason that Twitter and Reddit nag you about "installing their app" whenever you visit them in a mobile browser.
> 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 above sounds like it's trying to prevent you from wrapping up purely informational websites, like that for a specific wedding, or a brochure or something (analogous to "simply a song or a movie" vs a general music or movies app). Of course I'm sure individual reviewers will interpret it differently. But I don't think the "spirit of the law" is at odds with PWA Builder.
I think the "spirit of the law" is that the app you submit must "be an iOS app." If you implement the whole thing in Swift, then it's definitely an iOS app. But if your app is a "repackaged website" (which the rules explicitly forbid), then your app is not a "real" iOS app.
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.
> I think the motivating assumption behind the rule is that "repackaged websites" are different than (and worse than) "real" iOS apps.
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.
This is one reason I really hope they end up adopting Capacitor for the iOS and Android output. Capacitor has all those iOS-specific integrations that enable an app to be accepted into the stores, and they'd get all of that for free but could still keep the core PWA-to-native experience the way they want.
> Your app should include features, content, and UI that elevate it beyond a repackaged website.
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.
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.