I also got this email, but professionally and personally.
Personally, I voluntarily built and run open source apps for 16 different cities for their transit system. This gave me two weeks to update 16 apps, for no benefit of anyone. My app is a PWA, and the Android version just uses cordova + a few plugins to add a few native options. Unfortunately, updating cordova to support the new target android api broke some of the plugins, which haven't been updated yet, so it ended up being a full weekend of work and testing.
Truthfully, I'd prefer to get rid of the app and just have users go to the website and install the PWA, but the average user still doesn't know how to do this. And the Play Store is still the first place users go to find apps. If google would just allow submitting a PWA directly to the app store, that'd be nice... I am not looking forward to doing this yearly.
Professionally, we are also scrambling. We have a legacy app that some supported customers are still using until the end of the year. The app is a fairly complex application, and basic testing has already shown that just changing the target api version has broken quite a few things. We have gotten the extension, but we know this will take 1-2 weeks of developer time + 1-2 weeks of QA's time, for an update that does nothing but appease Google. All for an app we are going to officially remove from the store at the end of the year, once all customers transition to the new app is complete.
> Truthfully, I'd prefer to get rid of the app and just have users go to the website and install the PWA, but the average user still doesn't know how to do this. And the Play Store is still the first place users go to find apps. If google would just allow submitting a PWA directly to the app store, that'd be nice... I am not looking forward to doing this yearly.
This is what Trusted Web Activities (TWA) are for, you can use it to list PWAs in the Play Store without frameworks like Cordova
My TWA app still got hit with this mandatory update requirement. I'll have to rebuild the wrapper app for the first time in years. I don't even remember how I did it last time but I do remember that Android makes it nowhere near as trivial as it ought to be. I can practically guarantee that something will break if I try to do all this busywork. I'm probably not going to bother, it's just a free app that I made as a side project and a large majority of users visit the website in a browser.
If Google actually cared about getting PWAs into the store, the process would be as simple as submitting the URL of your PWA manifest to the Play Console.
> Truthfully, I'd prefer to get rid of the app and just have users go to the website and install the PWA, but the average user still doesn't know how to do this.
Let's be clear: that's not because users don't know how to do it. It's because Google and Apple haven't made it as easy as installing an app from their app store. That's a choice, and it's a deliberate one.
I disagree, at least on the Android side of things (Apple has long been hostile to PWAs). Installing a PWA from a website is trivially easy on Android, it's just that most users really have separated in their minds (not surprising due to history) that apps come from app stores, and the browser is used for websites.
Also, Google has made in much easier in recent years to submit plain PWAs to the Play Store: https://youtu.be/ddbHp8tGBwQ
On Android you have to pop open a menu and find the install option. That's not inherently discoverable as you need to know it's even possible, and most people don't.
It would be trivial to present the user with a more proactive notification that a site can be installed as an app, or even include such a notice in their search results on Google, but they choose not to do so.
Actually nowadays it's not that bad anymore. Android browser itself offers installable PWA and there is an event called beforeinstallprompt event (https://developer.mozilla.org/en-US/docs/Web/API/Window/befo...), which can be used to perform PWA installation on user interaction. Of course it's not supported in every browser.
iOS is more difficult since user needs to understand that "saving to home screen" is same as installing "app" and there's no way to trigger it programmatically or help user in any other way than with visual illustrations.
The share menu is used for everything on ios, I had to get used to it at my first apple device’s case.
One notably stupid usage of the Share option was (I believe it is no longer how it’s done) adding an image to a hidden folder — that’s something you definitely don’t want to share, yet quite easy to accidentally send to someone during this process.
Thankfully this insanity is changing in the upcoming release due in September. A button for a 3 dot/hamburger menu appears in the bottom right when you select photos.
Because it doesn't make sense that it's part of the web share functionality to begin with.
The native share dialog is about "I have this piece of content, now share it with one of these other apps", e.g. saving a document locally, or sending it with AirDrop, or saving to Google Drive, or sending as an email attachment, etc.
Installing a site as an app on your homescreen has absolutely nothing to do with sharing content to begin with.
I have some PWAs in the Play Store via that method. I also got this same Android API update email and had to jump through various hoops to update them all. I wish I could list an actual PWA (like a URL to a website) in the Play Store and then never have to worry about Android API version updates, since I'm literally not using any Android-specific features.
> it's just that most users really have separated in their minds (not surprising due to history) that apps come from app stores, and the browser is used for websites.
Right, because for a very long time (and maybe still) PWAs have been much closer to terrible websites than good apps. They generally don't have the same UX properties as real apps.
Remember when the iPhone first came out and web apps were the only option and they sucked balls? That never really changed. People still find mobile sites with maps that are impossible to use. They don't expect that from app store apps.
And if it's just a web site, why do you need to "install" it? A link is surely sufficient?
But nowadays you can't really see the difference between good webapps and native apps. We also migrated our native apps to full SPA apps. And really it makes development so much easier. The apps we have are relatively simple without fancy stuff. But the css render engine is fast. Even on Android.
And we reduced some of our apps from 30mbs of java code to 150kb of java/typescript.
Plus as a bonus we can have a website and serve ios as well.
For us there is really no reason to go back.
Sidenote: some parts of the app are still native. Ads, Auth and analytics
Thanks for posting, I think this is a great point. Web tech has advanced to the point that a large swath of apps can be implemented as PWAs with no loss of experience (though last I checked iOS was still holding things back).
This isn't true for all apps, but with the notable exception of games, I'd say it applies to most: banking/finance apps, social media apps, travel/airline/booking apps, etc.
If you seriously think analytics makes for a worse user experience, then you're speaking out of ignorance.
Analytics tell developers exactly where bugs and crashes occur.
And on which devices or versions of the OS the problem is.
Without analytics it would take weeks/months to figure out exactly what line of code is causing the issue. Heck, the developers might NEVER KNOW that the software has an issue.
Apps would just keep crashing on users for years. And developers would have no idea why users were abandoning their product.
Nobody that has any idea what they're talking about would say that analytics makes for a worse user experience.
> And if it's just a web site, why do you need to "install" it? A link is surely sufficient?
The point is that there are apps that can pretty much be built entirely using web technologies as PWAs, but in doing so they are no longer "just web sites" and they need functionality of installed apps, like notifications. For example, most banking apps on Android could be entirely rewritten as PWAs, but they'd need to make use of things like notifications (I don't want a random website sending me notifications, but I DO want notifications of activity on my bank account) and camera APIs (e.g. for mobile check deposit).
I find bank apps to be the least flexible about notifications; there's no way to get them to use app notifications for a lot of things they insist on using email and/or SMS for.
The last thing being the worst as SMS 2FA is so insecure, but SMS of your bank deposits isn't much better.
Well, obviously all the features that are available to PWAs are available in browsers - a browser is the thing that executes a PWA to begin with.
It basically is just a difference in use case and how most people thing about "apps" vs. "websites". If I have a long term relationship with a business, and I access its functionality frequently, I'd rather have it as an app on my homescreen.
Just looking through the apps I currently have open… Bank app, chat app, maps, Tile, YouTube and a weather app. Only one of them is actually doing anything that wouldn’t fit a PWA. So why are they apps, not a collection of links?
I would say only the weather and bank apps would be really equal as a PWA.
Maps require complex gestures and advanced graphics and UIs that would never work well as a PWA. Try maps.google.com. Its nothing like the Google Maps app. Plus Android Auto integration.
Tile probably needs pretty deep Bluetooth integration and background processing that the web doesn't provide.
YouTube can do things like PiP that you can't do on the web.
Yes, "Add to home screen" is exactly how you install a PWA to your phone =)
It's a bit confusing, isn't it? "Add to home screen" makes it seem like you're just adding a link, but it's installing the PWA, possibly enabling notifications, and etc.
1. For people like you that don't want to install them, they're just a normal website.
2. For people that do want to install them for the added functionality (things like notifications), then it is easy to install, and furthermore cheaper for developers to build and maintain (one codebase instead of multiple).
You say "you have no desire to have an app", but I think for most people that's really dependent on the site/application. Yeah, for any site I just have a short term or infrequent transaction, I don't want an app either. But many/most people use apps for businesses they have long term relationships with (namely financial institutions).
That's not always because of anything intrinsic to the Web. We know that ordering a pizza isn't any more complicated than what can be represented on a paper form. Forms can also be capably represented in a browser. The problem is that app developers are by and large not capable of distilling the requirements down to what is necessary and sufficient for the task at hand. Instead, they're foolishly preoccupied with what they consider to be the mandate to deliver experiences.
I find it much easier to install a web app from the website than having to find anything on the App Store. There’s nothing easier, it’s only 2 taps when browsing the website, at least on Safari. The process is exactly the same as in iPhoneOS 1.0, when this was the only official way to get applications.
The problem is not that it’s difficult, it’s that the share sheet got bloated and should be completely rethought.
> I'd prefer to get rid of the app and just have users go to the website and install the PWA, but the average user still doesn't know how to do this
I think you misunderstood users, it's not just ignorance. I want apps to go back in the direction of real(not cordova) apps, not some low effort web thing. Basically zero web apps match the experience of a well crafted actual app.
I agree with you in many cases. At my professional company, we've made the decision to write native apps for Android, iOS, Windows, and the web, because we have pretty deep integration into each platform and want the best native experience for our users.
But, for my personal apps (which is what I am talking about in this thread), I can't support that. Writing it once and maintaining it takes up enough of my free time. This app also doesn't have any integration with the system, and has a minimal interface, so it works quite well as a web app.
The app my accountant provide me - a white-label finance app with the firm logo on it - used to be native. The developers had issues with updating the app to support a change in the camera API and I couldn't scan papers. They sent me get web app instead. Now whenever I use phone's native back button/gesture the app quits instead of going back within the app, there's a functional in-app back button, but my instincts will never disappear selectivity when I'm using their app. I have quit their app million times half-way of filling forms. Terrible UX.
As keeps getting pointed out, every. Time. This. Gets. Raised: evidently most SPA’s are not written properly, because “back button not working properly” is easily one of the most common complaints.
That's not the only point. Web apps can have far lower performance or battery utilization than real native apps for one thing. If you care about the environment or your battery life use a compiled app, not the web.
I see now what the parent poster meant. He said a web app can have lower performance and battery utilization. He meant lower performance and higher battery utilization. From the context it was clear and I misinterpreted it.
You do understand that not every developer is backed by billions of dollars of venture capital, right?
That there are people who have to target multiple operating systems, and don't have 100+ people working on their team, right?
I mean...it doesn't take a genius to figure out that there's a benefit to being able to write code once and deploy to ALL users/customers without having to dedicate entire teams of developers with expertise in various platforms.
I'm an Android developer with 10+ years of experience. I take pride in my native apps that I code for the company I work for. They are far superior to any web app or "multiplatform framework solution".
But if I had to create my own personal app, there's no way in hell I'd spend years learning everything it would take to create a native iOS, Windows, Linux, MacOS version.
I'd be an absolute idiot if I didn't just choose a solution, like a web app, or framework that was able to output for more systems, etc.
We love to discuss technology on here and I have my own opinions about that, but to be honest, as a user I have found absolutely no correlation between the underlying technologies and how well an app works for me.
It often hinges on seemingly small design decisions that make some frequent task either a breeze or a constant annoyance. There aren't many cases where making the right design decision depends on whether or not the code is "native".
I believe the most important distinction is whether the motivation for making an app is economically aligned with my motivation for using it and sustainably so.
I used to think that, and then I started using Phanpy and Voyager. PWAs can be surprisingly good if they're done well. The problem is the mobile platforms have done nothing to optimize the experience or encourage their development and so the good examples are few and far between.
>I think you misunderstood users, it's not just ignorance. I want apps to go back in the direction of real(not cordova) apps, not some low effort web thing. Basically zero web apps match the experience of a well crafted actual app.
For me, it also depends on how integral internet access is to the application's function. When I'm on my computer and want to check the weather, I don't want to launch a separate application. I just google "weather". I agree that games probably belong as standalone desktop/mobile applications and similarly for other programs requiring deep integration with OS APIs. But if an app mostly wraps content that's already available via a website (e.g. starbucks.com, subway.com, or news sites), I'd rather just use a full-blooded web browser.
Usually I would prefer no app. Better than wasting my time downloading an app, being disappointed that it was noticeably "web", and ditching it. Low effort implementations also make it harder for the grass of better native apps to grow amidst the web based weeds.
I have compassion with you, some of my private apps were also affected.
But we were being told this deadline for many months now.
It was clear that at some point they would show it more in your face.
I also disliked the way it was formulated, also, even if everything was fine in production, it complained when testing versions didn't comply (doesn't make sense).
Also, it was always only about pushing new updates (it's ever year like that). You could still keep the app live for some time.
My understanding from earlier notifications was that updates would not be accepted unless you targeted a new api version. That is fine, since I haven't updated the Google Play "app" since I first released it. This is because the real app is a PWA that I update through the web, and the Play Store app is just a shell around that.
The first time I was aware that the app would be delisted in the Play Store for new devices was in the August 18th email.
> Apps with a target level of Android 11 (API level 30)* or lower will not be available to new users running the Android OS higher than apps’ target API after August 31, 2023.
>Apps with a target level of Android 10 (API level 29) or lower have not been available to new users running the Android OS higher than apps’ target API after November 1, 2022, or May 1, 2023, if your app had an extension.
In my case, I was hired to work on an update to a legacy app ~8 months ago. So this is my first round of bs. Been writing software for 20 years and I’ve never seen this before… I wouldn’t consider it playing dumb, I’ve just never had cause to care or receive an email like this.
And you have also never had a security vulnerability in one of your dependencies causing you to update your software? A new database version? A new version of whatever runtime you were using?
I guess that’s the difference between a free marketplace and whatever this is; because this IS NOT a free market.
In a free market, you set the deadlines. If your publisher reaches out to you about a security issue you don’t have to fix it and they aren’t obligated to pull your product. In fact, you might make it into a feature or simply reconfigure a WAF.
Probably the closest thing to this would be in the early/late 00’s when some idiot would buy an ad in the paper/magazines. You’d have a fire under your ass for that. Even then, it was self-inflicted.
So the answer is no. I’ve never dealt with a publisher that had you by the balls, imposing random deadlines. There’s always been a human on the other end who has their own agenda, but also respected ours.
Not sure if it helps, but if I was in your situation I’d provide a few app updates with a screen to train users on how to install the PWA version and gracefully run away from these problems. Maybe also provide a some sort of a form to get some feedback over the difficulties encountered by users to get there.
Good luck!
The problem is that many of my users are temporary. For example, I have an app for the public transit system for a resort town in Colorado. The town has a decent, albeit small bus system. They technically have an app from their vendor, although it is not very good and is difficult to find. If you search for "$town_name transit app", it won't show up anywhere, where as my app does. And I think my app is much more user friendly. I wrote it because I visit this area a lot and hated the vendor app.
My users are visiting this town for a few days, and are most likely going to open the app/play store and search for an app, use it for a few days, then leave the town and forget about it. The least amount of friction I can provide the better. My only goal is to support public transit and make it a smoother experience.
Do people really search for entirely temporary/short-term/single-use use apps, like for a resort town's transit or a restaurant? For me it's a last resort thing, if there's no website or it's unusable.
Yes. I spent a week in Rome last month (first time visit) and ended up downloading four different apps for public transport and city guides, all
of which were useful. This is on top of Google Maps, Trip Advisor and everything else.
> Or do you think places are making apps that no one uses?
Of course, because apps are "modern". You've never seen an app that should have been a website? I know of multiple places that had shitty apps built for extremely narrow use cases that had close to zero use outside of the team that ordered it (while it was meant for a wider audience).
And yes, I'm genuinely baffled people will bother downloading an app for a very limited use, like the transit of a place they'll visit once for a few days at most (especially considering there's Google/Apple Maps, Citymapper Transit; unless you can buy tickets through the app it's a waste on top of a waste). Has it been ingrained to such an extent that phone == app? Or is that an iOS thing, or maybe an American thing?
What makes you think that companies continue to build and support apps that no one uses? Maybe they have more insight about their usage then a random person on HN?
All the apps mentioned in that page are ones that are used regularly. You can surely appreciate Tinder and Spotify are wildly different than a random resort town's transit times app? In the same way that there are useless apps nobody uses, there are many that are used for hours daily.
I got Citymapper, and that was the end of me looking for transit apps when going abroad. But true, these days the built-in map apps in all platforms are also decent at dealing with public transport options.
I love cordova for my personal apps, but once every year or two when I’m forced to update Android and iOS they become such a nightmare. I spend days or weeks getting unblocked because I don’t have unlimited time to maintain these apps alongside everything else in my life.
Your customers have been using websites for much longer than they have been using apps. I simply don't buy that they can't understand how to use a website. Stop underestimating your users.
It's amusing that you are certain that you know his customers better than he does. I believe that you are utterly wrong, and if not most than certainly many people who use public transport and smartphones have never or nearly never been using websites on their phones, many of them haven't been using websites on a computer two - this is very typical of the non-technical people, especially those who are members of the younger and the older generations.
That's not what I said, I live half my life within browsers. But big chunk of the population that you are probably not thinking about is not like that. My mother in law is using browser to read on her computer, and will never do that on her phone - the screen is too small and the whole experience not something that fits someone at her age. On the other hand, my children use apps since they are two years old, and at the age of seven they still rarely if ever used browser.
>On the other hand, my children use apps since they are two years old, and at the age of seven they still rarely if ever used browser.
Most of the people writing on HN were first exposed to the internet through web browsers. On the other hand, children these days who grow up with smartphones first interact with the internet through phone apps. Do they have any difficulty adapting to the unfiltered web when they grow older?
I sure hope not. I don't have definitive first hand experience though as my kids are not old enough to have to use a computer and they haven't grow much interest in that direction. When my dad's first PC arrived home it was for me the most exiting thing ever, but it didn't have to compete with a smartphone.
The screen isn't too small to use web browser presenting site that looks just like the app, obviously. It is too small for comfortably reading or using the browser in general, so using the phone's browser for searching stuff on google is something that many older people simply don't do (in my anecdotal experience, I have no hard data to back this claim up). Searching for the train times in city z, going into a web site and finding that it is actually identical to the app and just as useful is something that is very unlikely to happen to my mother-in-law.
There are a lot of websites that don't scale well with small screens.
Just the simple trick of zooming in on a website with a "2 finger pinch/pull" is something a big part of the population doesn't even know how to do. I know my mom would probably just give up.
Buttons on many websites are way too small for some people to use.
Those are never an issue on native apps. The UI on apps scale with the size of a phone's screen. No matter if you have the smallest iPhone or the largest Android.
This alone is enough for many people to not use the web browser unless absolutely necessary.
If his customers are under 25 or 25 probably not. There are also plenty of older people in the US who never had a computer. But they now have smart phones.
Personally, I voluntarily built and run open source apps for 16 different cities for their transit system. This gave me two weeks to update 16 apps, for no benefit of anyone. My app is a PWA, and the Android version just uses cordova + a few plugins to add a few native options. Unfortunately, updating cordova to support the new target android api broke some of the plugins, which haven't been updated yet, so it ended up being a full weekend of work and testing.
Truthfully, I'd prefer to get rid of the app and just have users go to the website and install the PWA, but the average user still doesn't know how to do this. And the Play Store is still the first place users go to find apps. If google would just allow submitting a PWA directly to the app store, that'd be nice... I am not looking forward to doing this yearly.
Professionally, we are also scrambling. We have a legacy app that some supported customers are still using until the end of the year. The app is a fairly complex application, and basic testing has already shown that just changing the target api version has broken quite a few things. We have gotten the extension, but we know this will take 1-2 weeks of developer time + 1-2 weeks of QA's time, for an update that does nothing but appease Google. All for an app we are going to officially remove from the store at the end of the year, once all customers transition to the new app is complete.