In context 99% of the users I meet don't even know what USB-C is.
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 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.
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...
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.
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.
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.
Literally many people do not care enough to understand it. It's just a modern necessity, a tool.
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...
Buy stuff that's up to spec, and it'll be fine.
Higher power levels beyond 60W are optional. The newest PD spec goes up to 240W (5A @ 48V).
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.
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.
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.
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.
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.
The problem is all the non-conforming cables that people have, that look exactly the same as conforming cables.
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.
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.
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!
The only case where you may need a different (non-passive, "e-marked") cable is when going above 60W (3A).
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)
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?
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.
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.
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
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.
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.
Google in theory has a financial motivation to make their competitor Apple look like the bad actor.
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.
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!
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.
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.
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.
Heh! Also known as hydroxyl acid. It’s the major component of acid rain.
;)
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.
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).
Google Chrome would like a word...
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.
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.
Well, they "live" on their phone. I would just put a button on my website to install the app, users would find that easily.
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.
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.
"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...
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
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.
That's just a few of many advantages.
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.
>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?
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.
1: https://developer.chrome.com/blog/pwa-install-features
2: https://mobsted.com/pwa_vs_native_mobile_apps_install_rates_...
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 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.
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
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
It's functionality to add an arbitrary webpage. What exactly are you expecting them to "provide"?