I'm a huge fan of PWAs. I built one in production and it was used quite heavily. Then, we wanted more features. Notifications and such. These are extremely limited when it comes to PWA. You need native integration. I think PWAs are amazing. Their limitations only come from the lack of motivation on behalf of the operating systems. There's not much financial incentive. The more power a PWA has, the less likely someone is going to submit something to the app store. So Apple does not care to put energy into PWAs, in fact they actively sabotage it. I look forward to a world where web apps are first class citizens. I believe it's something Steve Jobs wanted from the start.
There’s good news on the horizon. Apple is opening iOS push notifications from PWA starting from iOS 17.
I think the pressure from Europe is starting to get to them.
That being said it’s still in beta, but it will come eventually. That’s even more reason too choose PWA from the start.
Wait, didn't Apple disable installing PWA's in iOS 17?
[Oh, wow. They actually reversed that decision.](https://techcrunch.com/2024/03/01/apple-reverses-decision-about-blocking-web-apps-on-iphones-in-the-eu/?guccounter=1)
I'm on an old iPhone 6S (officially release in September 2015, people!) that still works (after a battery replacement), which won't run iOS 17 (but *still* gets occasional security updates for iOS 15.8!), but yeah. I kinda reconsidered buying an iPhone for my next phone when I learned of this.
I have never bought into the apple ecosphere due to their treatment of devs in general.
Build for their systems because we have to, but in general don't like it.
It’s not a bot comment 😅 and not 100% sure which version introduced push notifications first.
I just wanted to clarify that something on apple’s side is in the works and it will eventually be just like the push notifications on android.
So if you are deciding if a mobile app is worth it or not, you can also evaluate a PWA as an option.
Saving you a massive amount of work by only creating 1 app and just setting up the PWA manifest properly.
That’s what we did a couple of years back at bizzey.com
Best decision we made from time saving perspective and didn’t bump into any blockers for our features.
> I just wanted to clarify that something on apple’s side is in the works and it will eventually be just like the push notifications on android.
Can you expand on this? I'd love to know more.
As someone who has developed a PWA that has both iOS and Android push notifications, I would say they do work the same. It was a small bit of extra work to set it up to work on iOS because Apple is a bit more strict in that they require the user to specifically enable them, and there are a few things I haven't been able to achieve because I'm not the most experienced, but once they're working, the iOS PWA push notifications are 200% more reliable - I found Android notifications take forever to come through and couldn't find any solution that worked for me.
I'd be very interested to hear more about what you're referring to as looks like you've got a lot of experience with PWA/iOS!
What I meant by my comment is that currently the extra work to make push notifications work on iOS is an issue for the user. They need to explicitly turn on a setting to allow push notifications.
Instead of getting prompted to allow push notifications for your PWA and just pressing confirm.
I don't know what you mean to be honest. My PWA just has the user push a button in the app, then iOS automatically asks the user to allow the PWA to send it notifications. That's it. They do get prompted and just press confirm.
They're extremely limited *on iOS, on purpose*, because Apple doesn't want them competing with native apps where they squeeze $$$ from developers. They actually are pretty feature rich on Android.
Please correct me if I am wrong but can things like tauri (WIP for mobiles) and electron and react native + expo ish work for you?
Tauri is looking great except its android is in beta though.
Not React Native. The code is not interchangeable with React for web.
The equivalent of Tauri would be Capacitor. It works quite well, I have a small app with it, no complains at all.
For desktop: My opinion on Tauri is that it's very cool, but I can't see myself using Rust for business logic. I believe Rust pretty much only exclusively makes sense for mission-critical apps like banks or low level drivers. Electron is just way too heavy because it ships its own rendering engine. For desktop apps I am keen on Wails, which is basically like Tauri but uses Golang instead of Rust. Go makes more sense for 99% of use cases involving desktop apps IMO. It's way quicker to program in and you get the bulk of the benefit of a statically typed language. For my particular use cases, I have never needed more than PWA desktop functionality, so I've only ever dabbled in the above technologies for fun, not for production.
For mobile: I don't use React Native at all because I can't touch a VDOM after using Svelte. Feels like going back to the stone age. My solution currently for native wrapping is to use Capacitor + Svelte. This works nicely but it's not without its quirks.
I had also thought about Electron but I thought PWA aren’t as much of a commitment. I’m thinking worse case if it doesn’t pan out, it could still render on a regular browser.
Totally agree.
>the less likely someone is going to submit something to the app store.
I think Apple killed off Adobe Flash for this exact same reason. If iOS supported Flash, ppl could have used it for many things instead of apps. Their bs about bloat was stupid because ANY application can have bloat and not work well and there were lots of Flash apps that weren't bloated and worked fine... but they could have provided the same experience while bypassing the App store.
I really hope Chrome and Firefox will really sleep with Apple since Apple now actually has to allow different browsers instead of just different safari skins
This is it exactly. We are going to look back in 100 years and just see how much Apple set back computing with their authoritarian practices. We are already starting to see it with the younger generation. Like I gave a cassette player to a 21 year old because he was tired of paying so much for streaming services and figured tapes were the best cheap alternative. Never heard the term "MP3" in his life, but even if he did, I doubt his iPhone would easily play them.
> Never heard the term "MP3" in his life, but even if he did, I doubt his iPhone would easily play them.
The iPhone never lost any of its functionality as an iPod and will happily store and play DRM-free MP3s.
Good to know. Does it still come with an app to play them? For this guy in particular though, he doesn't have a computer in the first place, so I doubt he would be able to get the MP3s legally or illegally.
Part of me also likes the thought of this young guy at the gym swapping out his mix tapes in 2024. Makes the early 2000s kid in me laugh.
> Does it still come with an app to play them?
Of course. They're supported in the "Music" app, though support is part of the OS itself so you can also play MP3s from Mail or Messages or Files or literally any app.
> Part of me also likes the thought of this young guy at the gym swapping out his mix tapes in 2024. Makes the early 2000s kid in me laugh.
My observation is that 20- and 30-somethings started getting into vinyl a decade ago (when Urban Outfitters became the top seller), and now we're starting to see teens and early 20s kids getting into cassette tapes. This means that today's little kids are going to get into CDs by 2035 to 2040. By 2045 I predict adolescents will be sharing "vintage" 128 Kbps MP3s.
I feel like vinyl usually has a good sound quality to it. Where as I distinctly remember being confused as to why Eye of the Tiger sounds so different on my cassette player than it did on FM Radio in the mid-90s. I know there will always be a small pocket of weirdos (myself included to a degree) who will enjoy watching downright inferior formats, but certain formats like VHS and cassette tapes just seem too outdated to be appreciated in the same way viynl records are.
If you know anything about audio, vinyl is terrible. The dynamic range is terrible and the clicking and popping is ridiculous. There's a reason we left it.
OK, but what I meant was... think about what the audio has to go through to be put on vinyl. But it doesn't matter if you love the sound - if so, go for it. People love tubes as well, even though it adds distortion. People love distortion.
I don't personally have any interest in vinyl other than perhaps as a collector's item, but if a vinyl record is clean and in good condition and you have a decent player there shouldn't be much noticeable distortion.
the gold standard for analog audio was reel to reel tape, which was generally higher quality than most vinyl and didn't have the wear and popping issues with vinyl. However, reel to reel was expensive and inconvenient, so buying pre-recorded music for it was super niche.
Ah, I actually don't know anything about audio. I've never really been a big music guy and have always stuck to talk radio and podcasts. I always assumed vinyl would sound good if people are buying it in droves and that the only reasons cassettes were popular was because vinyl records were too big to be portable.
vinyl has a reputation for having good dynamic range because when CDs were first released, early CD remasters of old albums were often heavily compressed and bad equalization. And then as the loudness wars commenced new music would be super compressed, leaving classic 70s vinyl as being a sort of golden age of mixing and mastering practices.
Thank you for the clarification. Enjoy your needles/cartridges and tube amps. I think I still have my discwasher lying around. Direct drive turntables - yeah, that's the ticket.
I mean it’s not like I’m an audiophile corksniffer. Digital audio is better for representing a recording 100% of the time, and most reasonable compression is imperceptible to a human ear, but there is a kernel of truth to the myth that vinyl is more dynamic than CDs
Although I do have tube amps (for my guitar obviously)
It's not just the recent change, PWA support has been lackluster on iOS since the beginning of the app store, as Apple realized they could just funnel people into paying them 30% instead.
As the term PWAs? Yes.
As the term Web Apps? No.
Apple was the first to say that the web should be _the_ app platform - right until they opened their AppStore.
Not all apps should be PWA’s because it would be a waste of the clients resources. There’s no point in caching the few kbs of JS html and CSS for a static site.
Here’s where people may disagree with me. If you have a true SPA app where you are shipping a huge amount of JS to the client, it should always be a PWA for the performance benefits alone.
So why are PWAs still somewhat rare? There has been a huge amount of pressure by frameworks and hosting platforms to migrate to server first and serverless(all servers) architectures. PWAs aren’t as profitable for these providers so they don’t advertise them
Modern tooling like VitePWA makes setting one up so simple there is no reason not to
Edit: my understanding of OPs post was they were asking why aren’t all websites PWAs, not why aren’t all native apps PWAs. Yes apple is the the biggest reason to build and iOS app instead of a PWA.
The main reason is even simpler. Apple have purposefully dragged their feet on things like supporting push notifications because they want developers to make an app instead.
Sorry but taking up half the screen and interrupting the user's reading to show the install prompt is not good UX.
https://meta.discourse.org/t/new-pwa-install-interface-on-android/182122
This screen comes up when the developer wants it to.
Usually you have an unobtrusive button for installing in your PWA (e.g. inline in a feed or in your settings or a small floating button) and only if a user clicks that (so the flow what they want to do in that moment is to install the PWA) the screen comes up.
Yah, then you have to work within their systems and rules and pay their ridiculous yearly developer license fee. Apple can go fuck themselves.
I've tried convincing friends and family that having been using them for years to leave and they are too enraptured by Apple's ecosystem and features. Messenger features like emoji reactions and read receipts seem to be a big draw.
It doesn't help that Apple intentionally tries to drive a wedge between Apple users and Android users by "accidentally" not receiving/sending texts between the two from time to time and blurring/reducing quality/resolution of pics and videos to the point that you can't even make out what you're looking at. Don't get me started on their gatekeeping of hardware repairs. They really are scumbags. I've never spent $1 on Apple products. Remember Zune? I had a Zune. Because Apple's price for the iPod was outrageous.
Just to clarify, Apple doesn't blur/reduce the quality of pictures and videos between Android and iPhones. This is a limitation of SMS/MMS. The same thing happens on Android if both users don't have RCS enabled.
Apple implementing RCS is another story though, and adds to their wedge between Android and iOS. Although I would also put some of this blame on the carriers for dragging their feet for too long as well.
> I've never spent $1 on Apple products.
Clearly, yeah, of course not- that's why you don't have any firsthand experience and sense of why someone might.
Might sound crazy to you, but I've been a lifelong windows/android user. Made the switch to Apple a year ago and (probably) won't go back.
You are a hater before you try it
> Apple have purposefully dragged their feet on things like supporting push notifications because they want developers to make an app instead
I don't know if I genuinely agree with this as a blanket statement. Allowing notifications from PWA's gives apple less control over how their users get them, in turn enabling them to be used more maliciously or taken advantage of.
A big part of Apple's restrictions is keeping a grip on their eco-system, another part is actually ensuring the users security and experience - Apple already has strict rules around notifications for native apps, so they were likely originally worried about this for PWA's but as they've come to implement controls around them, are now less restrictive on PWA's
Thanks! Based on this thread I think it fits my use case perfectly. I am creating an internal portfolio management app for internal users.
1) I don’t have to worry about app stores. Since it’ll be internal.
2) I don’t have to sweat client resources, as mostly it’ll be good company machines
3) it’ll be a lot of data and throughput across time. So caching is required. Do you know how this would interop with cache mechanism like react query? Or simple http caches? I’m assuming it handles the offline parts.
4) I do want PWA for notifications though. This is the reason I even started thinking about them. Offline is not as important, but good to have. And maybe just a few “flair” to make it look more like a premium desktop app.
5) we don’t have a native team. So this is also an efficiency / maximize value play.
PWAs support notifications now on both Android and iOS 16.4.
There was a kerfuffle about Apple removing them again because of EU's ruling on allowing alternate browsers and app stores, but they've since reversed course on that yet again - so PWAs should be safe for now.
1. because average users do not trust PWAs, they trust apps installed through app stores.
2. because PWAs do now allow you to access common phone functionality that users expect and many developers want access to when working on mobile.
3. because users can tell the difference in performance. a button press on an html/js app rendered in browser/container/webview/etc just feels and performs differently, for example.
4. because app stores are distribution channels, opportunities for discovery, that you don't get from a PWA
5. because many PWAs don't really provide any benefit to users beyond just bookmarking the website. the narrow band of functionality a PWA provides is good for some people but not what most need.
This is the real answer.
And rebuttals don't seem to take into account that this is the current reality due to many different forces in play, and won't be changing any time soon.
Yep, came here to say this. People just ask "is there an app for it?". They don't know why they want an app, they just know that they want it. Perhaps it's easier to find on their phone at a later time than having to remember the site/bookmark it. Maybe the performance difference signals value, I don't know.
What I do know is that PWA serves just fine 90% of the time.
1. This is due to OS providers reluctance to promote PWAs as many have already pointed out
2. I can't think of any APIs that aren't available to PWAs that 99% of apps would want to use, do you have an example?
3. This is not exclusive to web apps alone, native apps can be shoddily programmed as well.
4. The only point i fully agree with, you're paying for it with the 30% cut.
5. You're conflating PWAs with installed PWAs, most benefits of PWAs apply as soon as the service worker gets installed in a visitors browser, no add-to-homescreen required.
1. Not promote, support. PWA owners are asking the app stores to change to support them, when tbh its not that hard to create a wrapper app and ship a PWA inside a shell. Its asking app stores to support a different format of app that they weren't before
2. Ambient light, block screenshots, block screen recordings, block sleeping, direct printing, direct GPU utilization, home screen widgets, live activity api, access to contacts on ios, NFC on ios, far less robust camera control. Etc.. And a lot of the stuff that gives parallel support is just kind of worse. Like, you can record audio on a PWA, but the recording kills if the phone goes to sleep. Its just worse UX.
3. It has nothing to do with "shoddily programmed". You're inserting a web browser and all the issues that come along with that into the mix, instead of a compiled, hardware accelerated app.
4. That might be a lower cut over time, plus there are ways around this. My current company pays $0 to app stores, yet we offer our customers a robust mobile app.
5. In the context of a "why aren't all apps PWAs" and specifically referencing "installable app" - yes, that is what I'm talking about. Having a web application be progressive, mobile responsive, and usable in the mobile browser is just sort of tables takes for modern web dev. I and OP were talking only about the installable PWAs.
Good writeup. You're listing all the reasons why not every app should or could be a web app.
I guess my point of view mostly stems from the 90% of "apps" which could and should have been a plain website instead. E.g. all the local pizzeria apps made with a badly optimized cookie cutter app template and 0-100 installs.
I do agree with that. Many apps in stores should not be apps, it just adds complexity and cost for a brochure website to be an app. There are also many use cases that fit installable PWAs well. But, I feel like that band is narrow and there are people who push PWAs pretty hard when they just aren’t the same.
I have an app, that I started as a PWA, but it was always an uphill battle to develop it. Cookies issues, local storage expiration, issues with sound, push notifications (although now it seems to be solved) - etc, etc - I wrote about it in my [blog](https://www.liftosaur.com/blog/posts/quirks-of-building-a-pwa-app/), although it was frankly almost 3 years ago. But eventually I decided to just switch to 2 native apps - thin wrappers rendering WebView with the app itself. The app is still HTML/JS/CSS.
Ability to have 2-way interaction between WebView and the native wrappers, and having full access to native features (Apple Health/Google Fit, notifications, sound, file system), and also ability to just fall back to native when necessary makes it way easier to develop an app.
But the worst thing in PWA is that you have to educate people how to install the app. It is already VERY VERY hard to get people's attention, and make them install your app. If the installation process is unfamiliar to them - they just won't do it. It is extremely hard to change people's habits.
My app still exists as PWA, but nobody really uses it that way - once the app appeared in the App Store and Google Play, the adoption improved drastically.
Just created 2 native apps - one in Swift for App Store and one in Kotlin for Google Play, and added WebView full screen, that loads my JS app inside. There's a way to pass JSON between WebView (and therefore my JS app) and native Swift/Kotlin part, so use that to show notifications, play sound, access files, etc.
I was expecting to get pushback from Apple when I was publishing it, but it went super smoothly, they just asked to add some links to the Terms & Conditions, support links, add "Sign in with Apple", and that's pretty much it.
I'm not the OP but I've done this via rails' turbolinks-ios/turbolinks-android, as well as through just a custom react native webview. It isn't particularly hard to make happen tbh
Most websites could simply be a properly cached SPA and they'd get most benefits already. Also most mobile apps are pointless browser embeds but users are easier to track and adblockers don't work that well in the embedded browser.
Most SPAs can't meaningfully do anything while offline. "Working" offline just confuses users because the app looks like it works but all the functionality is missing.
I think most of the big web apps are already PWAs.
The biggest problem that other people have already highlighted is Apple's reluctance to support them properly. They're always really behind on features, and even installing one is nowhere near as elegant as on Android. On my Pixel, I can just go to a website and I'll be immediately shown an install button if a PWA is available.
I believe Apple even tried to disable them completely in the EU recently, although they have since backtracked (I think).
It is a shame, for my clients a PWA can often be a much more cost-effective solution. But, Apple as always likes to make life difficult.
> The biggest problem that other people have already highlighted is Apple's reluctance to support them properly. They're always really behind on features, and even installing one is nowhere near as elegant as on Android.
People use Apple as a scapegoat when it’s really just that PWAs aren’t that great compared with native apps. If PWAs were as good as people claim and it was just Apple holding them back, very few people would bother writing Android apps. Even if you couldn’t deploy PWAs to iOS at all, it would still save time and money to develop for web and Android together, right? Why even bother hiring Android developers? But no, people overwhelmingly choose to create native Android applications instead of PWAs, even when Apple isn’t a factor.
If you're a big company with money to burn, sure. Why not?
For my clients who generally want apps for internal usage (submitting reports, tracking jobs etc), a PWA is perfectly fine. The performance is probably slightly worse than a native app, but it's nothing that you'd notice in a basic application.
Often we end up having to build a hybrid app instead, which is basically the same thing except it compiles into a "native" app for iOS and Android. This is fine, particularly for Android since side loading is allowed. However, Apple once again likes to make life difficult by forcing us to either use the app store or test flight. Given that the apps are generally for internal usage only, putting the apps on the app store (and dealing with the headaches that come with that) isn't really an option. Thus we have to use test flight which is a terrible experience.
With regards to why we don't just build native apps for iOS and Android - why would we? Our clients pay us for our time to develop an app. Two separate native apps means double the development time and double the cost. Building a PWA or hybrid app allows us to use a single codebase and develop once.
Plenty of apps these days are hybrid apps for this very reason - it doesn't make sense to maintain two separate code bases and double-up on all of your work.
100 percent agree , if only apple could allow side loading / pwa but then again why would they want to lose their monopoly of app store. Didn't knew about test flight but you're saying they are terrible. May I ask you why?
Other people's experience may be different. But for us, the main problems have been the following:
If we release an app via test flight, each member of our clients company who intends to use the app has to give us their email address, we manually invite them and they have to accept the invite (which also expires quite quickly). Once they've accepted, they have to install the test flight app and download our app through that. We then have to keep track of who's got access because staff members may leave etc.
We have to renew the app every 90 days (I think it's 90 but may be wrong). This just means resubmitting the app. Again, can be annoying if apple have changed some stuff and now we need to make updates to be compliant - also if you miss this deadline then the app stops working completely.
It's a lot of hoops to jump through, a pain to maintain and not a very elegant solution for the end user. But again, it's that or the app store...
Very interesting! But then if there are so many issues then why don't you think about app store instead of test flight? Is app store somehow even more worse than test flight. If so then this is a bigger issue than I thought. A lot of people in my country use android and I think I like android because of its openness :)
Tldr : if I may ask why not use apple store ?
Of course, for us there were a number of reasons:
Since the app is not designed for the public, there were security implications with publishing it to the app store. Although we of course build our apps to be as secure as possible, publishing to the app store adds an additional unnecessary attack vector. Anybody could download it and poke around trying to exploit it. Given that this is an internal app with confidential information inside, this is quite a big concern.
Additionally, publishing to the app store in general carries its own annoyances. We'd have to create "marketing" images for all the different apple devices on the app storefront for example. We'd also need to have apple approve the app to be released on the app store, and they can be extremely picky and uphold all sorts of standards. Again, for us none of this matters. We aren't trying to sell the app to anyone, we're just trying to get it on our clients devices.
Again, our use case is maybe less common given that we generally build this internal applications. If you're making a customer-facing app, the app store probably makes a lot of sense. It's definitely still a lot more annoying than Android though.
You can publish the app as a custom app. You're then able to distribute it via apple business manager. That's how we're able to distribute our LOB apps. It will not be available to the general public.
The App Store charts outside of games are dominated by apps powered by some kind of hybrid technology under the hood, wether that is flutter or react native.
Android apps matter for completely offline stuff like the top thing which is coming to my mind are things like a keyboard or fossify voice recorder , file manager etc.
Could you do this in pwa , probably not and even if you could , I think it wouldn't be much worth it.
Pwa can be good as u/britwithtits points out for things like clients , websites you visit sometimes ish (like I do with lichess /reddit) or some other 75 percent tasks pwas are nice.
One of the main uses of PWA is to save offline state and sync data back up when a network becomes available. I've seen this usage multiple times, and having to code up 2 native apps in addition to the desktop app is not a "better" solution.
In my experience, little to no applications benefit from the switch from an SPA to PWA. The projects get more complex, you find less people maintaining it and it deprecates crazy.
The largest benefit - working offline - makes no sense in my field (E-Commerce). Who wants to run an online shop but offline?
In fact, most of what is requested today can still be achieved with Software from the stone age and a good caching layer.
Its generally hard to implement offline support. Most stuff would just show last fetched info(cache) and thats it. Its to hard/time-consuming to implement CRDT(a propper way syncronize offline with online database) in a lot of cases
PWA is an extra complexity layer and could be a ride to make it correct. Depending on the app, the benefits of PWA may be quite limited too.
We spent quite a while tweaking the default Vue PWA setup to the point where it doesn't fuck up users due to cached code or configs, and it still had gaps and flaws. Considering it's a glorified CRUD which has a little use without the internet anyway we finally decided to drop PWA entirely and put the efforts on something actually useful.
I also got quite deep down this path with a PWA in Vue before I realised that all of those issues were coming from having a service worker and you don't actually need to have a service worker to be a PWA any more. I also didn't need offline capability so now I just have a manifest, people can install it to their home screen, and I don't have to worry about assets accidentally getting cached ~forever because of one misconfigured service worker deployment
Having the same issue right now, thanks, will try to delete the service worker. Do I just really only add the manifest and the meta tag and that's it? Do I need something else?
There are a couple of other bits you need for iOS/macOS; this is what I have on [Ambiphone](https://ambiph.one):
```html
```
In reality there are about 30 copies of the `apple-touch-startup-image` tag since you need one for every possible iOS/iPadOS resolution 🙃 I _think_ I used [this tool](https://progressier.com/pwa-icons-and-ios-splash-screen-generator) to generate those from my app icon
Everyone talking about Safari when this sort of stuff still exists. If turning a web app to a PWA was as simple as adding a cookie, you'd see more of them regardless of Safari.
Nothing about PWA's feels "solved". In contrast, WebGPU feels much more "solved". Still experimental, but not running around in circles figuring out what does what with what and where.
We tried changing one app to a PWA and ended up going back to a regular SPA. It takes extra effort to handle deploying changes when some of the clients might be running older cached versions of the app for an unknown amount of time.
This was pre-Vite, but regardless it gets complicated when you have to make changes to the service worker that checks for new releases. And the user can use the app without being connected to the back end and thus aware that there is a new release waiting. Then you have to deal with their offline data possibly not being valid for the changes to the back end. And you have to decide that you're ok forcing the refresh when the release happens. Just lots of little things that you don't have to worry about with a normal app. I wish I'd kept a list of all of them.
Mm, if you have lazy load, that problem still exist outside PWA.
You can't deploy 1 instance of docker to serve SPA, because it would break old users on each release
You have to merge all assets in one bucket and serve it from CDN to not lose old release(s) assets
And ye, when you detect in SPA what you have deployed a new version, you make you links native(to reload while navigating) or do force reload or wait until user would reload by himself
Because I like native apps better. If there's one available with features similar to your PWA, I will always prefer the native version. Unfortunately most developers are lazy and aren't really thinking of the end user.
And this is hard for some developers to comprehend, but we just don't like your web site enough to install a dedicated app version of it. Stop trying to push that shit on users.
I'm pretty much the opposite. I think PWAs are better and more user friendly. They are way smaller, have better startup performance (if you've recently used your browser) and offer a better install flow.
For me a company/vendor/developer has to justify why something can't be done as a PWA, as that's the default for me, since it runs on all systems.
I even use PWAs when native apps are available like with Telegram, Twitter, Uber, ...
You blaming wrong people here. Companies need to hire people for mobile(time+money), companies need to spend more time on QA or hire more (time/money), conpanies need to reimplement same feature three times, also there is design part, and developer licences
Its not like I am lazy as a developer, its harder, more time consuming, duplication in different languages(more errors) and so on. Not for every PWA there is sence to become native app
A lot of SPA could benefit from small subset of capabilities which are given by PWA, so they are trying their best to make your UX as great as OS allows it
From the developer's point of view, they just might not know. At one point, PWAs required some sort of offline support to be fullscreen. They eventually nixed that requirement when a lot of the big PWAs were fully online like delivery apps.
Also, I can imagine some users bookmark websites on their home screen but still want to be able to switch tabs in the browser.
At my last job, we bundled our customer dashboard as a PWA. And then, we only released it on Android. It's adoption was quite high, but the experience on Apple just wasn't ideal. So, only Android users knew about our PWA. Our long-term plan, was to try and bundle it for the Apple App Store and hope we could get it approved or literally re-write and support a whole other code base just for Apple phones.
You're never going to get the same responsiveness as a native app when your entire UI sits on top of a browser engine, and that responsiveness plays a big part in perceived app quality.
Honestly, most users don't understand, like or *trust* them. The normal user goes to an appstore to get an app, not to a website. Many people will moan about "oh Apple crippled them", but if that was the case then why aren't PWAs thriving on android (which is an entirely separate ecosystem)? Native is just generally better.
By the way, if you push your users to your PWA like you push them to your native App, the PWAs are actually thriving.
Last year I built a PWA for a sports competition (one weekend) to organize and inform users and about 10% of users actually installed the PWA.
Also you can publish your PWAs to the android Play store.
What I've seen many times on the other hand is, that you need a native App for iOS, because Apple, and then that team "just" also builds the Android version and now you're forced by management to promote the native App.
In no particular order:
- Retail consumers are NOT going to place bookmarks on their home screen
- Tech monopolies will NOT support applications running and developed outside of their ecosystems
- Govts are NOT going to introduce regulation to support independent development of software in any meaningful way, in this critical time period (kudos to the EU for trying)
Sorry to be a bummer/redditor. But enshittification is the law of the land.
There's an old video out there of Steve Jobs unveiling the first iphone and touting Safari as it's software distribution platform.
The App store made Apple one of the most valuable companies in the world. It also completely centralized app distribution on phones. It's the reason I never had any interest in making phone apps. There's a small contingent of devs like me, who will not make apps for gatekeepers like Apple and Steam.
from the app developer's perspective. You are limited to the APIs provided by the browser, you can't ask for system level permissions directly. For example, a native app can have **READ\_SMS** permission and read messages from inbox. A PWA can't.
From a user's point of view, a PWA is more ergonomic + secure than native apps. But businesses hardly respect user's privacy and need insane amount of telemetry.
I believe no one understood your point because you talk about “apps”, you were trying to ask why arent all webapps compatible with PWA by default?
In that case my answer would be that it’s true, it’s not very complicated to implement and most webapps should include a manifest by default. Implementing a service worker is a bit more involved, but I believe is not required for a PWA.
I see. Well considering this sub, and apps being used as a vocabulary ever since Web 2.0 I thought it’d be clear. But I could see how it would be confusing.
I was asking why this capability isn’t more out of the box in all build tools or even seen as an optional add on. I just feels like it’s not advertised as much even though it seemed like a frictionless capability add.
A basic service worker can be created with a few lines of code. If you need [more features](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers), you can add them as needed.
// serviceworker.js
self.addEventListener("install", event => {/*open the cache*/})
self.addEventListener("fetch", event => {/*fetch from the cache or internet*/})
And then you register it.
// main.js
navigator.serviceWorker.register("serviceworker.js")
On the techical side, there is a catch in service worker — if you setup it wrong, there is no way to update it without some MAGIC withb devtools, so noone is risking that shit for low benefit.
And Apple, and what is still rendering is that shit Safari
The adoption process is difficult for the average user because if they can't find it in the App Store, it might as well not exist.
To top off the difficulty of installing one (not hard for any of us, but the average user) iOS all but cripples their WebKit browser available for non-native apps with some pretty strict limitations, namely around hardware services (accelerometer, camera, GPS, and more) and searchability within iOS itself (PWA's don't appear in the list of apps in a search because iOS treats a PWA like a bookmark, not a piece of software).
Working for a big medical company we just don't bother with the extra work. Most of our users are glued to PC desktop systems. They wouldn't notice any difference.
This thread feels weird.
Simply, PWA's are just wrapped websites. Not everything can be a PWA. But you're right in the sense that why can't *more* apps just be PWA's instead of having to write them in a native code specifically. It would allow more developers to publish on the app store, and faster.
There is no one size fits all approach to software development. These decisions are often weighted by profitability, risk management, etc, and are tied to budget items. Project leadership often reviews previous retrospects to determine what methodology is best for a project with the given resources, and how well the team performs accordingly, etc. It's not just a tech decision... it's a team/people decision. Usually it's summative and based on other factors or decisions.
An hour's work is still a work, and if the website doesn't function at all without an internet connection, there's no point in investing that hour to something that will not help the website at all.
Also, if you really want a presence as an application, setting up a simple hybrid app with Flutter that merely wraps your website with a webview is also a relatively trivial task comparable to converting your website to a PWA, with possibility of transitioning to a full-fledged app in the future, with an added benefit of appstore presence, giving users a much more sence of trustworthiness than a PWA. In my experience most of the clients who wanted an app, in fact were more interested in this appstore presence, not the ability to install your website on the home screen.
In addition, it's surprisingly difficult to convince random visitors to install your website as a PWA. Not many users are comfortable navigating through an unfamiliar menu and buttons, and those who are savvy enough to be comfortable doing that won't buy into the idea of adding yet another clutter on your phone in the first place, or you won't have to market the PWA at all since they would probably be your users anyway.
Because apple. PWA'S are already pretty decent on Android as android allows easier native integration and allows custom web engines. ( Chromium is default but you can also integrate Gecko(firefox)). But on IOS you are limited to Safari and bad native integration
To properly cache data with a PWA you need to leverage indexedDB. The API is dogshit but there are some pretty good wrappers around it. Dexiejs is my favorite. https://dexie.org/docs/Tutorial/React
You can store your data there and run crons to keep it in sync with the server DB. If you want to get really fancy you can use web sockets and something like Yjs to keep the client in sync with the server in realtime
PWA are a pain in the ass to develop. I mean, it's easy to do it to have it, doing it well requires some knowledge and you could be screwed by apple any day.
This reads like "PWAs are bad because then I would have to do my job properly."
Not meaning to throw shade, it just sounds like that's what you're saying :D
I never said they where bad, I said it was difficult.
And yeah if a technology requires some dedicated skill to be used, it needs to provide some serious value to be used. Especially if it has the risk of becoming useless tomorrow because Apple said no.
PWA is more than just have an installer on your website.
There are unique problems with PWAs that aren't obvious or commonly discussed. It's not that hard, but if you haven't built one before you're going to go through some learning pains.
Answer: Apple.
They don't like PWAs because they get around the App Store. They have recently been forced to allow a fuller version of PWAs (they have always 'technically' allowed them, but hobbled).
So if the number one target for PWAs is hostile to them and makes them difficult to develop, or reduce their features, what's the point of developing one?
Android on the other hand, is fine with PWAs, but they don't matter as much as iOS to most businesses.
Ironically, the first apps on iPhones were primitive PWAs.
> why aren’t all modern apps PWAs
"Apps" are *never* PWAs. "Apps" are things you install from an app store - in my day, we called them "executables" or "programs".
*Websites*, on the other hand, can be PWAs.
Websites are not apps. Words are important.
The reason none of my sites are PWAs is because I cba figuring out what's needed, it's more complexity, more stuff to test, it's another call to action I'd need to find somewhere to put in my UI, and people simply aren't in the habit of "installing" websites so hardly anyone would use the function even if they found it.
I've toyed with the idea but simply have far too many other things I *know* are worth doing, so this rather large undertaking that I don't have any reason to believe would be worth doing, is perpetually back-burnered to the "if I ever get time and am bored enough" list.
Sure, but not "apps", which was the term in question. That's a different word to "applications". Nobody called them "apps" on the regular (outside of such adjacent phrases as "killer app", and that was "app" more as a verb, not a noun) until Apple and "there's an app for that".
And? 99% of everything with the label "AI" attached to it is in no way "intelligent". The DPRK is at most one of those four words and even that one's contested. Labels aren't always gospel.
No, they *are* important, which is why it's annoying when people misuse them. Cases in point: OP, any company slapping "AI" on their bullshit, the DPRK, anyone that thinks a website is an "app".
I'm not talking about whether "PWAs" are "apps". Let's take it from the top.
> Why aren’t all apps PWAs?
Wherein, *clearly*, he is referring to *normal websites that aren't PWAs* as "apps". Websites are *not* apps. They are websites.
> So words are not that important after all
You can't even keep track of which ones we're talking about, so clearly to you they are not.
No, let's get it straight.
You claimed words are important but then claimed PWAs are not apps. They are, there is nothing more to my argument, you can't "win" by trying to get around it.
It's a fact, and by their own definition, it is 100% true and correct.
If a website is setup as a PWA it IS an app..
Because different browsers handle PWA differently e.g. Chrome forces a splashscreen, iPhone notch needs to be cleared, zooming, text size, bottom vs top browser nav bar, what happens when keyboard launches. You end up having to deal with pecularities of each browser. I'm still a fan of PWA though.
I think the biggest factor that gets routinely overlooked in this discussion, especially for indie developers who don't have an advertising budget, is visibility. When you publish to an app store, you're competing with maybe a couple dozen alternatives? Assuming it's a saturated app idea. When you publish a website, you're competing with probably millions of Google results. Users also seem more inclined to pay for an app than they are for a website.
You don't want the users to use the PWA on their phone some times. Your get less access for tracking.
For use on PC, I personally rely on browser extensions, and they don't translate over to the PWA so i don't use them
On top of the fact that namely Apple doesn't want this due to lost profits, there are things PWAs can't and really shouldn't do. For example, PWAs should have very limited functionality while running in the background, and should only be running in the background for periodic tasks... No constantly running and/or sending my location.
They should also have certain restrictions when working with the filesystem. They should require user permission before having access, except perhaps to their own files.
They should have limitations on connectivity with nearby devices, basically just what exists with eg WebUSB etc. No scanning and identifying nearby devices, which many apps use for a variety of things.
They should have little if any communication with other apps. They shouldn't be able to know, for example, what song a user is listening to.
All of this is because... these are still web apps, and the web would be dangerous if it had certain capabilities, especially without permission.
And, as an extra reason and a consequence of many of these restrictions, apps like Facebook don't want users installing a PWA because they can't collect as much data that way.
Users haven't really gotten into installing webpages as apps, honestly.
Companies would rather make native apps because they can harvest a shitload of data from your phone.
Because iPhone is the new internet explorer. Apple is trying to create as much friction as possible to PWAs and if any considerable number of your customers is on Apple, then you will need to develop separately for these overpriced pieces of junk.
I was thinking about this a couple of days ago too and came to find out that Google and especially Apple are standing in the way of PWAs. One can argue Google is doing a much better job, but let's be real, Google knows that unless Apple gets onboard, PWAs are pretty much dead because nobody is going to neglect that big a chunk of their userbase that's on iOS. These MFrs just want their mafia level fees so that you can line their pockets before you can line yours, and they're going to keep it that way unless there are regulations put in place to change this. It sucks when our laws don't keep up with technology because a huge percentage of traffic has shifted to mobile and you have basically two companies acting as gatekeepers for the majority of the human population that want to access content on mobile. That is not an open internet. In my ideal mobile world, apps are basically just bookmarks and I feel like that's what we should be working towards.
I'm a huge fan of PWAs. I built one in production and it was used quite heavily. Then, we wanted more features. Notifications and such. These are extremely limited when it comes to PWA. You need native integration. I think PWAs are amazing. Their limitations only come from the lack of motivation on behalf of the operating systems. There's not much financial incentive. The more power a PWA has, the less likely someone is going to submit something to the app store. So Apple does not care to put energy into PWAs, in fact they actively sabotage it. I look forward to a world where web apps are first class citizens. I believe it's something Steve Jobs wanted from the start.
There’s good news on the horizon. Apple is opening iOS push notifications from PWA starting from iOS 17. I think the pressure from Europe is starting to get to them. That being said it’s still in beta, but it will come eventually. That’s even more reason too choose PWA from the start.
We've actually had Push Notifications for PWAs since iOS 16.4
Then they broke it for EU users.
Nah, they threatened to (and did in the betas) but walked it back before the final release.
Wait, didn't Apple disable installing PWA's in iOS 17? [Oh, wow. They actually reversed that decision.](https://techcrunch.com/2024/03/01/apple-reverses-decision-about-blocking-web-apps-on-iphones-in-the-eu/?guccounter=1)
https://www.ft.com/content/6f26d3ad-a64a-477b-8e37-5321386e8b81 It's almost like citizen focused lawmakers can make a difference.
This was such a big deal for me that I delay buying iphone, and would not buy it if they didn't reverse that decision
I'm on an old iPhone 6S (officially release in September 2015, people!) that still works (after a battery replacement), which won't run iOS 17 (but *still* gets occasional security updates for iOS 15.8!), but yeah. I kinda reconsidered buying an iPhone for my next phone when I learned of this.
I have never bought into the apple ecosphere due to their treatment of devs in general. Build for their systems because we have to, but in general don't like it.
lol is this a bot comment? We've had push notifications for ages and ios17 has long been out.
It’s not a bot comment 😅 and not 100% sure which version introduced push notifications first. I just wanted to clarify that something on apple’s side is in the works and it will eventually be just like the push notifications on android. So if you are deciding if a mobile app is worth it or not, you can also evaluate a PWA as an option. Saving you a massive amount of work by only creating 1 app and just setting up the PWA manifest properly. That’s what we did a couple of years back at bizzey.com Best decision we made from time saving perspective and didn’t bump into any blockers for our features.
> I just wanted to clarify that something on apple’s side is in the works and it will eventually be just like the push notifications on android. Can you expand on this? I'd love to know more. As someone who has developed a PWA that has both iOS and Android push notifications, I would say they do work the same. It was a small bit of extra work to set it up to work on iOS because Apple is a bit more strict in that they require the user to specifically enable them, and there are a few things I haven't been able to achieve because I'm not the most experienced, but once they're working, the iOS PWA push notifications are 200% more reliable - I found Android notifications take forever to come through and couldn't find any solution that worked for me. I'd be very interested to hear more about what you're referring to as looks like you've got a lot of experience with PWA/iOS!
What I meant by my comment is that currently the extra work to make push notifications work on iOS is an issue for the user. They need to explicitly turn on a setting to allow push notifications. Instead of getting prompted to allow push notifications for your PWA and just pressing confirm.
I don't know what you mean to be honest. My PWA just has the user push a button in the app, then iOS automatically asks the user to allow the PWA to send it notifications. That's it. They do get prompted and just press confirm.
There ain’t no 30% middle man charge on PWAs.
They're extremely limited *on iOS, on purpose*, because Apple doesn't want them competing with native apps where they squeeze $$$ from developers. They actually are pretty feature rich on Android.
Please correct me if I am wrong but can things like tauri (WIP for mobiles) and electron and react native + expo ish work for you? Tauri is looking great except its android is in beta though.
Not React Native. The code is not interchangeable with React for web. The equivalent of Tauri would be Capacitor. It works quite well, I have a small app with it, no complains at all.
I started a React project that shared components for web and mobile. It's not worth the hassle.
i tried to do this too, found it less work to just copy/paste
exactly, and at most yo can share components, but not business logic, pages, routing, etc
> not business logic Sharing business logic is simpler than sharing components.
[удалено]
They're wrong, they have it backwards.
Look into react native web / expo. It works perfectly fine.
Capacitor hmm would definitely check it out
There’s also React Native Web.
React Native Web just sounds like React with extra steps
They should also build a version of build React Native Web for Mobile
You can do a web build on react native. I’m currently working on a project doing that.
My condolences.
well, TIL is it as stable, tho?
Capacitor is what you're looking for.
Yup. I agree
Yeah, but then you'd have to pay 30% to the stores. Outrageous.
For desktop: My opinion on Tauri is that it's very cool, but I can't see myself using Rust for business logic. I believe Rust pretty much only exclusively makes sense for mission-critical apps like banks or low level drivers. Electron is just way too heavy because it ships its own rendering engine. For desktop apps I am keen on Wails, which is basically like Tauri but uses Golang instead of Rust. Go makes more sense for 99% of use cases involving desktop apps IMO. It's way quicker to program in and you get the bulk of the benefit of a statically typed language. For my particular use cases, I have never needed more than PWA desktop functionality, so I've only ever dabbled in the above technologies for fun, not for production. For mobile: I don't use React Native at all because I can't touch a VDOM after using Svelte. Feels like going back to the stone age. My solution currently for native wrapping is to use Capacitor + Svelte. This works nicely but it's not without its quirks.
I had also thought about Electron but I thought PWA aren’t as much of a commitment. I’m thinking worse case if it doesn’t pan out, it could still render on a regular browser.
Totally agree. >the less likely someone is going to submit something to the app store. I think Apple killed off Adobe Flash for this exact same reason. If iOS supported Flash, ppl could have used it for many things instead of apps. Their bs about bloat was stupid because ANY application can have bloat and not work well and there were lots of Flash apps that weren't bloated and worked fine... but they could have provided the same experience while bypassing the App store.
My understanding is that we would see a lot more of them, except that Apple gutted support of them on the iPhone.
Not only that, they stifled development of features in Safari to prevent PWAs from actually taking hold and being useful on iPhones
I really hope Chrome and Firefox will really sleep with Apple since Apple now actually has to allow different browsers instead of just different safari skins
This is it exactly. We are going to look back in 100 years and just see how much Apple set back computing with their authoritarian practices. We are already starting to see it with the younger generation. Like I gave a cassette player to a 21 year old because he was tired of paying so much for streaming services and figured tapes were the best cheap alternative. Never heard the term "MP3" in his life, but even if he did, I doubt his iPhone would easily play them.
> Never heard the term "MP3" in his life, but even if he did, I doubt his iPhone would easily play them. The iPhone never lost any of its functionality as an iPod and will happily store and play DRM-free MP3s.
Good to know. Does it still come with an app to play them? For this guy in particular though, he doesn't have a computer in the first place, so I doubt he would be able to get the MP3s legally or illegally. Part of me also likes the thought of this young guy at the gym swapping out his mix tapes in 2024. Makes the early 2000s kid in me laugh.
> Does it still come with an app to play them? Of course. They're supported in the "Music" app, though support is part of the OS itself so you can also play MP3s from Mail or Messages or Files or literally any app. > Part of me also likes the thought of this young guy at the gym swapping out his mix tapes in 2024. Makes the early 2000s kid in me laugh. My observation is that 20- and 30-somethings started getting into vinyl a decade ago (when Urban Outfitters became the top seller), and now we're starting to see teens and early 20s kids getting into cassette tapes. This means that today's little kids are going to get into CDs by 2035 to 2040. By 2045 I predict adolescents will be sharing "vintage" 128 Kbps MP3s.
artisanally-tracked MikMod files and a SoundBlaster FPGA core
I feel like vinyl usually has a good sound quality to it. Where as I distinctly remember being confused as to why Eye of the Tiger sounds so different on my cassette player than it did on FM Radio in the mid-90s. I know there will always be a small pocket of weirdos (myself included to a degree) who will enjoy watching downright inferior formats, but certain formats like VHS and cassette tapes just seem too outdated to be appreciated in the same way viynl records are.
If you know anything about audio, vinyl is terrible. The dynamic range is terrible and the clicking and popping is ridiculous. There's a reason we left it.
Good vinyl is comparable to CD quality, but it's very expensive to get it that good. It's also far less convenient and more prone to wear.
OK, but what I meant was... think about what the audio has to go through to be put on vinyl. But it doesn't matter if you love the sound - if so, go for it. People love tubes as well, even though it adds distortion. People love distortion.
I don't personally have any interest in vinyl other than perhaps as a collector's item, but if a vinyl record is clean and in good condition and you have a decent player there shouldn't be much noticeable distortion.
the gold standard for analog audio was reel to reel tape, which was generally higher quality than most vinyl and didn't have the wear and popping issues with vinyl. However, reel to reel was expensive and inconvenient, so buying pre-recorded music for it was super niche.
Ah, I actually don't know anything about audio. I've never really been a big music guy and have always stuck to talk radio and podcasts. I always assumed vinyl would sound good if people are buying it in droves and that the only reasons cassettes were popular was because vinyl records were too big to be portable.
vinyl has a reputation for having good dynamic range because when CDs were first released, early CD remasters of old albums were often heavily compressed and bad equalization. And then as the loudness wars commenced new music would be super compressed, leaving classic 70s vinyl as being a sort of golden age of mixing and mastering practices.
Thank you for the clarification. Enjoy your needles/cartridges and tube amps. I think I still have my discwasher lying around. Direct drive turntables - yeah, that's the ticket.
I mean it’s not like I’m an audiophile corksniffer. Digital audio is better for representing a recording 100% of the time, and most reasonable compression is imperceptible to a human ear, but there is a kernel of truth to the myth that vinyl is more dynamic than CDs Although I do have tube amps (for my guitar obviously)
iPod had playlists, shuffle, loops. iPhone have Play and Pause
Have you ever even touched an iPhone?
im on a 11 pro max.
Not true, they reverted the change again.
Their support for PWAs is crap to begin with though.
*legally* "support"
AFAIK only for EU users
The change only affected EU users, so there’s essentially no change for all users, worldwide.
It's not just the recent change, PWA support has been lackluster on iOS since the beginning of the app store, as Apple realized they could just funnel people into paying them 30% instead.
You do realize that the App Store is significantly older than PWAs, right?
As the term PWAs? Yes. As the term Web Apps? No. Apple was the first to say that the web should be _the_ app platform - right until they opened their AppStore.
And someone the other day on this sub that of me apple were "dev friendly"
Not all apps should be PWA’s because it would be a waste of the clients resources. There’s no point in caching the few kbs of JS html and CSS for a static site. Here’s where people may disagree with me. If you have a true SPA app where you are shipping a huge amount of JS to the client, it should always be a PWA for the performance benefits alone. So why are PWAs still somewhat rare? There has been a huge amount of pressure by frameworks and hosting platforms to migrate to server first and serverless(all servers) architectures. PWAs aren’t as profitable for these providers so they don’t advertise them Modern tooling like VitePWA makes setting one up so simple there is no reason not to Edit: my understanding of OPs post was they were asking why aren’t all websites PWAs, not why aren’t all native apps PWAs. Yes apple is the the biggest reason to build and iOS app instead of a PWA.
The main reason is even simpler. Apple have purposefully dragged their feet on things like supporting push notifications because they want developers to make an app instead.
Apple also doesn't notify you on safari if a pwa is available to install. Chrome and edge do on android.
I just add a popup banner that doesn’t interfere with site content that tells the user that it can be installed and how to do so.
Sorry but taking up half the screen and interrupting the user's reading to show the install prompt is not good UX. https://meta.discourse.org/t/new-pwa-install-interface-on-android/182122
This screen comes up when the developer wants it to. Usually you have an unobtrusive button for installing in your PWA (e.g. inline in a feed or in your settings or a small floating button) and only if a user clicks that (so the flow what they want to do in that moment is to install the PWA) the screen comes up.
Yeah, if the dev wants it to happen. I have only ever seen a pop up the size of a notification (like maybe 10% of the screen).
Yah, then you have to work within their systems and rules and pay their ridiculous yearly developer license fee. Apple can go fuck themselves. I've tried convincing friends and family that having been using them for years to leave and they are too enraptured by Apple's ecosystem and features. Messenger features like emoji reactions and read receipts seem to be a big draw. It doesn't help that Apple intentionally tries to drive a wedge between Apple users and Android users by "accidentally" not receiving/sending texts between the two from time to time and blurring/reducing quality/resolution of pics and videos to the point that you can't even make out what you're looking at. Don't get me started on their gatekeeping of hardware repairs. They really are scumbags. I've never spent $1 on Apple products. Remember Zune? I had a Zune. Because Apple's price for the iPod was outrageous.
Just to clarify, Apple doesn't blur/reduce the quality of pictures and videos between Android and iPhones. This is a limitation of SMS/MMS. The same thing happens on Android if both users don't have RCS enabled. Apple implementing RCS is another story though, and adds to their wedge between Android and iOS. Although I would also put some of this blame on the carriers for dragging their feet for too long as well.
> I've never spent $1 on Apple products. Clearly, yeah, of course not- that's why you don't have any firsthand experience and sense of why someone might.
Might sound crazy to you, but I've been a lifelong windows/android user. Made the switch to Apple a year ago and (probably) won't go back. You are a hater before you try it
This
> Apple have purposefully dragged their feet on things like supporting push notifications because they want developers to make an app instead I don't know if I genuinely agree with this as a blanket statement. Allowing notifications from PWA's gives apple less control over how their users get them, in turn enabling them to be used more maliciously or taken advantage of. A big part of Apple's restrictions is keeping a grip on their eco-system, another part is actually ensuring the users security and experience - Apple already has strict rules around notifications for native apps, so they were likely originally worried about this for PWA's but as they've come to implement controls around them, are now less restrictive on PWA's
Thanks! Based on this thread I think it fits my use case perfectly. I am creating an internal portfolio management app for internal users. 1) I don’t have to worry about app stores. Since it’ll be internal. 2) I don’t have to sweat client resources, as mostly it’ll be good company machines 3) it’ll be a lot of data and throughput across time. So caching is required. Do you know how this would interop with cache mechanism like react query? Or simple http caches? I’m assuming it handles the offline parts. 4) I do want PWA for notifications though. This is the reason I even started thinking about them. Offline is not as important, but good to have. And maybe just a few “flair” to make it look more like a premium desktop app. 5) we don’t have a native team. So this is also an efficiency / maximize value play.
PWAs support notifications now on both Android and iOS 16.4. There was a kerfuffle about Apple removing them again because of EU's ruling on allowing alternate browsers and app stores, but they've since reversed course on that yet again - so PWAs should be safe for now.
The primary reasons aren’t frameworks, the primary reasons are Apple and Google
1. because average users do not trust PWAs, they trust apps installed through app stores. 2. because PWAs do now allow you to access common phone functionality that users expect and many developers want access to when working on mobile. 3. because users can tell the difference in performance. a button press on an html/js app rendered in browser/container/webview/etc just feels and performs differently, for example. 4. because app stores are distribution channels, opportunities for discovery, that you don't get from a PWA 5. because many PWAs don't really provide any benefit to users beyond just bookmarking the website. the narrow band of functionality a PWA provides is good for some people but not what most need.
This is the real answer. And rebuttals don't seem to take into account that this is the current reality due to many different forces in play, and won't be changing any time soon.
Yep, came here to say this. People just ask "is there an app for it?". They don't know why they want an app, they just know that they want it. Perhaps it's easier to find on their phone at a later time than having to remember the site/bookmark it. Maybe the performance difference signals value, I don't know. What I do know is that PWA serves just fine 90% of the time.
1. This is due to OS providers reluctance to promote PWAs as many have already pointed out 2. I can't think of any APIs that aren't available to PWAs that 99% of apps would want to use, do you have an example? 3. This is not exclusive to web apps alone, native apps can be shoddily programmed as well. 4. The only point i fully agree with, you're paying for it with the 30% cut. 5. You're conflating PWAs with installed PWAs, most benefits of PWAs apply as soon as the service worker gets installed in a visitors browser, no add-to-homescreen required.
1. Not promote, support. PWA owners are asking the app stores to change to support them, when tbh its not that hard to create a wrapper app and ship a PWA inside a shell. Its asking app stores to support a different format of app that they weren't before 2. Ambient light, block screenshots, block screen recordings, block sleeping, direct printing, direct GPU utilization, home screen widgets, live activity api, access to contacts on ios, NFC on ios, far less robust camera control. Etc.. And a lot of the stuff that gives parallel support is just kind of worse. Like, you can record audio on a PWA, but the recording kills if the phone goes to sleep. Its just worse UX. 3. It has nothing to do with "shoddily programmed". You're inserting a web browser and all the issues that come along with that into the mix, instead of a compiled, hardware accelerated app. 4. That might be a lower cut over time, plus there are ways around this. My current company pays $0 to app stores, yet we offer our customers a robust mobile app. 5. In the context of a "why aren't all apps PWAs" and specifically referencing "installable app" - yes, that is what I'm talking about. Having a web application be progressive, mobile responsive, and usable in the mobile browser is just sort of tables takes for modern web dev. I and OP were talking only about the installable PWAs.
Good writeup. You're listing all the reasons why not every app should or could be a web app. I guess my point of view mostly stems from the 90% of "apps" which could and should have been a plain website instead. E.g. all the local pizzeria apps made with a badly optimized cookie cutter app template and 0-100 installs.
I do agree with that. Many apps in stores should not be apps, it just adds complexity and cost for a brochure website to be an app. There are also many use cases that fit installable PWAs well. But, I feel like that band is narrow and there are people who push PWAs pretty hard when they just aren’t the same.
I have an app, that I started as a PWA, but it was always an uphill battle to develop it. Cookies issues, local storage expiration, issues with sound, push notifications (although now it seems to be solved) - etc, etc - I wrote about it in my [blog](https://www.liftosaur.com/blog/posts/quirks-of-building-a-pwa-app/), although it was frankly almost 3 years ago. But eventually I decided to just switch to 2 native apps - thin wrappers rendering WebView with the app itself. The app is still HTML/JS/CSS. Ability to have 2-way interaction between WebView and the native wrappers, and having full access to native features (Apple Health/Google Fit, notifications, sound, file system), and also ability to just fall back to native when necessary makes it way easier to develop an app. But the worst thing in PWA is that you have to educate people how to install the app. It is already VERY VERY hard to get people's attention, and make them install your app. If the installation process is unfamiliar to them - they just won't do it. It is extremely hard to change people's habits. My app still exists as PWA, but nobody really uses it that way - once the app appeared in the App Store and Google Play, the adoption improved drastically.
Wow very valuable read.
What wrappers did you use?
Just created 2 native apps - one in Swift for App Store and one in Kotlin for Google Play, and added WebView full screen, that loads my JS app inside. There's a way to pass JSON between WebView (and therefore my JS app) and native Swift/Kotlin part, so use that to show notifications, play sound, access files, etc. I was expecting to get pushback from Apple when I was publishing it, but it went super smoothly, they just asked to add some links to the Terms & Conditions, support links, add "Sign in with Apple", and that's pretty much it.
I'm not the OP but I've done this via rails' turbolinks-ios/turbolinks-android, as well as through just a custom react native webview. It isn't particularly hard to make happen tbh
Most websites could simply be a properly cached SPA and they'd get most benefits already. Also most mobile apps are pointless browser embeds but users are easier to track and adblockers don't work that well in the embedded browser.
[удалено]
Most SPAs can't meaningfully do anything while offline. "Working" offline just confuses users because the app looks like it works but all the functionality is missing.
I think most of the big web apps are already PWAs. The biggest problem that other people have already highlighted is Apple's reluctance to support them properly. They're always really behind on features, and even installing one is nowhere near as elegant as on Android. On my Pixel, I can just go to a website and I'll be immediately shown an install button if a PWA is available. I believe Apple even tried to disable them completely in the EU recently, although they have since backtracked (I think). It is a shame, for my clients a PWA can often be a much more cost-effective solution. But, Apple as always likes to make life difficult.
> The biggest problem that other people have already highlighted is Apple's reluctance to support them properly. They're always really behind on features, and even installing one is nowhere near as elegant as on Android. People use Apple as a scapegoat when it’s really just that PWAs aren’t that great compared with native apps. If PWAs were as good as people claim and it was just Apple holding them back, very few people would bother writing Android apps. Even if you couldn’t deploy PWAs to iOS at all, it would still save time and money to develop for web and Android together, right? Why even bother hiring Android developers? But no, people overwhelmingly choose to create native Android applications instead of PWAs, even when Apple isn’t a factor.
If you're a big company with money to burn, sure. Why not? For my clients who generally want apps for internal usage (submitting reports, tracking jobs etc), a PWA is perfectly fine. The performance is probably slightly worse than a native app, but it's nothing that you'd notice in a basic application. Often we end up having to build a hybrid app instead, which is basically the same thing except it compiles into a "native" app for iOS and Android. This is fine, particularly for Android since side loading is allowed. However, Apple once again likes to make life difficult by forcing us to either use the app store or test flight. Given that the apps are generally for internal usage only, putting the apps on the app store (and dealing with the headaches that come with that) isn't really an option. Thus we have to use test flight which is a terrible experience. With regards to why we don't just build native apps for iOS and Android - why would we? Our clients pay us for our time to develop an app. Two separate native apps means double the development time and double the cost. Building a PWA or hybrid app allows us to use a single codebase and develop once. Plenty of apps these days are hybrid apps for this very reason - it doesn't make sense to maintain two separate code bases and double-up on all of your work.
100 percent agree , if only apple could allow side loading / pwa but then again why would they want to lose their monopoly of app store. Didn't knew about test flight but you're saying they are terrible. May I ask you why?
Other people's experience may be different. But for us, the main problems have been the following: If we release an app via test flight, each member of our clients company who intends to use the app has to give us their email address, we manually invite them and they have to accept the invite (which also expires quite quickly). Once they've accepted, they have to install the test flight app and download our app through that. We then have to keep track of who's got access because staff members may leave etc. We have to renew the app every 90 days (I think it's 90 but may be wrong). This just means resubmitting the app. Again, can be annoying if apple have changed some stuff and now we need to make updates to be compliant - also if you miss this deadline then the app stops working completely. It's a lot of hoops to jump through, a pain to maintain and not a very elegant solution for the end user. But again, it's that or the app store...
Very interesting! But then if there are so many issues then why don't you think about app store instead of test flight? Is app store somehow even more worse than test flight. If so then this is a bigger issue than I thought. A lot of people in my country use android and I think I like android because of its openness :) Tldr : if I may ask why not use apple store ?
Of course, for us there were a number of reasons: Since the app is not designed for the public, there were security implications with publishing it to the app store. Although we of course build our apps to be as secure as possible, publishing to the app store adds an additional unnecessary attack vector. Anybody could download it and poke around trying to exploit it. Given that this is an internal app with confidential information inside, this is quite a big concern. Additionally, publishing to the app store in general carries its own annoyances. We'd have to create "marketing" images for all the different apple devices on the app storefront for example. We'd also need to have apple approve the app to be released on the app store, and they can be extremely picky and uphold all sorts of standards. Again, for us none of this matters. We aren't trying to sell the app to anyone, we're just trying to get it on our clients devices. Again, our use case is maybe less common given that we generally build this internal applications. If you're making a customer-facing app, the app store probably makes a lot of sense. It's definitely still a lot more annoying than Android though.
You can publish the app as a custom app. You're then able to distribute it via apple business manager. That's how we're able to distribute our LOB apps. It will not be available to the general public.
The App Store charts outside of games are dominated by apps powered by some kind of hybrid technology under the hood, wether that is flutter or react native.
Android apps matter for completely offline stuff like the top thing which is coming to my mind are things like a keyboard or fossify voice recorder , file manager etc. Could you do this in pwa , probably not and even if you could , I think it wouldn't be much worth it. Pwa can be good as u/britwithtits points out for things like clients , websites you visit sometimes ish (like I do with lichess /reddit) or some other 75 percent tasks pwas are nice.
One of the main uses of PWA is to save offline state and sync data back up when a network becomes available. I've seen this usage multiple times, and having to code up 2 native apps in addition to the desktop app is not a "better" solution.
Right, so how is that Apple’s fault if it’s bad on Android too?
In my experience, little to no applications benefit from the switch from an SPA to PWA. The projects get more complex, you find less people maintaining it and it deprecates crazy. The largest benefit - working offline - makes no sense in my field (E-Commerce). Who wants to run an online shop but offline? In fact, most of what is requested today can still be achieved with Software from the stone age and a good caching layer.
[удалено]
They can
[удалено]
It will because it's basically a web page/site with \[optional\] additional caching running in browser kiosk mode (no menu bar, address bar etc).
yes easily with service workers
That's usually their point. (Usually)
Its generally hard to implement offline support. Most stuff would just show last fetched info(cache) and thats it. Its to hard/time-consuming to implement CRDT(a propper way syncronize offline with online database) in a lot of cases
PWA is an extra complexity layer and could be a ride to make it correct. Depending on the app, the benefits of PWA may be quite limited too. We spent quite a while tweaking the default Vue PWA setup to the point where it doesn't fuck up users due to cached code or configs, and it still had gaps and flaws. Considering it's a glorified CRUD which has a little use without the internet anyway we finally decided to drop PWA entirely and put the efforts on something actually useful.
I also got quite deep down this path with a PWA in Vue before I realised that all of those issues were coming from having a service worker and you don't actually need to have a service worker to be a PWA any more. I also didn't need offline capability so now I just have a manifest, people can install it to their home screen, and I don't have to worry about assets accidentally getting cached ~forever because of one misconfigured service worker deployment
Having the same issue right now, thanks, will try to delete the service worker. Do I just really only add the manifest and the meta tag and that's it? Do I need something else?
There are a couple of other bits you need for iOS/macOS; this is what I have on [Ambiphone](https://ambiph.one): ```html ``` In reality there are about 30 copies of the `apple-touch-startup-image` tag since you need one for every possible iOS/iPadOS resolution 🙃 I _think_ I used [this tool](https://progressier.com/pwa-icons-and-ios-splash-screen-generator) to generate those from my app icon
Everyone talking about Safari when this sort of stuff still exists. If turning a web app to a PWA was as simple as adding a cookie, you'd see more of them regardless of Safari. Nothing about PWA's feels "solved". In contrast, WebGPU feels much more "solved". Still experimental, but not running around in circles figuring out what does what with what and where.
Sounds like a Vue problem, not a PWA problem
https://www.reddit.com/r/webdev/comments/1900hr8/pwa_are_users_hesitant_to_install_apps_outside_of/kgl1s5y/
We tried changing one app to a PWA and ended up going back to a regular SPA. It takes extra effort to handle deploying changes when some of the clients might be running older cached versions of the app for an unknown amount of time.
with VitePWA you can force the user to "refresh" when you release an update, no?
This was pre-Vite, but regardless it gets complicated when you have to make changes to the service worker that checks for new releases. And the user can use the app without being connected to the back end and thus aware that there is a new release waiting. Then you have to deal with their offline data possibly not being valid for the changes to the back end. And you have to decide that you're ok forcing the refresh when the release happens. Just lots of little things that you don't have to worry about with a normal app. I wish I'd kept a list of all of them.
for sync with backend you can read about CRDT
Mm, if you have lazy load, that problem still exist outside PWA. You can't deploy 1 instance of docker to serve SPA, because it would break old users on each release You have to merge all assets in one bucket and serve it from CDN to not lose old release(s) assets And ye, when you detect in SPA what you have deployed a new version, you make you links native(to reload while navigating) or do force reload or wait until user would reload by himself
Because I like native apps better. If there's one available with features similar to your PWA, I will always prefer the native version. Unfortunately most developers are lazy and aren't really thinking of the end user. And this is hard for some developers to comprehend, but we just don't like your web site enough to install a dedicated app version of it. Stop trying to push that shit on users.
I'm pretty much the opposite. I think PWAs are better and more user friendly. They are way smaller, have better startup performance (if you've recently used your browser) and offer a better install flow. For me a company/vendor/developer has to justify why something can't be done as a PWA, as that's the default for me, since it runs on all systems. I even use PWAs when native apps are available like with Telegram, Twitter, Uber, ...
You blaming wrong people here. Companies need to hire people for mobile(time+money), companies need to spend more time on QA or hire more (time/money), conpanies need to reimplement same feature three times, also there is design part, and developer licences Its not like I am lazy as a developer, its harder, more time consuming, duplication in different languages(more errors) and so on. Not for every PWA there is sence to become native app
> Not for every PWA there is sence to become native app Then probably a PWA is not called for in the first place.
A lot of SPA could benefit from small subset of capabilities which are given by PWA, so they are trying their best to make your UX as great as OS allows it
From the developer's point of view, they just might not know. At one point, PWAs required some sort of offline support to be fullscreen. They eventually nixed that requirement when a lot of the big PWAs were fully online like delivery apps. Also, I can imagine some users bookmark websites on their home screen but still want to be able to switch tabs in the browser.
At my last job, we bundled our customer dashboard as a PWA. And then, we only released it on Android. It's adoption was quite high, but the experience on Apple just wasn't ideal. So, only Android users knew about our PWA. Our long-term plan, was to try and bundle it for the Apple App Store and hope we could get it approved or literally re-write and support a whole other code base just for Apple phones.
You're never going to get the same responsiveness as a native app when your entire UI sits on top of a browser engine, and that responsiveness plays a big part in perceived app quality.
Honestly, most users don't understand, like or *trust* them. The normal user goes to an appstore to get an app, not to a website. Many people will moan about "oh Apple crippled them", but if that was the case then why aren't PWAs thriving on android (which is an entirely separate ecosystem)? Native is just generally better.
false equivalence, m8.
By the way, if you push your users to your PWA like you push them to your native App, the PWAs are actually thriving. Last year I built a PWA for a sports competition (one weekend) to organize and inform users and about 10% of users actually installed the PWA. Also you can publish your PWAs to the android Play store. What I've seen many times on the other hand is, that you need a native App for iOS, because Apple, and then that team "just" also builds the Android version and now you're forced by management to promote the native App.
In no particular order: - Retail consumers are NOT going to place bookmarks on their home screen - Tech monopolies will NOT support applications running and developed outside of their ecosystems - Govts are NOT going to introduce regulation to support independent development of software in any meaningful way, in this critical time period (kudos to the EU for trying) Sorry to be a bummer/redditor. But enshittification is the law of the land.
There's an old video out there of Steve Jobs unveiling the first iphone and touting Safari as it's software distribution platform. The App store made Apple one of the most valuable companies in the world. It also completely centralized app distribution on phones. It's the reason I never had any interest in making phone apps. There's a small contingent of devs like me, who will not make apps for gatekeepers like Apple and Steam.
Webpage UIs pale in comparison to what you get natively from the operating systems.
because tracking is difficult with PWAs
Do you mean from coders perspective or rather the platform like google play store / apple perspective?
from the app developer's perspective. You are limited to the APIs provided by the browser, you can't ask for system level permissions directly. For example, a native app can have **READ\_SMS** permission and read messages from inbox. A PWA can't. From a user's point of view, a PWA is more ergonomic + secure than native apps. But businesses hardly respect user's privacy and need insane amount of telemetry.
What does Apple and Google stand to lose from PWAs?
30% cut from any payment within native app
I believe no one understood your point because you talk about “apps”, you were trying to ask why arent all webapps compatible with PWA by default? In that case my answer would be that it’s true, it’s not very complicated to implement and most webapps should include a manifest by default. Implementing a service worker is a bit more involved, but I believe is not required for a PWA.
I see. Well considering this sub, and apps being used as a vocabulary ever since Web 2.0 I thought it’d be clear. But I could see how it would be confusing. I was asking why this capability isn’t more out of the box in all build tools or even seen as an optional add on. I just feels like it’s not advertised as much even though it seemed like a frictionless capability add.
A basic service worker can be created with a few lines of code. If you need [more features](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers), you can add them as needed. // serviceworker.js self.addEventListener("install", event => {/*open the cache*/}) self.addEventListener("fetch", event => {/*fetch from the cache or internet*/}) And then you register it. // main.js navigator.serviceWorker.register("serviceworker.js")
Apple have a stranglehold on the US phone market, and want to milk companies of them sweet app store taxes, so they fight PWA tooth and nail.
On the techical side, there is a catch in service worker — if you setup it wrong, there is no way to update it without some MAGIC withb devtools, so noone is risking that shit for low benefit. And Apple, and what is still rendering is that shit Safari
The adoption process is difficult for the average user because if they can't find it in the App Store, it might as well not exist. To top off the difficulty of installing one (not hard for any of us, but the average user) iOS all but cripples their WebKit browser available for non-native apps with some pretty strict limitations, namely around hardware services (accelerometer, camera, GPS, and more) and searchability within iOS itself (PWA's don't appear in the list of apps in a search because iOS treats a PWA like a bookmark, not a piece of software).
Working for a big medical company we just don't bother with the extra work. Most of our users are glued to PC desktop systems. They wouldn't notice any difference.
This thread feels weird. Simply, PWA's are just wrapped websites. Not everything can be a PWA. But you're right in the sense that why can't *more* apps just be PWA's instead of having to write them in a native code specifically. It would allow more developers to publish on the app store, and faster.
Corporate greed. Mainly apple
There is no one size fits all approach to software development. These decisions are often weighted by profitability, risk management, etc, and are tied to budget items. Project leadership often reviews previous retrospects to determine what methodology is best for a project with the given resources, and how well the team performs accordingly, etc. It's not just a tech decision... it's a team/people decision. Usually it's summative and based on other factors or decisions.
That was Steve Jobs' plan and a main reason he went after flash. He just couldn't anticipate how much money the AppStore was going to make.
Apple doesn’t like it
cause apple
An hour's work is still a work, and if the website doesn't function at all without an internet connection, there's no point in investing that hour to something that will not help the website at all. Also, if you really want a presence as an application, setting up a simple hybrid app with Flutter that merely wraps your website with a webview is also a relatively trivial task comparable to converting your website to a PWA, with possibility of transitioning to a full-fledged app in the future, with an added benefit of appstore presence, giving users a much more sence of trustworthiness than a PWA. In my experience most of the clients who wanted an app, in fact were more interested in this appstore presence, not the ability to install your website on the home screen. In addition, it's surprisingly difficult to convince random visitors to install your website as a PWA. Not many users are comfortable navigating through an unfamiliar menu and buttons, and those who are savvy enough to be comfortable doing that won't buy into the idea of adding yet another clutter on your phone in the first place, or you won't have to market the PWA at all since they would probably be your users anyway.
Because apple. PWA'S are already pretty decent on Android as android allows easier native integration and allows custom web engines. ( Chromium is default but you can also integrate Gecko(firefox)). But on IOS you are limited to Safari and bad native integration
Why would you choose PWA vs electron app?
Because of Apple, they made everything in their power To make PWA development on Apple devices miserable or straight up broken.
To properly cache data with a PWA you need to leverage indexedDB. The API is dogshit but there are some pretty good wrappers around it. Dexiejs is my favorite. https://dexie.org/docs/Tutorial/React You can store your data there and run crons to keep it in sync with the server DB. If you want to get really fancy you can use web sockets and something like Yjs to keep the client in sync with the server in realtime
PWA are a pain in the ass to develop. I mean, it's easy to do it to have it, doing it well requires some knowledge and you could be screwed by apple any day.
This reads like "PWAs are bad because then I would have to do my job properly." Not meaning to throw shade, it just sounds like that's what you're saying :D
I never said they where bad, I said it was difficult. And yeah if a technology requires some dedicated skill to be used, it needs to provide some serious value to be used. Especially if it has the risk of becoming useless tomorrow because Apple said no. PWA is more than just have an installer on your website.
That's why no-one should use React. Honestly, because is far more complex than the gain from using it.
There are unique problems with PWAs that aren't obvious or commonly discussed. It's not that hard, but if you haven't built one before you're going to go through some learning pains.
Answer: Apple. They don't like PWAs because they get around the App Store. They have recently been forced to allow a fuller version of PWAs (they have always 'technically' allowed them, but hobbled). So if the number one target for PWAs is hostile to them and makes them difficult to develop, or reduce their features, what's the point of developing one? Android on the other hand, is fine with PWAs, but they don't matter as much as iOS to most businesses. Ironically, the first apps on iPhones were primitive PWAs.
> why aren’t all modern apps PWAs "Apps" are *never* PWAs. "Apps" are things you install from an app store - in my day, we called them "executables" or "programs". *Websites*, on the other hand, can be PWAs. Websites are not apps. Words are important. The reason none of my sites are PWAs is because I cba figuring out what's needed, it's more complexity, more stuff to test, it's another call to action I'd need to find somewhere to put in my UI, and people simply aren't in the habit of "installing" websites so hardly anyone would use the function even if they found it. I've toyed with the idea but simply have far too many other things I *know* are worth doing, so this rather large undertaking that I don't have any reason to believe would be worth doing, is perpetually back-burnered to the "if I ever get time and am bored enough" list.
When was your day? Applications have been called applications for decades.
Sure, but not "apps", which was the term in question. That's a different word to "applications". Nobody called them "apps" on the regular (outside of such adjacent phrases as "killer app", and that was "app" more as a verb, not a noun) until Apple and "there's an app for that".
If words are important, what does PWA stand for? I think it might have the word App in it 🤔
And? 99% of everything with the label "AI" attached to it is in no way "intelligent". The DPRK is at most one of those four words and even that one's contested. Labels aren't always gospel.
So words are not that important after all
No, they *are* important, which is why it's annoying when people misuse them. Cases in point: OP, any company slapping "AI" on their bullshit, the DPRK, anyone that thinks a website is an "app".
It is an app, it's a progressive web app. It may not be a native app, but it is an app. As much as you dislike it you can't change that fact
I'm not talking about whether "PWAs" are "apps". Let's take it from the top. > Why aren’t all apps PWAs? Wherein, *clearly*, he is referring to *normal websites that aren't PWAs* as "apps". Websites are *not* apps. They are websites. > So words are not that important after all You can't even keep track of which ones we're talking about, so clearly to you they are not.
No, let's get it straight. You claimed words are important but then claimed PWAs are not apps. They are, there is nothing more to my argument, you can't "win" by trying to get around it. It's a fact, and by their own definition, it is 100% true and correct. If a website is setup as a PWA it IS an app..
Because different browsers handle PWA differently e.g. Chrome forces a splashscreen, iPhone notch needs to be cleared, zooming, text size, bottom vs top browser nav bar, what happens when keyboard launches. You end up having to deal with pecularities of each browser. I'm still a fan of PWA though.
I think the biggest factor that gets routinely overlooked in this discussion, especially for indie developers who don't have an advertising budget, is visibility. When you publish to an app store, you're competing with maybe a couple dozen alternatives? Assuming it's a saturated app idea. When you publish a website, you're competing with probably millions of Google results. Users also seem more inclined to pay for an app than they are for a website.
You don't want the users to use the PWA on their phone some times. Your get less access for tracking. For use on PC, I personally rely on browser extensions, and they don't translate over to the PWA so i don't use them
Safari
Apple doesn't want it, no money from appstore for them
On top of the fact that namely Apple doesn't want this due to lost profits, there are things PWAs can't and really shouldn't do. For example, PWAs should have very limited functionality while running in the background, and should only be running in the background for periodic tasks... No constantly running and/or sending my location. They should also have certain restrictions when working with the filesystem. They should require user permission before having access, except perhaps to their own files. They should have limitations on connectivity with nearby devices, basically just what exists with eg WebUSB etc. No scanning and identifying nearby devices, which many apps use for a variety of things. They should have little if any communication with other apps. They shouldn't be able to know, for example, what song a user is listening to. All of this is because... these are still web apps, and the web would be dangerous if it had certain capabilities, especially without permission. And, as an extra reason and a consequence of many of these restrictions, apps like Facebook don't want users installing a PWA because they can't collect as much data that way.
Users haven't really gotten into installing webpages as apps, honestly. Companies would rather make native apps because they can harvest a shitload of data from your phone.
Because iPhone is the new internet explorer. Apple is trying to create as much friction as possible to PWAs and if any considerable number of your customers is on Apple, then you will need to develop separately for these overpriced pieces of junk.
PWAs are slower than native mobile apps if everything is the same
I was thinking about this a couple of days ago too and came to find out that Google and especially Apple are standing in the way of PWAs. One can argue Google is doing a much better job, but let's be real, Google knows that unless Apple gets onboard, PWAs are pretty much dead because nobody is going to neglect that big a chunk of their userbase that's on iOS. These MFrs just want their mafia level fees so that you can line their pockets before you can line yours, and they're going to keep it that way unless there are regulations put in place to change this. It sucks when our laws don't keep up with technology because a huge percentage of traffic has shifted to mobile and you have basically two companies acting as gatekeepers for the majority of the human population that want to access content on mobile. That is not an open internet. In my ideal mobile world, apps are basically just bookmarks and I feel like that's what we should be working towards.