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.
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.
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.
I disagree. Apple needs to improve their support for PWAs, so that PWABuilder becomes obsolete.
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.
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)?
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.
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.
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.
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.
> 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.
Now, with installation of PWAs, it'll become the same as the "apps" of old, just without a store in between.
PWA manifests etc
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.
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.