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.
At rosaly.com we've built our "app" with something similar
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).
" we pay really attention to performance and it's a dream"
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.
Ironically though, phones usually struggle more with single-page apps / Javascript heavy sites which have all the client-side application logic, 3rd party libraries, and DOM re-renders based on state changes.
exactly !
most browser will wait for the next to load before unloading the current one so with a little css trick you can do a nice transition between pages
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)
Looking at the app reviews looks like it's also a dream for the user (only 5-star ratings!). Kudos to you!
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.
> From my experience, push notifications are a very important feature too, almost all of my customers want that
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.
I agree, nobody likes fake or useless notifications. But luckily these days Android and iOS offer end-users the option to disable notifications. It's not a perfect solution though of course as you might not want to block all notifications from the app.
From what I'm seeing my customers treat push notifications very responsibly and their app users love the feature :)
AFAIK iOS does not have notification categories, you can only configure notifications as a whole per app, but not on category level. And I distinctly remember having turned off all notifications in their settings in an App for an Android, yet still received some.
I think so too - notification categories are Android exclusive. I like that feature a lot, but it also depends a bit on the app developers that they use it correctly and don't just have 1 category for all notifications.
Receiving notifications while having them disabled is weird - I haven't had that happen to me yet luckily.
Very interesting - my co-worker reached out to you to see if one of our sites would work. It's a collection of analysis tools written in JS meant for the desktop web, but we can reconfigure it to work better with responsive viewports.
Would really like to get something like this as a proof of concept for our clients who just love mobile.
I'm no expert in Capacitor, but from what I understand, different goals.
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.
Capacitor creator here: agreed that Capacitor absolutely could be used by the PWA Builder team to power this and still keep their goals/values in mind (we also have a connection through Justin at PWA Builder who was an old Ionic team member!)
I am going to chat w/ Judah about this, already have a convo on github
It has been really cool to watch the evolution from Apache PhoneGap -> Cordova -> Ionic -> Capacitor (where now Ionic is the UI component library)
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.
Appreciate the kind words! Capacitor is younger than anything on that list so it still has a ways to go in terms of market awareness, but the general reaction we see when devs try it out is very positive. When we explain to people that you can build a native iOS/Android/Web/Desktop app with your favorite web stack and existing web code in many cases, that's turning out to be pretty compelling. And, for people that tried Cordova in the past, Capacitor's DX is pretty dramatically different and improved.
I did just that when using capacitor (pointed it to my dist folder, good to go). What other steps do you think capacitor requires that PWA builder doesn't?
Capacitor is great! At the BBC, we significantly reduced the cost of producing apps for children by adopting Capacitor. We write one React PWA and ship it to the Play Store, iOS App Store, Amazon App store and Amazon Kids+ store. It's native integration helps with push notifications and also reliable persistent storage on device.
Can you accept in-app payments with Capacitor? Asking because I did not see it listed as an official plugin.
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?
It's quite easy but it depends how you want to do it. Would you want to take an existing PWA codebase and deploy it in the best possible way to mobile, or do you want to wrap the existing externally hosted PWA? Both are possible but the former will be more likely to be accepted into the app stores.
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
Curious. What are all these things you want to get notified about? I pretty much have all notifications turned off besides messaging, phone, and alarm.
I'm a developer of a web app where users interact with each other. Notifying users on in-app activity is the absolute most important thing for them and for us.
Google implemented PWA support years ago into both Android and Chrome, including web push notifications. Apple is the only one that purposely doesn't implement necessary features for PWAs like web push notifications.
Google and Mozilla have supported the web push API for going on 6 to 7+ years now.
Facebook's mobile website works well enough. They keep pushing me to use their lite app, but I suspect it's not in my benefit. The web app is a bit buggy (only the first few photos load on an image post), but there's no reason to think that couldn't be fixed if they tried.
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.
In my interest, too. Pay attention to non-geeks using this "feature" and it's clear that web push is the 3rd party toolbar[0] of the modern web. Crap they enable by accident, then don't know how to get rid of.
[0] Ask someone who worked with computers in the late 90s and 2000s if you don't get the reference.
I'm confused, what are Google blocking? iOS famously lacks push notification browser support, but Android's browser and third party browsers on the platform all support it on Android (and have since forever).
Please don’t use tools like these. Customers want native apps, not thinly-wrapped websites disguised as apps.
(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.)
Many things that need to be apps on iOS are fine as PWAs, just Apple's crippling of PWA functionality (no notifications+no background sync mean you can't have your data up to date, all data deleted after a few days if not on the home screen) forces vendors to wrap them as apps.
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.
Maybe no one wants sites wrapped in an app, but some of us do want to use the site through our web browser. So please keep on building web sites/web apps :)
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.
No. If Apple values their user experience they shouldn't throw developers under the bus. When they fail to adopt cross-platform standards like Vulkan, this is what happens.
I wonder if you realize that "cross-platform standard like Vulkan" was announced two years after Apple had already released Metal v1 (after investing significant resources into it)?
Why should Apple invest in supporting Vulkan, exactly?
That makes no difference. Apple has the resources to support two graphics APIs at once, and the detriment of not doing so has been setting in quite heavily. 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 (like DXVK).
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.
> 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.
> Progressive Web Apps (PWAs) are web apps that use service workers, manifests, and other web-platform features in combination with progressive enhancement to give users an experience on par with native apps.
If it works, this is awesome. I've used it before to add my PWA (liftosaur.com) to the Android store, and it's way easier to get users from there, than to explain them how to install PWA. Will try it out for iOS definitely.
How's the camera integration? Can you programmatically open the camera to capture a picture for uploading? Or does it still need the "file picker" menu interface?
I have used this for some of my web apps, and it has been really great to have them in the store. However, Apple has given me a hard time on some of my apps since it is against their rules if your app doesn't provide additional utility over a website.
What sorts of apps were given a hard time? Like where's the line between a full webapp and website. Does the webapp need to hook into device-specific APIs to not be a website?
It is hard to say with Apple, it seems highly dependent upon the reviewer. In one case, I just resubmitted the same app with a different build number and it then passed through review just fine. /shrug
This sounds great; I've made a few PWAs and wanted to publish them on app stores but couldn't quite figure it out so I gave up. Might give this a shot.
Google: forks the web with AMP, rams its own poorly desinged, Chrome-internal APIs through standards processes, continuously gaslights other browser developers through a multitude of talking heads.
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.
We have a webview-wrapped-spa on Google Play without fuss. But haven't tried to push to App Store because of 4.2.2
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?
Neat, but what stops someone from publishing your PWA under their own dev account? Sure you still control the site and data, but they could publish with inappropriate icons, wording, etc. It seems like maybe there is some potential for abuse.
This potential for others stealing your content has always been present though I suppose this tool would make that even easier. Android has the Trusted Web Activity which somewhat solves this problem: https://blog.chromium.org/2019/02/introducing-trusted-web-ac...
My app is a React Native app with a webview, quite simple to create/manage/modify and I have notifications, native logins, etc. with communication between the webview and the native app
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.
In a lot of ways web apps are more native and a better experience.
"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.
I had to check Smoldesu's post history to understand this comment, as Apple loves people writing native software, even if they don't care if devs can make a profit and the store is a mess.
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).
Thank you for your crack forensic work, this so-called 'Smoldesu' character really seems to be asking far too much for a company like Apple. How can someone even expect them to support more than one graphics API when they're not even the largest company in the world anymore? Truly ridiculous. Every real developer just splits their codebase into two separate portions, one for Windows, Linux, BSD, Switch, PS5, and Xbox, then one for MacOS and iOS. Sounds like the parent is just butthurt that they don't have the time to support multiple platforms and are too poor to afford a suite of Apple products to test on. What a reprehensible dev.
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!
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.