It's kind of a nightmare due to both Google and Apple messing things up.
PWAs could be an amazing platform but both companies are really messing it up.
Apple is trying to kill them by giving plausible explanations as to why they can't have PWAs. Security this, blah blah blah. There's no reason they can't have PWAs work well in Safari other than they want you to port your app to the App Store and get locked into their native APIs.
Google's problem is, well, they're Google. Meaning things are somewhat incoherent, docs are all over the place, they start new initiatives then abandon them half way, etc.
Consumers are another problem. They have no understanding of PWAs and they go to the app store, don't find us, and then complain we don't have an app..
The plan now is to use Google TWAs and port our PWA to Android.
We're going to do the same thing to Apple after we do the Android release BUT I think there's a 50% chance that apple will just flat out block us.
I think we might have a chance of getting around it if we use mobile gestures properly, use platform specific APIs like the camera, audio, and GPS that aren't on web and try to really integrate into the platform properly.
For example, they have an API to detect dark mode now. IF that's on we're just going to magically enable our dark mode in our app.
I tried using your app on an iPhone (with Add to Home Screen).
- If I press the settings gear, the text on the settings page is about twice as wide as the screen, requiring horizontal scrolling.
- On the front page, if I open the color picker, it's partially offscreen.
- On all pages, if I do a scroll gesture in the wrong direction, it scrolls the entire UI rather than just the scrollable part. Admittedly, iOS has long made this hard to avoid without hacky JavaScript, but it's been doable, and it's much easier now [1].
- The hamburger button on the left opens a modal view that covers all of the screen but a small margin on the right, making it unreasonably hard to exit.
- If I try to create a tag or folder, the name prompt appears under the other modal view and is improperly sized.
- Oh, and the UI looks thoroughly non-native, e.g. Google-style floating action button, UI not covering the status bar, bottom tab buttons too short, etc. The animations are also haphazard.
My point is not just to nitpick. It's just that while I sympathize with the idea of PWAs in principle, almost every single time I see someone talk about theirs, the PWA in question has immediately obvious glaring UI defects that have nothing to do with browser limitations, and leave it far below the standard of a good native app, or even a bad one. I honestly don't know why this is, but experiencing it over and over makes it hard for me to care about PWAs.
There are some fantastic PWAs out there. Twitter is the one I use most regularly.
I think one of the reasons we see a lot of less-polished PWAs is that the idea of the PWA appeals to businesses at certain stages. Larger shops can afford to ship native binaries to more than one platform, but a smaller operation can't. PWAs are presumably tempting to those types of product teams: you get multi-platform reach while truly only writing for the web. The fact that their UIs have rough edges are probably a result of having an MVP-stage product.
Is Twitter really a PWA or just a nicely done responsive website? At this point the boundary is a unclear.
Beside Twitter rely on server side storage and pretty much only store session token in the PWA "local storage" (largely speaking).
And as a user I rather installed iOS native App to keep finer grained control on permissions. (I also use multi accounts not sure the PWA Handel that?)
It is absolutely a PWA, and an excellent one at that. You can add it to your home screen on the desktop and mobile platforms that support it; they have all the trappings of a native application including notifications support, background refresh, etc.
This highlights a longstanding issue of PWA definition and how to position it against modern web practices and features. What is a PWA? Why is it even a thing?
Why enclose PWA in quotes? Just curious. I use Twitter's PWA weekly on more than one platform and it works great for me, but that's just one person's opinion. I prefer it over their native clients for a lot of reasons, but the main value-add is that I don't have to give Twitter access to detailed information about my system while still using a full-featured, first-party client.
It's twitter's mobile site that they extended to cover both desktop and PWA. As a result, it's quite bad on all fronts and judging by the number of bugs that are lingering with no fixes, abandoned. At least they managed to almost fix the epileptic scroll position [1]
> I don't have to give Twitter access to detailed information about my system while still using a full-featured, first-party client.
Yes, this is, without a doubt, the best value-proposition of PWAs.
Are you sure that's not a catch-22? The reason you've not seen any good PWAs is because the ecosystem doesn't exist for making good PWAs, which doesn't exist because there aren't any good PWAs. Any sane technologist is going to look at the shortcomings of PWAs, and choose a different technology to build their app. Choose boring technology[0], and unless your product is a PWA toolkit, the app UI library isn't the place to get creative.
The single issue with PWAs, on iOS, is how do I add a PWA app to the home screen? I go to the app store and search... and your app isn't there. As developers we innately understand why that's so, but our users don't and shouldn't need to understand the difference.
Hi there, I'm the product manager for PWAs on the Chrome team.
Very interested in hearing about pain points you've had building out PWAs, especially if there's features you were keen on that haven't been released. Easiest way to reach me is on Twitter: https://twitter.com/b1tr0t
Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev, and the PWA section launched recently (https://web.dev/progressive-web-apps). Consolidating and adding docs is an active area of investment, and our goal is to create a well lit path for developers to succeed with PWAs.
was way too complicated as a first example, if all I wanted to know was how to make my app installable and is also broken as it uses some outdated tools. (don't remember the details)
Also, it could have been mentioned somewhere, that when you serve from localhost, you do not need SSL to install it. Knowing that, would have saved me the trouble of messing with apaches config and certificates.
So that was very frustrating as a start.
Much more helpful was a very simple hello world pwa which was barely installable. But it worked. And from there it was easy.
Thanks for the feedback! This is now the reference "first PWA" example: https://web.dev/codelab-make-installable. Let me know if you find it easier for new devs to get started with. The other codelab and a lot of other scattered content will be removed once we finish the migration to web.dev.
Please consider contributing to MDN. It's the best source for web development and it would be great to keep everything there, properly cross-referenced, etc.
The statement from b1tr0t directly refute that Google is contributing to MDN, as they put it: "Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev". As far as I know, web.dev is not MDN and has nothing to do with MDN.
As another user mentioned, we do contribute to MDN. MDN is where we point devs for reference documentation. web.dev is for guides, how to's and other support docs.
Heh, you're asking a googler who's basically responsible for some of the actions Google is taking with Chrome, trying to make the web only browseable via Chrome and centralizing information under their own Google brand, to contribute to a cross-company/community effort (Mozilla + Microsoft + open source hackers)? While noble, I can only wish you good luck.
I think the sail has long sailed for asking Chrome/Google to help out with the openness/sharing on the web/internet. It's time we just start ignoring them instead.
Just want to note that you specifically mentioned Microsoft working with open source hackers in this comment saying that the ship has long since sailed on Chrome/Google contributing to the open web.
I don't know, never say never I guess. I'm certainly not going to defend Google's track record on openness and privacy -- there have been, under even the most generous of interpretations, huge missteps, and I don't think they deserve the benefit of the doubt -- but they do contribute. Edge backed by Chromium?
Reading that announcement makes b1tr0t's statement "We've started to consolidate docs under web.dev" even worse, as they previously said they are gonna contribute to MDN, but now they have turned and use their own shit anyways.
Just so understand correctly, you're contributing reference documentation to MDN but then everything else goes into web.dev? Why not contribute the "guides and other supporting documentation" to MDN as well?
As I understand, the Product Advisory Board for MDN was created with Mozilla + others in order to combat the fragmentation of information, but your actions seems to do the opposite.
More background services would be very nice even though it's a bit of a security nightmare. A request was opened almost 5 years ago for background geolocation services.
I don't want Google or central authorities to decide which PWAs are "trustworthy" directly to ask for certain permissions but there could be a way or compromise. I don't remember which feature it was but it required yes from Google.
I really want the first screen after installing PWAs to be their privacy policy or detailing which permissions/how they use them. It should be mandatory and important or may show a default screen with permissions and few dangerous ways they can be used for.
Background geo, including geofencing is challenging, but there may be a way forward. We're exploring this conceptually, but it's not in the plan for 2020. I'd certainly like to be able to improve the capabilities of web based ride sharing and similar apps that have a need for this.
Bluetooth discovery is an especially thorny area from a privacy perspective. What use cases did you have in mind?
Asking for permissions upfront has been found to be an anti-pattern in systems UXR. Research has found that users make better decisions and find the experience less interruptive when permissions are requested in context at runtime. For example, in a video chat app, it's better to ask for the camera/mic permission at the start of the first chat session, not when the app first starts. Mac OS, Android etc. and other platforms have all been moving in this direction over the past few years.
When the permission is requested, we're investigating ways that we can do more to communicate permission risks to the user. Nothing publicly shareable yet, but do expect experiments to be showing up in dev channels over the next few months while we try new things.
Regarding your point on consumers, we put our PWA/TWA into the app store (for the reason you outlined) - and now get a raft of negative reviews that the TWA is the same as the mobile site... Which is frustrating, because that's the point.
Making it clear why a TWA is in the app store is hard in itself. Trying to explain why it's better for consumers over a native app + mobile site is even harder.
As an iOS and Android developer myself, this doesn't effect me but I still think Apple and Google making things harder for PWA is bad because Apple and Google are the gate keepers for what goes on their native app stores. I can cut some slack for Google as they at least allow third party app stores but Apple doesn't.
Either Apple should stop being the gate keeper or stop making life harder for web devs.
Maybe Apple could offer a compromise and allow users to sideload apps, but restrict non-App Store apps from accessing the file system or any kind of personal identification (like location etc.)
And improve their documentation to lower the barriers to native development.
I wouldn't attribute it to laziness. Quality can really suffer when you need to maintain so many code bases. Not all teams have those kinds of resources.
Perhaps Electron/PWA should be seen as a last resort, not the norm, reserved for exactly such a situation: when you don’t have the resources to build native for all platforms.
Hiring aside, it’s probably simpler than attempting to reconcile souped up document viewers with contemporary expectations of “apps”, iOS and Android being purposefully built for the task and all.
Having done native Android/iOS and web dev, web dev is much easier than Android and at least on par/if not easier than iOS.
There's a bunch of very complex web/electron apps that disprove the idea that the web is only for static documentation and web-inspired ideas are coming to mobile (React --> Jetpack Compose/Swift UI).
More importantly, hiring can't be put aside, and it's much easier to adapt your web app to work for mobile (since websites should be screen size agnostic anyway) than it is to build a fully native app from scratch.
Makes sense, they want you to create native apps so they can collect their rent, and also dictate what is in, what is out, and control searching of apps.
> There's no reason they can't have PWAs work well in Safari other than they want you to port your app to the App Store and get locked into their native APIs.
Is it possible they also want you to port your app to the App Store to prevent an explosion of garbage and malware that could happen if PWAs really took off?
There is absolutely no reason that PWAs can't be sandboxed like native apps, or even more aggressively. In fact, native apps are more likely to be spyware, as they can collect much more information from the user than a browser-based app can.
Native apps ostensibly go through review so that Apple can flag malfeasant behavior that is nonetheless allowed by the sandbox. Think things like a $999 purchase request that pops up on app launch (Yes, I know Apple isn’t that great at this. But that’s the argument that they use for review.)
Yes, they are[1]. The GPL is incompatible with the App Store terms and if Apple is aware that an app uses GPL software, they will reject or remove it from the App Store.
That link is from 2011, and the referenced verbiage is nowhere to be found in the App Store terms. I believe that the current terms leave the App Store open to GPL software. Also, Apple will only remove software if you notify them of copyright infringement; it's not their job to preemptively perform licensing enforcement.
> Also, Apple will only remove software if you notify them of copyright infringement; it's not their job to preemptively perform licensing enforcement.
Developers of GPL software have had different experiences with Apple than what you're asserting. There is a direct incentive for Apple to police licensing incompatibilities if they are profiting from illegal distribution of GPL software on their platform.
I tend to think of this as reaction to GPL FUD; I know some people who have these so they never have to actually figure out the answer to this question.
I seriously doubt that. It's a lot more difficult to do horrible things with PWAs than it is with native apps. Apple has a history of doing everything they can to keep people inside their walled garden and this is just another instance of that.
It's kind of a nightmare due to both Google and Apple messing things up.
PWAs could be an amazing platform but both companies are really messing it up.
Apple is trying to kill them by giving plausible explanations as to why they can't have PWAs. Security this, blah blah blah. There's no reason they can't have PWAs work well in Safari other than they want you to port your app to the App Store and get locked into their native APIs.
Google's problem is, well, they're Google. Meaning things are somewhat incoherent, docs are all over the place, they start new initiatives then abandon them half way, etc.
Consumers are another problem. They have no understanding of PWAs and they go to the app store, don't find us, and then complain we don't have an app..
The plan now is to use Google TWAs and port our PWA to Android.
We're going to do the same thing to Apple after we do the Android release BUT I think there's a 50% chance that apple will just flat out block us.
I think we might have a chance of getting around it if we use mobile gestures properly, use platform specific APIs like the camera, audio, and GPS that aren't on web and try to really integrate into the platform properly.
For example, they have an API to detect dark mode now. IF that's on we're just going to magically enable our dark mode in our app.