PWAs in App Stores
web.dev
web.dev
The web stack (html/css/js/http) is one of the most impressive feats of invention by humanity. We have this one stack and toolkit that run on everything from a desktop computer down to a cheap (as little as 100$) mobile phone. It's free with no payments for access or deployment, and at the bottom end basic enough that a child can pick it up. But capable of building incredible professional experiences (see Figma or onShape, seriously they are incredible).
As a sole developer I can build something with a single code base for mobile (both web and installable), and desktop (again both web and installable). The breadth of tooling available is incredible.
The OP is about PWAbuilder, there are alternatives. I like the combination of Capacitor (from the Ionic Framework team) and Native Script. It lets you extent your installable version of the app with additional native capability, all while staying mostly in a JS environment.
The complaints about PWA being poor are, in my view, two fold. One, the support for them on iOS has be atrocious until recently, but also there are a lot of poorly written webapps. That is actually a testament to the accessibility of the platform. Look past that and you see what it is truly capable of.
We need to stop this silly gate keeping, it's frankly ridiculous.
Edit: since I started writing the negative posts have them voted down the page. Looking more positive now.
Edit 2: While I have your attention, if you care about PWAs and consumer choice of web engines on mobile, go support the OWA (Open Web Advocacy - https://open-web-advocacy.org/donate/). They are there to represent us and push for move choice and support. They are turning up and presenting the evidence needed to ensure the large players open up their platforms.
OK, perhaps we need to step back from discussing their capabilities and flaws in a technical sense, but we seriously do need to discuss the capabilities of the average user and how allowing PWAs to bypass the app store review process is likely to be harmful to them.
If any random webpage can get them to install something which has access to things like notification apis, location etc, we're in for a world (more) privacy invasions, scams and just people whose phones become unusable, beeping, message-laden messes.
Yes, there are problems with the app store model, but lets not pretend just bypassing it without a further thought about the impact is a great plan.
(And yes, I am aware this article is about a tool for including PWAs in app stores. This is great, if you want to do that, go for it!)
We have at least two kinds of users. One is the non-technical user you are talking about. The other is a braver, more independent, and maybe even technically literate user who at least reads the prompts before granting requested permissions. One group of users wants the comfort of knowing that a big tech company is keeping them safe by keeping a close eye on the place where they get their apps from. The other group of users wants to enjoy the new project Fugu apis available on Chromium-based browsers.
Why is the first group of users attended to, and the second one ignored? Why not allow two app stores — one, installed by default and guarded and taxed by Apple, and the other for the projects that want to take a different route — and let the user choose?
But it's not users, it's developers.
Specifically below we have people saying that as a developer they don't want to have to jump through hoops, nor pay the tax. And as a developer I can empathise.
But as a tech savvy user I don't actually have anything that makes me desire PWAs. There's no driver there for me, I don't care about the new project fugu apis available on Chromium-based browsers, I can probably get a native app that does the thing I want, it's developers that care about that stuff. Stuff they could already do if they weren't trying to bypass the app store infrastructure.
So even among tech savvy users, the number of users who care about installing from outside of the app store ecosystem is not 100%.
> Why is the first group of users attended to, and the second one ignored?
Group 1 is a lot larger, they are the mainstream audience and the tech-savvy-but-doesn't-care-specifically-for-PWAs audience. Not only are they the people that the device vendors want to target, they are the people that the nefarious would-be PWA writers want to target too.
> and let the user choose?
"Press this button, this button and this button to get the free shiny! Don't worry about those silly warnings, they just don't want you having any fun!"
"Hi, is this Apple? My phone is an unusable pile of shite and somehow all my money is gone"
Storage space? The knowledge that the app you installed runs inside a browser sandbox, with certain safety guarantees (I've never quite learnt what they are; but apparently they exist).
Personally, I would be much happier installing PWAs than native apps. I know PWAs are effectively just websites. I know what to expect from websites. I know I can remove them cleanly if I want to. I have no idea what to expect from native apps.
> "Press this button, this button and this button to get the free shiny! Don't worry about those silly warnings, they just don't want you having any fun!" – "Hi, is this Apple? My phone is an unusable pile of shite and somehow all my money is gone"
Is this a problem on Android or on Windows? Do people besiege Google (or Samsung, or Microsoft) complaining that their devices have become unusable and that their money has evaporated because they have installed something on their device? Is this, ultimately, Apple's problem (you can still install things on a Mac bypassing the app store)?
> Personally, I would be much happier installing PWAs than native apps. I know PWAs are effectively just websites. I know what to expect from websites. I know I can remove them cleanly if I want to. I have no idea what to expect from native apps.
You have the same with UWP apps
Do you?
For example, Chrome allows MIDI Device enumeration without permission, and it's used in fingerprinting.
The number of APIs available to web sites (especially in Chrome) will soon rival the number of APIs available to native apps.
People do indeed buy tablets because they’re easier and safer, particularly for older, less savvy relatives or kids.
Undermining that is likely to hurt the market.
As for the other - I know what to expect from a native app, mobile platforms particularly have similar guarantees and expectations, and I know someone else has had eyes on it. Those guarantees you’re talking about aren’t necessarily very meaningful in the face of social engineering - a PWA may not be able to take over your device but they could still be great avenues for phishing attacks etc.
Yes and no.
The "no" part comes from people trying to twist a system designed for displaying static text into an application platform. And as an application platform it sucks. It's one of the most inefficient, slow, resource hungry app platforms that humanity has ever devised.
As a free somewhat open cross-platform means for information exchange, it really is unparalled.
Is it? JavaScript interpreters are crazy fast, almost comparable to compiled languages. The layout engines are powerful and efficient. They support extremely-optimized networking protocols and media formats.
It's not (currently) a great platform for high-poly 3D rendering and such, but who knows what the future holds with wasm and WebGPU.
Browsers do use a lot of memory, but so did Java, Flash, Shockwave, Silverlight, etc.
It is. None of what you write is either fast or efficient. Especially not the layout engine that does a re-layout and a re-paint as soon as you look at it sideways
I always say when people talk about efficiency: There's a reason you can't animate height: auto or a list item efficiently without hacks. As is the reason why opacity changes are outright banned on lower-end devices like TVs.
The limitations of this system designed to display static text are such that a non-issue like quickly displaying scrolling text becomes a problem: https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
You mean the fastest libraries like ivi use Virtual DOM ;) : https://twitter.com/RyanCarniato/status/1636120238638137344
There was no real equivalent to this before. In corporate environments, this was often the Java stack that was used and it was often a really painful experience.
PWAs are the same for Mobile, the current experience of developing mobile apps using the native SDKs is really subpar and it is expensive. PWAs will become the default for mobile apps because, in most cases, there's no reason to go through the pain and cost of creating native mobile apps.
Unless you need, you know, actual performance, fast animations or even things like proper controls which the web has none of.
The original web memo by Tim Berners-Lee defined "a document" as text only content that could be displayed on a 240x80 character display. Images were defined as an optional extra few people would be able to access. I'm going to guess you want a web that does a bit more than that.
In which case.. Tim Berners-Lee's memo suggests "Live Links". His proposal was that the web should have "documents" that are generated per request aka serverside rendering. He went further and suggested "If one sacrifices portability, it is possible so make following a link fire up a special application, so that diagnostic programs, for example, could be linked directly into the maintenance guide." To me that sounds a lot like a clientside app. At the time (1989) I imagine he meant that a link in a page would execute a local app, but it turns out we just found a different (better?) approach.
The memo is really interesting - https://www.w3.org/History/1989/proposal.html - TBL was incredibly insightful.
How dare it learn how to talk, walk eat solid foods and grow bigger!
For sure. That ship sailed 25 years ago, when XMLHTTPRequest was invented.
Those platforms exist: desktop and mobile. People are so enamoured with the web and/or have no experience outside the web, and so don't know how insanely more performant almost literally everything outside the web is.
I'm old enough to remember the same arguments being made when people started using C rather than ASM.
With that attitude you get Microsoft officially advertising their new Teams version that takes 9 seconds to show less than 1kb of text (3 seconds just to show the splashscreen).
Yes, we are running what essentially amounts to supercomputers. Why is it then that Slack still requires 20% CPU to show an animated emoji? Or that Matrix spikes to 60% CPU when scrolling through a largely empty channel? Or...
I will gladly take every disadvantage of the web to deliver my products to every platform. The alternative is not shipping to MacOS and Linux systems.
I bootstrapped a Ionic project the other day and had something running right after without knowing anything about it some hours before, compiling as a pwa and native apps using their respective toolchain.
It felt like I was replacing Bootstrap components with Ionic's and was able to transfer all my Vue knowledge.
Also the docs are great nowadays, way less Angular centric than before.
Flutter's overall DX experience is so incredible that it is in its own league. But the ecosystem is still pretty limited, there are performance issues as well.
Web (HTML, CSS, JS) has been so optimised over the past two decades and it has such a HUGE ecosystem and libraries that it becomes almost unavoidable choice if coupled with Capacitor et.el.
Imagine d3.js or some of the amazing visualisation libraries. Hard to get the same deal on ReactNative or Flutter with same breadth and robustness.
You can already switch to it by adding this flag, "--enable-impeller". It's waaay smoother and worth giving a shot, their demo on YT is highly suggested.
But tbh, that's not my issue.
Fun.
Figma is anything but incredible. I have one Figma file that I always open. Every day or every couple of days. Every single time it loads up ~100 MB of God-knows-what and takes ~20 s before showing anything useful to me. Not to mention the added loading time if you don't have Chrome open.
So no, it is not "incredible". It is the slowest app I use. Doesn't put much confidence into me regarding the entire PWA system.
But yeah. I wish people stopped waving Figma and VSCode around as shining examples of web tech. They are two outlier built at incredible expense and effort.
[1] https://www.figma.com/blog/building-a-professional-design-to...
Ok, so take a look at photopea.com, basically built by one guy.
The point is the web is capable of these things, sometime with a large team sometime with a tiny one.
The thing is... when you say "the web is capable", keep in mind that it's always one or two of the following:
- it's an insane effort to get something working (VS Code, Figma)
- it's not using web tech, not really, but desktop tech that is usually 5-10 years behind the actual desktop tech (WebGL in Figma and Photopea, Canvas in Google Docs)
And even there it's still multiple unresolved issues like font rendering, accessibility and a plethora of others.
Edit: Speaking of Photopea: I'm always in awe of people who can not only build a complex app, but also build an entire library of controls and a design system, too. Because the web's controls are is just so, so, so poor.
Photopea is a great project and it's nice that we can build things like that, especially with tools that are familiar across a wide variety of use cases (as opposed to having to know OpenJFX, WPF/WinUI and who knows what else).
But compared to native software, there will always be a certain overhead to contend with, which may or may not be an issue: for many, it will be easy to just hand wave away the idea of needing to support netbooks with something like 4 GB of RAM, or many older machines, due to personally having better hardware.
For example, I briefly compared working with the following image (the full sized one) in Photopea in a Chromium based browser instance with no other tabs and GIMP locally: https://commons.wikimedia.org/wiki/File:Andromeda_galaxy.jpg
First, I checked the memory usage of both programs without the image open:
Photopea 304 MB
GIMP 110 MB
Photopea 1004 MB
GIMP 396 MB
Photopea 1340 MB
GIMP 474 MB
Otherwise we'll end up in a point where it won't be possible to reasonably open 10 IDE instances at once, or run all of your Electron based software in parallel (e.g. some editors, Postman for API testing, Discord/Slack for chatting, Figma for mockups, Lens for Kubernetes or whatever else people are using, possibly even Terminals built on web tech eventually).
This isn't a great comparison because you're counting the fixed overhead of the browser as well. If you have three tabs open with other images, it won't take 3x the memory.
Personally, I virtually always have a Chrome instance running on my desktop, so the overhead is incurred either way.
In Electron there is fixed overhead for running Chromium for each program, but it's a stripped-down instance without all the bells-and-whistles of a browser, so it's not as high as it would be for a full browser.
This is a good point, my bad. Most people would open multiple images in the same piece of software (though it seemed like more memory was used in comparison to GIMP anyways). A more realistic take on my part would be running X different pieces of Electron based software, which would use Y% more memory than native alternatives.
That's not to say that there can't be good and comparatively efficient software like that out there, Visual Studio Code is a good example of something that actually performs pretty well! But that's mostly because of the huge amount of engineering that MS put into it, most other similar approaches like Brackets or Atom were plagued by sluggishness.
And if the native software is a bloated monstrosity? Naggy, cloud-syncing, process-spamming, privacy-invading, background-lurking garbage? Don't give native apps a pass for being native.
I ditched all google software from my PC after it acted like malware, re-installing itself after I removed it several times. And doing bizarre things like scanning my drive with a "software reporting tool" which thrashed the hell out of my drive. That's the only reason I found it because my hard drive was mechanical and wouldn't stop grinding.
https://support.google.com/chrome/thread/29314533/can-we-ple...
Then those pieces of software probably should be excluded from your candidates for what to run on your machine.
For example, GIMP, LibreOffice, VLC, Blender, Audacity, Kdenlive, XnView MP, OBS, PeaZip, Thunderbird and others have very little in the way of the issues you've mentioned.
That's not to say that they'll always be the most capable options out there, but for most folks they'll be entirely sufficient.
Then it should be criticised as well.
The device integration criterion includes achieving a full performance(be it for the UI immersiveness or processing speed).
PWA don't tick any of these, they are just an output of the dream to have universal codebase. This is a dream I share but it doesn't need to be an app in the App Store.
The only reason people make apps that don't need to be apps is to get another marketing channel through App Store distribution and another user reach channel through notifications.
We're considering building an app pretty much solely due to notifications, because our only option currently is e-mail and deliverability while good can never be perfect.
They just have to convince the user to add their PWA to the phone home screen. I guess the issue is that users hate being instructed to "install" "apps" which don't need installation to function.
You just want to use it on the web? Just so that. You get the full experience because there is no resource split between the web site and native apps.
You want to find the app in your favourite app store? It's there. Just install it.
You like the web version but want to add a shortcut to your app list? You can do that and there is enough metadata available to provide nice icons and titles.
Unless you are an owner worried about PWAs being normalized so that your tracker infested app stands out.
It won't be a "full experience". It's amazing to me that people are talking about GUI apps and keep pretending that GUI-wise the web is anywhere on the same level as anything native. I wonder why the https://open-ui.org effort exists if that is the case (because it isn't, of course).
And those almost invariably suck. A few try and invest in smooth-enough experience because customer retention affects their bottom line (e.g. Foodora is a suprisingly nice app), but those are not enough to say "You get the full experience".
It does if you enjoy eating and paying rent, and don't like the only real alternative (i.e., cramming it full of advertising).
I wrote a longer response but decided to scrap it. The behaviors and expectations are different than you might expect from a pure engineering POV. Its not just sales and marketing. For better or worse, people want to interact with companies' apps on their phone via installing something "trusted" through their appropriate app store. Not responsive mobile web, not even PWAs (which are difficult for people who are not tech savvy).
At my most recent exited startup, we had a web app which was mobile responsive. People asked for a mobile app. We gave them a mobile app that was simply a webview that loaded the web app. Customers loved it. We got almost no inbound from it at all for various reasons, but existing user satisfaction, engagement, etc went through the roof. They could finally "use our app on mobile" even though they always could, and we consistently pointed them to the mobile web experience to do so. This is a market full of people who are average to below average levels of tech savviness.
So no, thank you. I don’t want back into the App Store.
As a consumer, and perhaps more importantly as someone who is frequently unofficial tech support for other consumers, this is why I don't want PWA support or PWAs in generally getting any foothold on devices.
The number of notifications, icons, noises, ads, disturbances and general bullshit that an average user already has to put up with on a device is absurd. Can they be careful about what they install? In theory. Can they configure and down-regulate all these notifications? In theory. But they don't, and they won't.
Having something that appears to be able to bypass app store review is a developer wet dream but a user nightmare. Because they'll go to a website and press the buttons it tells them to, and now instead of it just being spammy bullshit that did pass the app store filter, it might be absolutely anything.
You might have honest intentions, but thousands won't, and users demonstrably can't handle it.
Actually they are just regular websites and I guess most developers who created them never consider their website PWA. Many of those "PWA" websites were built before PWA term was invented.
They work very well in my opinion. Minimal UI and they are always up to date. I do not have to download or login to any app store to use them.
For average user finding this "Install this site as an app" button is a real UX issue.
I think this rule is supposed to guard against things like packaging amazon.com into an app wrapper rather than developing a mobile-first offline-capable web app. Actual PWAs should be fine.
Google Play strongly enforce their policy about how an app cannot be something that duplicates the functionality of a website.
Example:
Years ago I wrote a simple html/js app, and published it to the Google Play store using Cordova. It was a completely self contained app and did not access the internet (although it required internet permissions to use the webview). After publishing the app, I reused much of that code and release the app as a simple website.
Google Play deleted my app because purely because the app had a similar version on a website - even the styles were slightly different between them! The reviewer ignored of my explanations and refused to reinstate my app, even after I deleted the web-version of the app.
This was a 5 star app with only positive reviews!
If I got my app deleted because it smelt like it might be a webview wrapper of a PWA, using a service that is a PWA wrapper sounds like the most risky thing ever!
Source: worked on supporting this capability.
[1] https://developers.google.com/codelabs/pwa-in-play#0 [2] https://www.youtube.com/watch?v=ddbHp8tGBwQ
When I raised an appeal, and proved to them how it was a self contained app, they told me an app cannot be a webview of a website.
When I deleted the website they told me that my app was just a webview of (which it wasn't), and then reappealed, they told me an app cannot be a webview of a website, and deleted my app.
So, the lesson here is: Submitting an app that renders using a webview is a gamble and that Google reviewers don't actually review your app.
I have a PWA (https://journalisticapp.com) published in the PlayStore as TWA (https://play.google.com/store/apps/details?id=com.journalist...) via bubblewrap. It has many users and people love it, many don't realize it is not a native app. But I struggle since a long time to find a good way to monetize it.
First of all, there is no good guidance about the topic besides some clips about the Digital Goods API and it only works for recent Chrome. How do deal with users that use a different browser or an older version? Is it ok to check if the API is available and if not use Stripe? No info about that... It can be pulled off, but UX will definitely be bad or worse.
Then, there is the problem with complex backend logic and accounting, I have to deal with two scenarios, did the person use Play Billing or Stripe to purchase? What if he used Play Billing and then wants to manage their subscription in the browser or other way around? It would be amazing if either Play Billing could also handle purchases on the web, or if Stripe could detect TWAs and automatically send 15-30% to Google for doing nothing.
Also, what about testing? How can I test my Digital Goods integration if it is only available within an Android app and not in my PWA? Am I supposed to publish an app that points to my dev server?
If Google was really serious about PWAs and Trusted Web Activities I think they should allow developers to use 3rd party payment systems (in TWAs only) until all of the issues are resolved and have solutions, instead of being like "ya we don't know either, you figure it out, but you can't use Stripe". As TWAs are only a miniscule fraction of TWAs in the PlayStore it won't even make a hint of a dent into Google's revenue, but it would allow developers to seriously pursue a PWA solution over a native one and therefore allow Google to see if it is viable and worth putting serious resources into.
otherwise, very cool however the app store market monopoly is a joke. So are most of the user ratings on such stores. The beauty of PWA's is that there is no appstore or an over looking body - the internet is free!
Fixed in iOS 16.4[1].
1. https://www.izooto.com/blog/ios-safari-push-notifications#:~....
been deploying native apps cross compiled from c# with PWA interfaces to app stores for years, so they are possible, u just got to work within the guidelines.
Make sure you don't confuse HTML5 and Chrome-only non-standards.
The former is implemented by Safari to a much larger degree than people would have you believe. The latter they have no intention of implementing even if people pretend they are standards.
2. There's Android that holds 70% of world's market share and none of the imagined "killing" that Apple does. Unsurprisingly, there's still not a single mind-bending paradigm-shifting PWA that would show the world just how great PWAs is and just how exactly "Apple is killing PWAs"
Technologists are enticed by the cost and development time savings of PWAs over native, but users resent the diminished user experience that almost always comes with it and repay you with poor ratings/reviews.
But Apple and Google don’t exactly have a huge incentive to do that.
Plus pushing users through an app store at least enforces a minimum standard of app quality, which as a user, I like.
- it failed when Palm tried it
- it failed when Microsoft tried it
- it failed when RIM tried it
- the “sweet solution” that Steve Jobs called web apps when the iPhone was introduced was called a “shit sandwich” by potential developers who wanted native apps.
On another note, in the history of computing, all cross platform GUI apps have always sucked.
VS Code is one of the most successful open source cross platform GUI apps of all time. Who would have thought that good ol' HTML would finally fulfill the promise of "build once, run everywhere".
It is free! Free as in free beer. So all those trillions are going to very good use, considering it is the most used editor. And its open source too!! What a web tech success story this one...
> and still running into issues like "we can't make the terminal fast enough
Imagine that! A cross-platform code editor with its own configurable integrated terminal that hooks into the apps extension system. But someone wrote a blog post in 2017 explaining some performance improvements, so bring out the pitch-forks and burn it all down!
You're confusing price and cost of development
> so bring out the pitch-forks and burn it all down!
That is literally not what I wrote, but at this point it's clear you're not interested in discussion beyond low-level trolling.
Adieu
Yes. Not all discourse has to be literal. It's called a a metaphor. And your "trillion dollar company throwing thousands of man-years" is called a hyperbole. You are talking about the most successful cross platform code editor of all time, so if you want to be taken seriously, use level-headed arguments rather than emotional exaggerations.
> but at this point it's clear you're not interested in discussion beyond low-level trolling.
> Adieu
I wouldn't consider a discussion where someone cites a 6 year old blog post about performance improvements as proof of "throwing thousands of man years" as a serious, or worthwhile discussion. You can go. Don't let the door hit you on the way out.
Sublime Text is implemented natively (C++) and uses a fraction of the resources to accomplish similar functionality. I know we live in a period of plentiful system resources where RAM usage no longer practically matters, but using 1.5GB RAM for a few files open seems insane, even more so that this is now normalized.
If VS Code is slower than sublime with the same level of functionality, why does it currently totally dominate the market? Is it because devs just love Microsoft?
It does use a lot more resources, but it turns out that people care a lot less about memory usage than UX speed.
That may or may not be the primary reason for the difference, but I don't think it can be ignored.
Because it only has the same level of functionality when you conveniently ignore how easier it is to write plugins
But it absolutely wasn't the native SDK that developers wanted.
Microsoft Teams though...
Now that all those AND the browser engines are better, there's a lot more that can be done, and better too.
As another example, if Google were to say tomorrow that they would release a high performance database, I’d believe it. If they were to say they are going to release an original social media platform, I would laugh.
Also, are you saying that Microsoft doesn’t know how to make developer tools or support platforms?
I've hear that fantasy before
> But Apple and Google don’t exactly have a huge incentive to do that.
Google is literally the main company behind PWA push. Android doesn't have any of the perceived or real limitations that iOS has. Well, where are these non-sucky PWAs?
Did you hear it from Steve Jobs?
https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...
Electron apps also had/have a bad reputation and the came vscode.
On VS Code: https://news.ycombinator.com/item?id=35450206
That aside, focusing on the main topic, and now I am answering more seriously.
You claimed PWA that do not suck are a fantasy. My point is it is not such a crazy thought. It is very possible. Now that Apple wants to appear less monopolistic (probably because of Epic court case) they are finally giving more permissions to PWAs.
On top of that the founder of the company expressed this same vision.
Both things, together, make me think that it is not such a fantasy.
The only difference is the APIs it has access to.
The reason why PWAs suck is that it has access to some pretty basic APIs.
Who controls the APIs? Apple and Google.
They’re the only people that can make a PWA nice. However, you constantly hear about efforts to make PWAs nice from people other than Apple and Google but these people aren’t in control of anything and honestly don’t matter.
Now Google may have been behind PWAs but from what I see, it’s been mostly to make web apps work better in browsers — apps like Gmail. But they’re not that invested in replacing apps with PWAs because if they were, you’d see them dogfooding their own apps as PWAs. However, they’re not.
So really, neither Apple or Google are invested in replacing apps with PWAs and until the dominant platforms want to, it will never happen.
Of course I was claiming no such thing
> Regardless what people reply to that question at least agree that when support is missing Safari will be the common denominator
No, you cannot disregard what people reply. Because the common denominator is just whining as people are complaining about random things. And when Safari adds another random API that random people randomly whine about, they immediately switch to whining about some other random API that apparently PWAs can't live without.
That seems utterly strange - did you try debugging it?
I don’t know what it is but between Apple, Elon, Web3 and Glen Greenwald they all have some of the absolute strangest super fans I’ve ever seen.
Or maybe just refer to the definitive docs [1] instead of relying on what 3 random people say?
[1] https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
I'm not asking. I'm telling, and quite clearly: ask three people, and you will have five answers as to what APIs people think PWAs can't live without.
Because of this you will always have people scream "Apple is killing PWAs" because they don't support a yet another random API.
And yet, see bullet point two in my original comment.
I like the "yet another random API" phrase. It creates the impression that PWA APIs are being generated fast and furious, and apple is trying very hard to keep up with all these "random" new APIs. Yet, the reality is that apple has for a long time deliberately crippled PWAs on their platform by not supporting just 4, crucial, old and fundamental APIs. I will list these for you:
- Background Sync
- Web Push
- Before Install Prompt and Installation Banner
- Background audio for PWAs
They do not have to implement any "yet another random API". Just those four. Everything else is a bonus, considering this is Apple's Safari (the new IE) we are talking about.
They are
> not supporting just 4, crucial, old and fundamental APIs.
At least these two are definitely random APIs that you think are "crucial", and not everyone who complains about Safari lists them.
> They do not have to implement any "yet another random API". Just those four.
Just those four that you decided are crucial.
Random APIs indeed. Lol
Imagine having a discourse in good faith. Imagine not resorting to false analogies. Imagine not resorting to low-effort trolling the moment you run out of arguments. Imagine...
Anyway. I bid you adieu in a sibling thread, I'll do the same here.
Adieu.
haha. Seriously though, do you honestly believe that is what you are doing here? You think you are acting in good faith?
> Anyway. I bid you adieu in a sibling thread, I'll do the same here.
> Adieu.
You cannot even keep track of all your "adieus". Are you saying goodbye to a thread, or to an individual? Or is it all just random. lol
FYI: I do not respond to individuals. I respond to comments. Usually asinine comments because they trigger me. So the best way to say goodbye to me, is to think before you post.
But perhaps this directory should be run by an other entity than the official app store.
The first match on my search engine is https://www.findpwa.com/
Downvoting starts in 3..2..1..
Right. We're carrying stupidly powerful supercomputers in our pockets just to be able to run simple apps written in this stack.
> Developing in one code base with just minor platform specific differences is so much better.
Try Flutter.
There is of course some hiccups but with no major obstacle.
- DNS is broken (because Google wants to have its own version of the internet).
- TLS is broken (for the same reason as above).
- Layout is limited (far too much, in comparison to web).
- Keyboard interaction is (practically) barebones.
- State management is (practically) one-style only.
TBH, that last point applies to nearly all of Flutter. You get a strong feeling that the only way to do anything is the Google-blessed method and nothing else. If you need anything done differently, just don't.
Can you expand on how exactly it "entirely broken"? I use it two years in production apps, and it's been amazing. The look and feel is pixel-to-pixel perfect to the native apps and slightly different from the "native browser", but it doesn't matter to users.
> DNS is broken, TLS is broken
))) right. IP is broken too )
> Layout is limited (far too much, in comparison to web).
Flutter not just designed to give you full control over layouts and its constraints in an efficient way (so widgets don't get rerendered or sizes don't get recalculated redundantly), it has custom painters and shaders and let you create completely custom layouts, including high-fps games. How is this more limited then DOM and "<a href target="_blank">" legacy?
> Keyboard interaction is (practically) barebones.
What's missing?
> State management is (practically) one-style only.
At this point I have a strong suspicion that you're trolling. State management in Flutter is a notoriously overpopulated field, with a whole zoo of officially endorsed approaches (for different cases and/or app sizes). Actually, if you would mention this as a main argument (no one-style state management) – I would agree with your point.
The problem is that the companies insist on publishing it to app stores, despite the fact that it is a hell for us to maintain as well as being completely indifferent from the users perspective once it's installed.
Having this as an option almost completely solves the maintainability issues of "packaging" and re-releasing the site every time we want to deliver an update.
> Progressive web apps employ the progressive enhancement web development strategy.
It isn’t like progressive loading of images (low res first, then high res). Instead the concept focuses on content first and then progressively adding functionality/behavior on top of the content. Dedicated web apps make the progressive loading of behavior a bit fuzzier, especially when the entire point of the site is the behavior. But these PWAs are not necessarily single page apps, so that content can be indexable.