Hacker News new | past | comments | ask | show | jobs | submit login

The “low usage” comment is going to be more ammo against Apple unfortunately. The whole reason they are low usage on PWAs is because of a lack of investment from Apple and a lack of parity, yet for the longest time Apple has played both sides by saying PWAs are a viable alternative to the App Store, all while channeling people to App Store for actual app downloads and not providing similar marketing or anything for PWAs



Are you sure this isn't a tech industry viewpoint? I don't know anyone who knows what the difference between an app and a PWA is. I don't think I've seen anyone outside of the tech industry with a PWA active.

In context 99% of the users I meet don't even know what USB-C is.


You’re right but a lot of that has to do with discoverability and the lack thereof on iOS. On Android you can show an install prompt via the browser or even package your PWA to be distributed via the Play Store. On iOS you have to do a strange incantation of “sharing” a web page to your Home Screen via a submenu. Its utterly unituitive so it’s not too surprising that most don’t.


I think it's pretty feasible for a web app (assuming the user trusts it) to prompt a user and explain how to add it to homescreen from iOS Safari. I can imagine, and think I've seen in the past, a nice-enough UI flow to get people to install a PWA. After explaining the benefits, you have an "Add to Home Screen" CTA button. When the user taps that, if it's iOS Safari, you pop up a modal that visually explains the two steps required, which are (1) tapping the button at the bottom of the screen, and (2) tapping the "Add to Home Screen" menu item. (OK they need to do one final tap on 'Add' to confirm the title, but most users who've got this far would manage that on their own.)

I agree that's not as good as a native install prompt but I don't think it's a strange incantation/utterly unintuitive. I know that icon originally meant 'share' but these days it means a wider range of things - basically "take this thing somewhere else".


It’s definitely possible, I’ve done it myself in the past (it’s still very annoying owing to the different position of button on iPhone vs iPad) and the analytics show some users get it. But as compared to “find us in the App Store” it’s night and day.

It’s also a very inconsistent experience: some sites have set themselves up as fully featured PWAs, others have made no efforts at all. Both get the same button.


>Are you sure this isn't a tech industry viewpoint? I don't know anyone who knows what the difference between an app and a PWA is. I don't think I've seen anyone outside of the tech industry with a PWA active.

The more important context is the legal one, not what laypeople think.

Apple is presenting PWAs as viable alternatives to the app store in a legal context: https://www.accc.gov.au/system/files/Apple%20Pty%20Limited%2...


Companies can quite happily hold two opposing viewpoints when it suits them. Apple's products usually have some kind of pleasing consistency but that doesn't mean their corporate dealings have to be.

In a similar vein, a startup will be very happy to talk about how valuable it is, except when it comes to talking to tax authorities, whereupon suddenly their shares are borderline worthless.


Eh, this is at least a little different. Startups talk themselves up to investors where they need to convince the investors that they will be really valuable at some point in the future. This is compared to tax authorities who are only concerned about current value, which is often essentially zero when it comes to startups.


But now they’ve allowed alternative app stores so why are PWAs still required?


Because they have already been heavily invested in and are cross platform. Sure, Apple has already been fucking over PWAs by refusing to implement certain web standards, but they still promoted them and they are heavily used in certain industries.


No. It is not! The law is for the people, for the „laymen“, not for lawers.


Correct on it being a tech industry viewpoint— people think "apps come from the App Store" and therefore anything else that's clunky requires a fair amount of education and payoff for users to adopt.

It's off balance, and it shows now that the tech has to be removed since it wasn't actually at parity despite it being an argument for it unfortunately.

The worst part? This has been the case for 15 years. It's not like there wasn't enough time to fix it. That's plenty of time to hire and develop solutions, yet now look at the reasons for it being taken away.


On Android you can install PWA's from the App Store, no reason why Apple couldn't also support it.


Fair call on your first point about PWA knowledge level in users. Regarding your users knowledge of what USB-C is: are you sure your user group are not potato's? Most people I know, including the teenage daughters and their friends, all know what USB-C is these days.


One of them was going to buy a new phone because it took a long time to charge. This was because she had a crap charger and crap cable. I am unsure if they are potatoes or not but I suspect they might be :)


I don't necessarily think it applies in your example, but I've heard some very silly reasons given by people as their reason for upgrading.

I think a lot of the time people give an excuse, or perhaps even a justification to themselves, when they really just want the excitement of new phone. I often catch myself inventing reasons why I should replace my perfectly fine phone.


No it was 6 months old and she doesn't care about it or phones. She thought it was broken. I charged it with my powerbank, an anker PD one and she ordered a proper charger off amazon. I gave her my spare USB-C cable. It was seen as a potential financial inconvenience having to do anything about it as well.

Literally many people do not care enough to understand it. It's just a modern necessity, a tool.


This is my wife. She purchased a bunch of USB-A to USB-c cables off Amazon and wonders why her laptop runs out of power while plugged in - it's because the laptop needs 25-30 watts and those cables can only put out 5 watts because they're limited by the USB-A port.

USB-c PD is such a dumpster fire of a standard. Even with supposedly high end cables like Anker you often can't charge a Macbook Pro faster than it can drain it's own battery under load. We can't expect normal people to understand why there are a dozen different cable types that all have the same tip but charge at vastly different rates...


That's true of all things that don't respect standards, not a PD issue. If you buy a wheel and it's not up to spec it'll crack. If you buy a power cable and it has a type-c on one end and a 110/220v plug on the other, that's not going to work well either.

Buy stuff that's up to spec, and it'll be fine.


The charging speed of USB-C cables (C on both ends) is pretty much just the slow ones and the fast ones, and "slow" is 60 watts.


No. PD is optional in standard.


No, all compliant USB-C cables support 60W minimum (3A @ 20V). That is the minimum baseline for all USB-C cables.

Higher power levels beyond 60W are optional. The newest PD spec goes up to 240W (5A @ 48V).


Compliant being the keyword there. Are you saying all of the crappy cheap low-end USB-C cables you find on Amazon are fully compliant? You have to put an effort to find brands that are actually legitimate, and pay more for that. Hence the vast majority of people probably won’t successfully do so. Standards compliance is theoretical in the real world that involves cheap crap from Amazon.

Anyway the GP post is referring to a USB A to C cable and an old-fashioned USB A wall charger, many of which barely output a single watt. My family members have had similar problems due to similar confusion.


As long as the cable isn't completely broken and has wires that actually conduct the current, you're getting 60W over USB-C PD. It's 100% passive. Compliance means "it connects one end with another without causing fire", it only gets more complex at more than 60W.

If it doesn't have the wires inside, you've been scammed into buying a piece of junk that merely looks like a USB cable.

When using a USB-A charger, you're guaranteed* at least 2.5W, and the charging standard (BC 1.2) goes up to 7.5W (though usually you can go higher with proprietary protocols, such as QC, or even PD 1.0, although it's very rare for something to support PD 1.0 and pretty common to support QC or Apple signaling). Sure, you won't be able to charge a laptop from a USB-A port, but it's not a hard thing to grasp.

I don't think you know what you're talking about.

* You could probably find some chargers that do less than 500mA, but you'd have to search among 20 years old ones at this point and they wouldn't really work with anything modern anyway, PD or not. The hard requirement is that a port has to provide at least 100mA, but that's only relevant to data ports that can do USB enumeration - for charging-only ports, everything assumes at least 500mA, and it would be really hard to find something with less than 1A or even 1.5A (7.5W) these days. Of course, if you try hard you can find any kind of weird stuff out there - I've got a water fountain for cats with power adapter that has a USB-A port providing 9V, so connecting anything else to it may make it release its magic smoke - but that's hardly a problem with USB itself.


Optional in what way?

Having power wires isn't optional. The ohm limits aren't optional. And they can handle 20 volts by virtue of using normal insulation.

The 60 watt limit is for completely passive cables that don't implement anything PD-specific.


No.


Yes.

Every conforming cable supports 3 amps and 20 volts.

If you think something's incorrect with that, be specific. But the spec is pretty clear.

The exact details of the faster cables are murky because there's old and new versions of that section of the spec, but very few devices use enough power to care about that.


USB-C spec is not very clear. And even in cases where it is clear. It’s not followed. There’s so many bad cables around. Cables that work on 1 device but not another, cables which do data and not PD, cables that do PD and not data, USB-C has the nicest plug with the worst experience.


The power handling of a basic cable is very clear.

If something breaks that, it doesn't make sense to blame USB. Whatever the manufacturer was doing, it was such a mess that it would fail with any other standard.

Supporting data and PD is just three tiny wires, it's not hard.


> Every conforming cable

The problem is all the non-conforming cables that people have, that look exactly the same as conforming cables.


In this particular context, a "non-conforming" cable would cause troubles by starting fire or dropping voltage below usable range, not by limiting charging current. The only sane thing to do with such cables is to throw them away.

Really, we're talking about physically broken cables here. As long as there's electrical connection, there's no other way for a cable to not work at 3A/60W with USB PD. Its cable requirements only start when you want to go higher than that - and 60W is plenty of power already.


Except they were responding to a comment criticizing USB-C PD as a standard. Non-standard cables are irrelevant to that discussion.


> We can't expect normal people to understand why there are a dozen different cable types that all have the same tip but charge at vastly different rates

Is the part of the GP comment I was responding to. The connectors form part of the standard. There’s no way to identify a standards-conforming cable from a non-standards-conforming cable by looking at it. They all look the same.


This applies to any kind of cable. How can you tell that a HDMI cable isn't empty inside, missing all its wires? It looks the same!


You plug in an HDMI cable, it either works, or it doesn’t. It might only work at specific resolutions, but you get immediate feedback when it’s working or when it’s not, at whatever resolution you try.

You plug in a USB-C cable, you might get a quick charge. You might not. Unless you have a USB-C power meter, you have no way to tell unless you know how quickly your device should charge in 5, 10 or 15 minutes, and hang around to wait and see if it does or not.

I think there’s a meaningful difference there!


There are no USB cables that are limited to 5W, and standard non-PD USB-A ports can give you up to 15W.

The only case where you may need a different (non-passive, "e-marked") cable is when going above 60W (3A).


I recently discovered that I can use my iPad and MacBook charging brick to test PD of a usb cable. If it’s low wattage, the charging brick will not provide any power to the iPad. High wattage and it will.


It is a bit curious that you immediately jump to PD being a dumpster fire instead of the much more immediate "apple is a dumpster fire and incompatible just to be obnoxious".


It can be only the charger or the cable. It usually happens when using the charger of an old phone for a new one or when buying a new cable, maybe because the one coming with the phone is too short and doesn't go from the plug to the table. Both chargers and cables usually list their compatible phones.


> In context 99% of the users I meet don't even know what USB-C is.

OH (frequently):

- hey I need to to up, do you have a phone charger?

- yup, which kind?

- not "an Apple"

- oh, so USB?

- yeah the "standard" one, not the "new usb"

That said, I'm surprised many do know about the literal "usb-c" term. Micro USB A though flies over their head, it's "small usb" or "standard usb" every time.

Of note: EU here, and while they by and large don't know about the EU standardising stuff they did notice the effect. I've seen a few refer to USB-C as "universal one" (largely coz it works the same for both phones and laptops)


With my friends it's either "USB-C" or the "round USB". Maybe it's already too old to be referred to as the "new USB". The old one is definitely the "old USB" or the "not round USB".


Going on a slight tangent: I do get many clients inquiring about PWA because "they don't need to pay 30% per purchase". This is anecdotal, of course... they wouldn't be able to tell you what it is, but all they care about is that they save 30%. So there is definitely "interest" in PWAs.


I think PWAs are an outright failure and a technical solution looking for a problem. I don’t even know where to find one.

For one thing, if Apple is complying with the EU’s alternative App Store and browser engine mandate, they’re even less useful than before. Why do I as a user want a PWA when I could have a native app?


PWA’s on Android can be installed directly from a website…it’s awesome, less friction and less scammy than the Play Store.

On iOS you need to use the Share > Add to Home Screen which normies have no clue about. You’ll find out if the site supports PWA features AFTER you add it to your Home Screen. This of course is done entirely on purpose to make them harder to find and less appealing than the revenue generating App Store.

For me, I use iPhone entirely because pixel doesn’t support cardav and caldav out of the box…if I can’t use PWA’s on my phone then I’m going back to android cause I can solve the email problem easier than I can solve the productivity tools not being available via PWA’s.


Google should in theory have the same play store revenue motivation to hide PWAs, right? Granted, they also want people to stay on the web to continue using Google.com, so I guess those are two competing priorities.

That to me is a bit of an indicator that Apple just doesn’t believe in the merits of the technology. I think they might be asking the same question in asking: what problem is this solving?

Every platform with a web browser has a better way to run applications, which is to just run an application. A web site that is masquerading as an installed application is basically just a less capable application.

As a side note, I’m also not really sure how an app store can be considered scammier than the entire web. The web is a Wild West with far fewer “rules” than the Play Store.


Kind of, it's just that the approach Google takes is a lot more palatable than Apple's. As someone who has written a PWA (albeit one that almost entirely relies on SSR), Google's PWA approach is definitely better than Apple, but there's some marked issues.

For one, the actual PWA packaging process gets shunted off to a Google server; I think you can make a "thin client" APK from a manifest using a tool they wrote some time ago[0] (Twitter Lite is one of these), but I've not really looked into it. It's not quite the extension to Chrome you'd really want it to be; if you use a non-Chrome browser on Android, it means you can't really ditch the Chrome dependency if you want to use a PWA. (Further not really helped by the fact that Google is basically the only PWA implementer on Android, since Firefox does not consider PWAs a priority whatsoever.) Similarly, Google's servers need to be able to read out the manifest declaration, which makes them unfeasible for intranet software unless you want to punch a temporary hole and expose it to the internet for a bit.

The other kinda annoying thing Google does is really aggressive degradation between PWA and homescreen shortcut. If the manifest isn't entirely up to snuff in terms of what's listed, there's no attempt at trying to resolve the issue, it just instantly degrades to a homescreen shortcut. A basic example of this is the requirement to use a service worker (even if the service workers entire job is to do nothing); it's not really stated in the manifest spec that it's required, but if you don't have one, the PWA straight up refuses to install as a PWA.

Google's strength with the play store really mostly comes from their bundling advantage; Play Services and the attached Store and Google Apps are required for OEMs to add to their devices (might change with the DMA?). That's the kinda odd reality that makes Apples desire for control seem so extreme - we know what an open platform looks like on Android. It works pretty well for the most part and the incumbents advantage for a store is large enough that almost every app developer submits to the Play Store regardless.

[0]: It's called Bubblewrap - https://github.com/GoogleChromeLabs/bubblewrap


Tend to agree with all of this. Manifest is way too finicky.

Would be interesting to see how the play store changes in the event of Android honoring code signing for side loading like windows. Eg..no scare screen on side loaded apk’s as long as they’re code signed.

I suspect the App Store would live on as a consumer focused App Store and the enterprise apps would direct distribute which makes sense anyhow cause IAP does t understand account based pricing.


Android doesn't do scare screens actually. The only real difference between installing an APK from the play store and an APK you found on the internet is that the application calling the installer has a one time "OK" to make sure you are the one who wants to install an APK; Play Store has this as well, but the default distribution has it turned on, by going in the settings you can fiddle with it and turn it off if you want to.

The only thing actually needed for feature parity with the Play Store is mostly just that F-Droid can't auto-update; the Play Store can skip the update/install prompt screen, F-Droid can't. They added install origins to APK files last year iirc, so there's a likely chance they're allowing it though.


Yeah, still have what equates to a scare screen. Tells you file may be harmful upon download, then you need to change a setting which is streamlined to what it was before, but still a scare screen. Now you can allow from source…but the source isn’t the web address, it’s the initiating application eg. Chrome or Files so there’s a huge security hole with this implementation presumably on purpose to manufacture the incident they need to justify their behavior.


I’ll have to test this tomorrow. Last time I tried sideloading direct from our website I had to flip a switch in settings which came with a scare dialog. If I remember correctly, it was a system wide setting too and didn’t allow for trusting specific sources. If we can self distribute on Android, that will be 3 out of 4.


>Google should in theory have the same play store revenue motivation to hide PWAs, right?

Google in theory has a financial motivation to make their competitor Apple look like the bad actor.


Google have an interest in moving people away from desktop applications because they don’t have a desktop OS (not counting Chromebook).

We run 3 SaaS apps. One is strictly native, and the other two are strictly web. Writing for 4 platforms on the native app is an extremely expensive exercise and then we are also subject to the insanity that is the App Store. Long story here, everything from App Store review times on mission critical software to the fact that their billing mechanism simply doesn’t work for B2B SaaS…and by the way, we get zero traffic from the App Store as that’s simply not where our customers are looking for the solution we provide. Fortunately, bulk of our customers start on desktop where we self distribute (code signing on windows and notarization on mac) with ev ssl on marketing sites. Why is the App Store scammy over the open web…search for any number of popular apps and look at how many have been cloned. Sure, you can do this on the web with paid ads and enough SEO effort but it’s much harder.

To this day, Apple continue to allow keyword stuffing, advertising on trademarked names, and blatant copyright infringement in app descriptions and even I (fairly tech savvy) accidentally purchased a clone of poly bridge for my kid cause they’ll list the clone above the real one on an exact term search. What was apples response when I said I purchased the wrong app? Tough cookies!

This is the same reason I hate shopping on Amazon. I simply prefer to have a direct relationship with the companies I buy things from, and from what I can tell, our customers prefer have a direct relationship with us.

But back to why PWA’s are awesome…simply put, iteration time. We can publish dozens of improvements every day and roll back instantly when an issue arises. We simply can’t do that with native as long as the Apple / Google act as a gate keepers. When we allow proper sideloading without the scare tactics and dirty tricks, we’ll take the time to build native again.


> why PWA’s are awesome

You've described some advantages to you as a developer. For the average user, apps that change all the time and effectively make them a tester aren't such a no brainer!


Resolution time on native is longer than web. Bugs happen, native, web, doesn’t matter…bugs happen.

Re benefit for who. We will invest our time where it makes the most sense. If you’re familiar with platform risk, you’ll understand that we’re not exactly eager for our existence to be subject to the whims of Apple and Google.


You think that a technology that allows mobile apps to be developed and distributed in a way that’s secure, free and open, and platform-independent is a solution in search of a problem? Honestly?


Yes, just like every other cross platform GUI has been a dumpster fire since Java Swing all the way up to Electron.


>technical solution looking for a problem

In some regards yes. In practical regards they're a threat to app store margins (on all app stores, not just Apple), so there's no incentive to truly support them other than developers being loud about it.

>I don’t even know where to find one.

Because Apple has crippled the ability for you to use them, so developers can't really spend time working on them. Chicken and egg problem.

>if Apple is complying

They're not really, they're twisting and turning as much as possible to look like complying but make the desired outcomes even more difficult to achieve.


Isn’t all regulation about activities, not outcomes?

If a regulator enforces a ban on dihydrogen monoxide in a misguided attempt to reduce global warming, should companies comply with the regulation or the presumed intent?

The EU is demonstrating the folly of legislation tech product design at this level of detail.


> dihydrogen monoxide

Heh! Also known as hydroxyl acid. It’s the major component of acid rain.

;)


It came out in the Epic trial that 90% of App Store revenue comes from in app purchases of pay to win games. They are not going to all of the sudden move to PWAs and on top of that, they already use cross platform engines.


I also don’t know where to find one on my Windows PC.


I mean, the problem is the same one introduced since the two big mobile platforms were established: "I want to publish to IOS/Android as a native app without needing to have two separate builds to manage". PWAs make that pitch to those who already have websites to triple dip. It never has to promise to be as good as a native app, just "good enough".

Does it live up to that? YMMV. It's probably fine for very simple apps, probably comes apart at the seams for anything trying to look modern or have fancier functionality.


The "two big mobile platforms" were not established by an irreversible act of God. Before the current time of two platforms, there was a time of (mostly-)one platform i.e. the Web, and that platform had quite a few nice features.

One of the small conveniences is indeed that you didn't need to develop the same thing twice, which made the barrier to entry much lower. The functionality that you were exposing to users did not need to pass a review at one of two US tech giant companies, which could reject publishing it for any or no sensible reason at all. You were not forced to pay 30% of your revenue to the gatekeepers of the platform. You were not banned to invite users to buy your product in any way that works for them, even if it meant sending you checks over carrier pigeons. There was no _chokepoints_ that a single company could squeeze to further its own interests (after the collapse of IE).


>There was no _chokepoints_ that a single company could squeeze to further its own interests (after the collapse of IE).

Google Chrome would like a word...


I've built large, complex and beautiful healthcare apps as a PWA.

The only two things I've ever missed from native functionality are:

- background geolocation

- push notifications on ios

The second one was fixed recently.

In contrast, from what I've seen 90+ percent of apps I see in the app stores would be better as a web page / PWA.


But the real question is where most of your users live.

I’d take a decent wager that most of your users are most familiar with apps and would prefer installing full apps.

Doesn’t matter that most apps would be better suited to being a web page or PWA if that’s not where the users are. That’s kind of like saying that PCs are better at gaming than consoles. Yes, that’s true, but that’s not where the majority of users are.


>But the real question is where most of your users live.

Well, they "live" on their phone. I would just put a button on my website to install the app, users would find that easily.


I mean, PWAs aren't made with the goal to maximize User UX. It's a cost saving measure like any other solution that isn't making 2 dedicated native apps for IOS/Android.it won't get as much traffic as a native app, but it's almost "free" to deploy.

To use the gaming console example, it's not unlike using an emulator to launch your game on PC (if you could somehow monetize an emulated rom). It's not the ideal experience, but it requires very little extra work.


I find PWAs to have a vastly superior UX. I can trust that they are running in the strongest sandbox my device has to offer. I don’t have to download anything, and I don’t have to update anything. I don’t have to remember any account passwords to install anything, and my ad blockers and password managers just work inside them. I don’t have to worry about arbitrary content policies of Apple or Google, the app can just show me whatever it wants.


It allows us from our webapp to easily allow a user to i.e. PIN a section of the app onto the homescreen (e.g import photos into this folder).. really nice.


So what's a Home Screen Web App in this context? Is it adding a bookmark to the home screen (you open it, and it opens in the regular full iOS Safari), or something else?


The only PWA that I think gets any use on i(Pad)OS is that for the Financial Times.


I thought that was gone but you’re right, app.ft.com still works and can be installed as a full screen PWA. But the main site, ft.com, isn’t a PWA (or at least, it doesn’t install as a full screen web app). I had assumed they had shut down the PWA, because I haven’t seen any promotion/mention of it for years (and I use ft.com a lot) so I don’t know how regular people would find out about it these days.


It’s just iOS and macOS.


I recommend that everyone interested in this topic read some of the comments from PWA developers at: https://bugs.webkit.org/show_bug.cgi?id=268643

Apple’s decision is going to kill businesses and break apps used by hundreds of thousands of people in Europe, many of whom are healthcare workers delivering patient care.


Apple doesn't care, unfortunately for humans. Jerome Powell of the US federal reserve knew that he would put companies out of business, and people would lose jobs, when they raised the rates. In fact, that was the goal.

"In September, hiring was much greater than had been expected, with the unemployment rate staying near a half-century low. Strong hiring typically empowers workers to demand higher wages, which, in turn, can worsen inflation if their employers pass on the higher labor costs by raising their prices."

https://apnews.com/article/federal-reserve-inflation-economy...


Patient care apps as PWAs? Yikes.


Patient care apps as native blobs for selected platforms? Yikes.


What's unusual with it? I even do my online banking exclusively via web browser.


Eric, we need answers!


What's the concern here?


From Apple’s PoV, PWAs don’t earn them any money, aren’t forced through review by Apple, and decrease lock-in. There is no incentive for Apple to support PWAs.


So it is now their fiduciary duty to enshitify the web? Nice system


That cringe neologism refers to shifting from making money by delivering value to users to making money by exploiting the user base.


Enshitify ChromeOS actually.


>The whole reason they are low usage on PWAs is because of a lack of investment from Apple

I don’t know if this ironic given that apple originally didn’t want to support native apps and gave in due to developer demand.

Apple both did and didn’t want web apps


So are PWAs really popular on Android?


I think the advocate retort is that lack of support on iOS makes them a nonstarter for developers on all platforms. I think this argument is more of an excuse.


Right, Android has something like 70% global marketshare. PWAs aren’t popular because they don’t really benefit developers/businesses. They also don’t offer any advantages in user experience over a native app. Apart from the economics, there’s no developer friction advantage since you can use something like react native and deploy anywhere.

The kind of deep user information you can gather by installing a full blown app compared to a more sandboxed web app is worth way more than the 30% royalty cut.


What world are you living in? Web apps are literally 100+ times faster to start using, much easier to share, much easier to market, and you can offer much cheaper services as apple doesn't take a large cut of payments.

That's just a few of many advantages.


If what you say is true then you could find a platform bigger than something like TikTok or WhatsApp that is a PWA. The only one I can think of is Google.com, which technically is built in to your mobile OS anyway.

100+ times faster to start using: are they? I can type in the name of an app into my OS-wide search and tap “get” and that’s it. Swipe down, type “candy crush,” tap “get.”

Easier to market? What’s easier than saying “download the [name] app?” Arguably more complicated to say “go to example.com”

Much cheaper services? What is cheaper than TikTok or WhatsApp? Those companies make more money on the apps because they have more user data collection. Companies like Netflix go around the App Store cut entirely.

With installed apps the desires of the corporations and users pretty much align.


70% of marketshare isn't the important part, it's what the share of potential revenue is. And it's well know that iOS has more revenue per user.


There is great value in building one product instead of three.

>The kind of deep user information you can gather by installing a full blown app compared to a more sandboxed web app is worth way more than the 30% royalty cut.

What kind of information is that?


Great value to whom? The only value I've ever heard of that made any sense at all was "saves me money and lets me change things and publish them faster" and that (as other commenters have said) is a developer / manager value, not a user value.


Developer value is totally user value. The developer "changes things and publish them faster" for the customer, it's not a hobby.


It's tempting to think so, but IME users download apps to get things done more than they want to "ooh" and "aah" over an app's UI changes and I've been an app developer since 2009. It's all too easy to push out someone's pet feature (or something to buff up someone's resume for their next job) and if it's a speed-focused company it's a coin flip whether there is someone acting as the gatekeeper to keep that kind of nonsense out.


I can’t believe Apple is holding back my vision for a resurgence of COBOL apps. If only Apple would support native cobol apps, surely Android would follow and the world would see peace and prosperity forever. /s


> The whole reason they are low usage on PWAs is because of a lack of investment from Apple and a lack of parity

This is a trite argument that hasn’t been true ever since Jen Simmons joined Apple in 2020 and changed the course of Safari significantly to the point that PWAs not only are viable, they have been given feature parity with native apps on many fronts.

Simultaneously, the argument completely bypasses the fact that install rates of PWAs are abysmal on any platform. Whether it be iOS, Android or Windows.

Contrary to what PWA developers, industry organizations and other stakeholders proselytize, PWAs aren’t the second coming and the next best thing since sliced bread. At least not when it comes to install rates.

Edit:

Don’t get me wrong, I’m sure they’re great as “websites”.

Lord knows people who sell PWAs[0] love to brag about bounce rates and conversion rates and what not. But there’s a reason why you can find barely anything about install rates other than some vague statistics about individual unnamed PWAs[1] or PWA sellers[2] talking about obviously bogus 10x and 3-5x install rates, and it’s not because the PWA crowd is too shy to brag.

0: https://www.pwastats.com/

1: https://developer.chrome.com/blog/pwa-install-features

2: https://mobsted.com/pwa_vs_native_mobile_apps_install_rates_...


That's kind of the point, PWAs don't have parity on any platform, but Apple's platforms are the only ones where it is being positioned as a legitimate alternative; Android has "sideloading", Windows has REGULAR loading. It doesn't matter who joined Apple when and did what, PWAs on iPhone are not like native apps, it's not even really close. It's good that this pathetic line of argument wasn't much of a deterrence for the EU.

What people want isn't PWAs, they just want the kind of capabilities that computers have had for decades, including many of Apple's current computers for sale today. To be able to install an application and run it.


> That's kind of the point, PWAs don't have parity on any platform

That’s not true, nor what I posited. PWAs have almost all the native features, if not all, depending on the platform. Plenty of “pro-PWA” people go out of their way to demonstrate this[0].

I’m talking about install rates and usage by end users in a way similar to using a native app.

Whether you agree on parity or not, you seem to concede that PWAs aren’t wildly adopted the way native apps are.

As such, it makes sense that Apple wouldn’t want to waste engineering resources on it by rewriting the underlying architecture, which is the topic at hand.

That in and of itself ends the debate.

You then go on, OT, about whether Apple should or shouldn’t position websites and PWAs as legitimate alternatives.

Saying:

> but Apple's platforms are the only ones where it is being positioned as a legitimate alternative

Specifically, Apple states[1]:

> If the App Store model and guidelines are not best for your app or business idea that’s okay, we provide Safari for a great web experience too.

An alternative isn’t, as you seem to imply, an identical option; instead, it is simply understood to mean a different choice, usually a choice different from what is usual.

One might say, "In the absence of a better alternative, we’ll have to proceed with our original plan.” This use in and of itself implies that one option is better than another, thus not identical.

Whether something is “legitimate” or, more specifically, a “legitimate alternative” entirely depends on the person making the consideration and the value judgment they make based on their needs and wants.

I might consider soda a “legitimate alternative” to coffee because I’m just looking for a beverage, whereas a different person might not deem it a legitimate alternative. After all, they are solely interested in a warm beverage.

With that in mind, I consider web pages, particularly PWAs, a legitimate alternative to native apps because most native functions are available to PWAs on iOS. You might not because your need might be one of the few things PWAs can’t provide.

That doesn’t make it a bad-faith argument on Apple’s part; they never claimed that PWAs are an identical option to native apps via their App Store. They offered up an alternative that can provide some, if not most, of what a native app can provide.

You continue with your OT by presenting a false equivalence

> Android has "sideloading", Windows has REGULAR loading.

It’s a false equivalence because neither Google nor OEMs present sideloading as a legitimate alternative; it simply exists, but it’s not promoted as an alternative option.

Google specifically likes to write copious amounts of words in blog posts[1] and whatnot, talking about how great PWAs are while wearing their Chrome hat. Meanwhile, the PWA experience on Android is marginally better than that on iOS, provided you use Google’s browser. Where is your indignation for that? They’re promoting PWAs harder than Apple will ever do.

For that matter, Microsoft also doesn’t call “regular loading” a legitimate alternative, so again, your equivalence makes no sense.

> It doesn't matter who joined Apple when and did what

Of course it does; if you don’t go OT, that is. Whether Safari is or isn’t suitable for PWAs is essential to assess if PWAs are used in meaningful quantities.

If someone posits that Safari doesn’t properly support PWAs when that isn’t true, like GP did, then it’s important to point that out and provide context on when that changed.

It doesn’t matter to you because you’re having an entirely separate discussion.

> PWAs on iPhone are not like native apps

Yes, they are.

As stated above, they’re not identical, but they are similar to, or if you prefer, “like” native apps.

> it's not even really close

This is a value judgment because it requires that you and I agree on the definition of “close.” I argue that they’re pretty close because they can do about 90% of what native apps can do.

> It's good that this pathetic line of argument wasn't much of a deterrence for the EU.

Let’s keep it classy and within HN guidelines.

> What people want isn't PWAs

Hence, the low install rate of PWAs and why it’s not weird that Apple didn’t decide to spend engineering resources on rewriting the underlying architecture for PWA installs.

Again, that, in and of itself, ends the debate.

> they just want the kind of capabilities that computers have had for decades, including many of Apple's current computers for sale today. To be able to install an application and run it.

I’m not sure what you base this on.

From here, it looks like you’re projecting your own wants onto the average iPhone user base at large. Do you have anything that expands on how many iPhone users share your vision?

The commercial success of iPhones suggests that not many seem to care for this.

I suppose alternatively, you could argue that the fact that Android dominates globally indicates there is a demand for this in the smartphone market[2]. Still, the obvious question then becomes why those iPhone users wouldn’t just join in Android’s dominance and switch over, particularly those who feel so strongly about this that they’d spend their time online lamenting its absence.

0: https://whatpwacando.today

1: https://developer.apple.com/app-store/review/guidelines/#int...

2: This is simplified, of course; one feature wouldn’t be the sole driver of Android’s dominance


I'm not going to go point by point on this one, but I do have some remarks. I am not "projecting", I own multiple Apple devices, therefore, I am very well within my right to talk about what I want as an owner of Apple hardware and on behalf of likeminded users, even if people on Hacker News don't like that fact as is evident from time to time. Wanting "sideloading" aka regular loading is not wildly off topic, it's literally MORE on topic than PWA vs native app parity, which is really not relevant to the EU DMA compliance issues at hand. And on that note, of course PWAs do not have parity with native applications. They're quite a lot slower, for starters. Is anyone shocked? No... it's not weird that it is much slower when you are going through Webkit instead of native APIs like Metal, in WebAssembly and JavaScript instead of C and Swift. That's disregarding the fact that both policy-wise and in what APIs are available, clearly PWAs have significantly more limited access to integrate with their host platforms, which again, is hardly surprising for glorified bookmarks.


web apps are websites with standalone

the name "install" is bad and the wording is NOT a web standard, NOTHING is installed

the question is web capabilities

one core capability is caching and offline via service workers

no need for "install" for this

"installing" a web app does not even need anything anymore, not even offline or service workers... it is ONLY switch to standalone and get a launch button or be integrated into app launchers on OS

behind "install" is a bad and immature web app manifest api, it is a draft... the wording install must go

it is one of MANY possible web capabilities for a web domain to be able run standalone and get a button

apple cannot ban this since a shortcut to chrome cannot be deemed unsafe, where then CHROME decides to run standalone or not

the real problem is NOT that safari kills standalone

they try to kill a lot of web capability, like service workers, and NOT JUST FOR SAFARI

I mean this will not stand, you CAN stay apple-level-safe (whether it is more or less than other platforms) by CHOOSING safari

it is an obvious CHOICE to be granted to trust google, mozilla or microsoft and their web security model to stay safe with THEM on the web

no argument why this should not be allowed if other native apps are allowed

and come on, even mac os is safe with service workers in chromium


So why is there also low usage on Android?


how do they know low usage if there is no download from apple?


Most likely telemetry in iOS itself. iOS knows when users pin web pages to the home screen, and iOS knows each time a user taps on and opens those pinned web pages.


Apple are extensively tracking users, that's how they can know.


Because they know what’s on your Home Screen If you enable Usage analytics?


welcome to tradeoffs and unintended consequences.


> not providing similar marketing or anything for PWAs

It's functionality to add an arbitrary webpage. What exactly are you expecting them to "provide"?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: