Any chance we can get the original title which doesn't sound so childish:
It’s Official, Apple Kills Web Apps in the EU
And if PWA were such a threat to Apple's business then why are they allowed in US.
It’s Official, Apple Kills Web Apps in the EU
And if PWA were such a threat to Apple's business then why are they allowed in US.
Adoption of PWA on Apple platforms is low because they've always had a significantly degraded experience when compared to PWA on Android, ChromeOS, or desktop browsers other than Safari.
With the right engine basically any kind of app could be created as a webapp / pwa
So in the US it doesn’t matter because users are still stuck with Safari there
Do you know that the only "alternative egnine" that implements hardware APIs is Chrome? Because it's a Chrome-only non-standard that Firefox opposes, too?
I don’t think Apple can tell alternative browser engines what features it will allow and which not. Or is there something in the EU regulation that says browser engines must follow a standard?
Indeed. People cry "Safari is the new IE" and then literally turn around and say "well, who cares, Chrome has dominant market share, so if it only works in Chrome, it's fine".
As a reminder, United States v. Microsoft Corp. was never about IE's market share. It was about the illegal monopoly manipulation of Windows to prevent third-party browsers from competing. With that in mind, Safari absolutely could be the next IE.
The argument may have worked 10-15 years ago. Since then Chrome has captured majority market share (among other things deploying, clear anticompetitive practices [1]). They now dominate all the standards bodies and shit all over the standards process by shipping whatever they damn please to the sycophantic cheering from the sidelines.
So it's not "you need a competitive browser", because both Safari and Firefox are plenty competitive. It's "you need to ship whatever features Chrome ships at neck-breaking speed, all consequences be damned".
[1] Former Mozilla exec on Google sabotaging Firefox https://archive.is/tgIH9
The story of how Google drove the final nail in IE6's coffin is funny until you let the implications set in https://www.theverge.com/2019/5/4/18529381/google-youtube-in... And yes, "only works in Chrome" is a frequent enough appearance to warrant a worry.
Given that Chrome isn't shipping ActiveX or Flash, what's the issue? Apple and Mozilla decide how (or if) they want to implement each standard. If there's no demand for the feature, it shouldn't be a problem ignoring it. If icky features like WebUSB and Bluetooth are terrible, users won't notice anyways.
I've daily-drove Firefox for close to 5 years now, but Chromium is simply better-developed in a lot of ways. It integrates better on Linux and doesn't ship with annoying adware that nags you with pop-up modals. I don't want Google's browser engine to be the best, but I don't think I'd be using Firefox today even ignoring compatibility concerns. Safari isn't even an option to me, not that I'd willingly pick WebKit anyways.
> And yes, "only works in Chrome" is a frequent enough appearance to warrant a worry.
Crocodile tears coming from an ecosystem where "only works on iOS" and "only works on Mac" is the default. Apple is not the savior of the free web, and if the openness of the internet relies on their goodwill then it is already lost.
Google's strategy is pressuring Apple to make more capable software. When a user has more freedom in a browser than they do in their hardware's native runtime, something is gravely wrong (and you can't blame the browser).
What does this have to do with what I wrote? Literally nothing
> Apple and Mozilla decide how (or if) they want to implement each standard.
For something to become a standard there needs to be consensus, and at least two independent implementations.
Just because Chrome ships something doesn't make it a standard.
> If there's no demand for the feature, it shouldn't be a problem ignoring it. If icky features like WebUSB and Bluetooth are terrible, users won't notice anyways.
Neither WebUSB nor Bluetooth are standards. There status is literally, and I quote, "It is not a W3C Standard nor is it on the W3C Standards Track. "
> Google's strategy is pressuring Apple to make more capable software.
That's not Google's strategy, and never has been. It's also quite telling you decided to ignore Google's clear anti competitive practices. I guess by sabotaging Firefox they were also "pressuring Firefox into making more capable software or something".
It amazes me to no end that Apple/Safari haters will contort themselves to no end to justify Google because Chrome can do no wrong.
> When a user has more freedom in a browser than they do in their hardware's native runtime
Google couldn't care less about the end user. All Google cares about is its dominance. To that end it doesn't care if it breaks the web [1], or twists it to their liking [2]
[1] Speaking of breaking: Breaking the Web forward https://www.quirksmode.org/blog/archives/2021/08/breaking_th... and Stay Alert https://dev.to/richharris/stay-alert-d but you will ignore these, too. Because it's not "ActiveX or Flash", innit?
[2] People keep mentioning sites like https://whatwebcando.today/ and https://whatpwacando.today/ and they are filled to the brim with APIs that Chrome ships and whose status is "not on any standards track".
Everything, really. ActiveX and Flash were proprietary runtimes, which is a real example of a domination play. To my knowledge, Chromium doesn't feature anything that couldn't be reverse-engineered or conditionally re-implimented by third-parties. Maybe some things are nonstandard, but if there's user demand for it then why complain? The native iOS runtime clearly isn't making everyone happy.
> I guess by sabotaging Firefox they were also "pressuring Firefox into making more capable software or something".
Nobody but you has been talking about Chrome's anticompetitive practices in this thread. I might actually agree with you, but I'm not going to discuss it because it's tangential to Apple's own anticompetitive practice.
> Google couldn't care less about the end user. All Google cares about is its dominance.
I'd have an easier time believing you if I couldn't use the web with my Open Source browser.
> but you will ignore these, too.
Both of those posts are actually valid complaints, and they're just as valid when the breakage is on Safari's side. Much as you'd rather minimize it, "who owns the web" is also a valid question when leveled against Apple too.
Nothing at all, really
> To my knowledge, Chromium doesn't feature anything that couldn't be reverse-engineered or conditionally re-implimented by third-parties.
To your knowledge. It's just Chrome-only Chrome-specific code inside a 50-million-line codebase that may or may not depend on very Chrome-specific things.
> Maybe some things are nonstandard, but if there's user demand for it then why complain?
Because you've just literally supplanted standards processes with "whatever Chrome ships is standard now". Are you even aware that Chrome ships 400 new web APIs a year?
> Nobody but you has been talking about Chrome's anticompetitive practices in this thread.
Indeed. Very few people talk about Chrome's practices, period. You could look up the thread why I started talking about Chrome's practices.
> I'd have an easier time believing you if I couldn't use the web with my Open Source browser.
Ah yes. The only thing that's needed for a company doing whatever the hell it wants is to provide the source. Who cares if no one has any say on what gets implemented in that browser. Who cares if even that company admits that no one contributes to that browser: https://twitter.com/RickByers/status/1715568535731155100
I mean, you could use the web with internet Explorer, too, so why complain?
And yes, there's an increasing number of sites (including sites from Google) that carry the "only works in Chrome" or equivalent banner. So no, increasingly I cannot use the web using an open-source browser of my choice.
> Much as you'd rather minimize it, "who owns the web" is also a valid question when leveled against Apple too.
I don't minimize it. I point out the one-sidedness of the judgments leveled against Apple.
If you want to circle back around to the point, I'm glad to keep discussing it.
The core problem is not Chrome's adoption of random features. It's Apple's neglect of the native platform, which in turn creates demand for absurd workarounds. As I said way further up in the thread, they're not pushing proprietary browser extensions; so how is it anticompetitive?
Whether Web Bluetooth, Web HID etc should be implemented in a browser engine is really irrelevant in this context - but the thing is they CAN be implemented in a browser engine. So can pretty much any native functionality currently guarded by the App Store.
I wish Firefox had WebBluetooth or another API that could do that.
But then Mozilla instead of helping set codec standards that everyone could use preferredyto show you could run codec in JS and opened a way for EME
EME has nothing to do with Bluetooth.
only safari and firefox did not implement it according to: https://caniuse.com/?search=web%20bluetooth
which might be great because you have the choice...
and you can use open source chromium or brave (like the jvm to run cross platform java) to run web apps seemlessly that need web bluetooth or such but use safari or firefox for personal use if you find them more secure
I mean using chromium engine as the running environment where chromium only ever runs special trusted web domains and never goes to other "malicious" web domains that may fuck up iOS as Apple claims would be still a secure choice
like you will not download spyware from Apple Store because you are an adult not because Apple can protect you there
Ah yes. Browsers with near-zero market share (aside from Edge which hovers around 4% market share) that have literally no say in how the engine they are using is developed, and what features go into it.
You know how I know that? Because Google themselves admit it's a problem: https://twitter.com/RickByers/status/1715568535731155100 The largest contributor to Chrome that is not Google is none of those browsers and is barely above 1% of all Google contributions.
Not sure why this is such a threat.
I’m torn on this whole issue. I both enjoy my walled garden and want full-fat Firefox on iOS.
That is, the discourse is valid, and Apple is to blame. But why did it have to be around PWAs of all things?
(I don’t personally enjoy working with JavaScript, but the reward of truly cross-platform development makes it worth doing when it’s a viable option.)
I am currently building an app for internal use, and because I’m obsessive about presentation, I ironed out every wrinkle in this department. It’s 100% fluid, there are no layout shifts, no surprises anywhere. You would never know it’s not native. But I will admit it took a lot of effort to hunt down all the little idiosyncrasies and fix them.
I think a problem with frontend web development is that there are a lot of mediocre practices that became standard operating procedure. When I do this type of work, I try to keep the dependencies very lean and write a lot of stuff from scratch.
it is just totally possible, there are so many web api-s, you just need to be a good programmer and study a lot
you will not really find or use big web apps because
1. most companies have already built their native apps with mobile engineers
2. web "programmers" or rather designers are stuck with old tech
3. web apps will start to become strategic targets(!) by most developers/companies if you are sure they are cross platform (which was crippled by Apple and now they even try to eliminate modern web capabilities on iOS
The whole discourse around PWAs is frankly schizophrenic.
Web apps (esp. Electron-based) on desktop: universally regarded as bloated, slow, resource-intensive for the simplest tasks, breaking platform conventions etc.
You add a P in front, and talk about mobile? Oh, PWAs are the bee's knees, just as good or better than native etc.
And yet, when you ask for examples of these amazing apps (after all, Android with full PWA support has dominated mobile market for over a decade) we get either silence or... Twitter.
There are not many good example of great PWAs precisely because Apple has been crippling web capabilities on iOS by banning other engines and degrading the experience in Safari for a decade.
> PWAs do not need to be wrapped in a browser engine of their own, they use the installed browser engine.
Ah yes, they don't need a browser engine, they just need a browser engine
> They are not inherently bloated or resource-intensive in any way.
So, let me get it straight. A web app running inside a web browser engine is bloated, slow, and non-performant when it's on desktop. But the moment you put it on mobile it's not?
> There are not many good example of great PWAs precisely because Apple has been crippling web capabilities on iOS by banning other engines
Two notes:
- Which of the features that Apple "crippled" will help web apps not be bloated, non-performant, slow, with bad UI etc.?
Is it the lack of an install banner that makes a web app struggle to display even a static text with any semblance of performance?
Is it the lack of push of notifications that make Google say: okay, we give up, most sites load in over 2.5 seconds now, so we assume anything faster than that is a win [1]?
Is it <the list is frankly endless>...
- Android has been a dominant mobile OS for over a decade with "non-crippled" PWA support. Where are the not inherently bloated non-resource-intensive web apps we've been hearing about? Please say Twitter :))
[1] https://blog.chromium.org/2020/05/the-science-behind-web-vit...
The second one especially stings - Apple might be throwing out a perfectly fine feature that I used a lot. Not everything needs to be on the app store - what exactly can I do now to put an icon on the home screen for a user base of 5 people? Something like this would never pass app review.
> So, let me get it straight. A web app running inside a web browser engine is bloated, slow, and non-performant when it's on desktop. But the moment you put it on mobile it's not?
A web app doesn't require that you bundle an entire Chrome runtime with the app. There's a lot of your "bloated" right there. You've been told this several times, so it seems that you're being deliberately obtuse.
As far as "slow and bloated" as a whole, my (several years old) phone has 64 GB of storage, a hexacore 3.22 Ghz CPU and a quad-core GPU.
I. Just. Don't. Care.
I'm old enough to remember the exact same "slow and bloated" crapola when programs written in C (and, at that time, Pascal) started replacing hand-coded ASM. Now, modern C compilers are pretty whizzy, but at that time coding in C entailed a significant size and speed penalty.
Are you still writing in hand-coded ASM?
Yeah, that's what I thought.
If you don't want to use web apps, or Electron apps, don't use them. No one's forcing you to use them at gunpoint, mang.
Better yet, write your own "fast and slim" apps and take away the market for the "slow and bloated" ones.
I also use "web apps" in the browser. I struggle to find a single one that doesn't fit the description. Well, I know some, but when ask people like you to give examples, there's either silence or some ridiculous thing that only proves my point.
> I. Just. Don't. Care.
Indeed
> I'm old enough to remember the exact same "slow and bloated" crapola when programs written in C
Non-sequitur
> If you don't want to use web apps, or Electron apps, don't use them.
I would if devs like you didn't have your attitude of not caring and shipped other than shit
> Better yet, write your own "fast and slim" apps and take away the market for the "slow and bloated" ones.
What's stopping you from creating such apps? Just your "I don't care we have supercomputers so I'll use the technology that struggles to even display some static text on it"?
it is a responsive website, they do not have native apps, you can still use it on a phone
I just checked you can use it standalone if you want to, I myself choose to use this website from the browser on linux... but I actually "installed" it on android and if I used my mobile more, I might just want to use this "app" this way
every website is a potential web app if written responding to screen sizes correctly
inherently nothing is bloated...
actually, I do not really understand why you hate web apps that much, just do not use them! use them in your favourite browser or whatever
whether a sotware shit or not, depends on the developer, not whether it is c++, java, swift, android-java or js...
> it is a responsive website, they do not have native apps, you can still use it on a phone
I see a largely static site with very little functionality.
During search the site jumps when the progress bar disappears, so you can easily misclick on items in the list (I did at least once).
During checkout it takes a second or so to add additional items to the order (could be long network connectivity, but there's no indication on the page).
I'm supposed to be impressed? You call this an application?
GoDaddy of all sites had all that in mid-2000s. Just checked: they still do, and it's faster, the page doesn't jump around, and additional selections are applied immediately. If something takes time, there's a loading indicator (inline if needed).
Okay, I decided to sign up and see what's there. Literally nothing works, but that's not really important. Here's the sad/funny part:
A static page showing domain details with literally just text on the page and a few icons requires 2.5 megabytes of Javascript.
Yes. This page with almost nothing on it needs 2.5 megabytes of Javascript: https://dmitriid.com/media/6/b/1/f/912c-e91b-4530-af54-09247...
Yes, you said it correctly: "inherently nothing is bloated". You still managed to bloat it. Go and read "Performance Inequality Gap 2024": https://infrequently.org/2024/01/performance-inequality-gap-... (I don't agree with Alex Russel on many things, but his performance analyses are always spot on).
> every website is a potential web app if written responding to screen sizes correctly
Honestly, web people should leave their bubble at least for a nanosecond from time to time. No, a site displaying a few hundred lines of text and a minimally functional checkout (and still doing a rather poor job of it) is not an application.
Having a responsive design does not make a website into an application.
> I do not really understand why you hate web apps that much, just do not use them! use them in your favourite browser or whatever
Because I'm forced to use them as they are the cheapest fastest way to make stuff for people who wouldn't know a good UI/UX (and good apps, and good programming practices) if it stared them in the face. And who cannot even design a text page without requiring enough resources to power a small town.
> whether a sotware shit or not, depends on the developer, not whether it is c++, java, swift, android-java or js...
And yet, the shittiest software is somehow still made for the web, en masse.
but here I am, the reply is: hover is a minimalistic usability example, I will not show my website yet, but I know it is totally possible for good or very-good programmers to write in application style, using web tech
try this one: https://web.telegram.org/k/
the writers are mathematicians I guess, russian minimalists... I remember I checked their site and it did not seem to use bloated stuff
compiled native UX code may be less kb than minimized js but actually I have never seen comparisons and I do not know much about UX programming in java, c++, android-java or swift or the like
however, a website can dynamically load (can, 99% do not make use of it) just in time what you need (or as a compromise, preload the next possible steps)... UX code, app code anything
you can make the client download always the very necessary code on its user journey... even UX code, app code...
what I find better in native is the built in bot protection :)
I do not use and know good web apps in the application sense, in plenty of comments I argued it is the tech of the future because web designers are mainly not real programmers and hence bad in app programming.
I mentioned hover (I did not write it) as an example that was in my mind that they asked us years back whether we needed a mobile app or is it enough to have responsive website.
I am the opposite of power user of mobiles, I do everything on linux desktop, I hate 99% of websites. So now I "installed" hover again on my phone because I already de-installed it. It was 5 sec, I got a button, I pressed it, and signed in with my pass manager, having an authenticator app activated it was still a breeze. Most websites would have already lost me...
There I have a feeling of a website but I see everything clearly and I can use it effectively, change things, pay things etc. One thing that was annoying in the 2 minute test of mine is that a seemingly button like thing did not work, you had to click on the text which I smiled at.
For usability it was 8/10 for me which is great because most sites are 0-4...
This site demonstrates not that it is a web app in the greatness sense but that there are so many things you do not need a native mobile app for, thanks to the web which can deliver usable standalone UX even from traditional web designers (hover engineers seem to be clever minimalistic web designers, not really modern web app programmers).
What I can tell you, that good web programming is totally possible, it is a question of modern js, modern web api (so that you do not have to write things in js just call c++ or rust code that is implemented by very capable native app engineers), V8 optimization, most importantly good future web programmers vs. bad current web designers.
Yes, hover makes 70 requests, 5 mb on first load, it is an old school website but still works for me, even on mobile. It is not a bombastic app but capable to become a standalone UX on mobile (aka app) where I can easily use it for the use cases there are in the web domain management domain of services :)
Sorry but I do not really know actually what your point is. In a year or so you can take a look at my site, it will be the best web app you have ever seen. It is totally possible. If you wish I write you a c++ app that you want to die after using it and it will so bloated importing 10 million libraries that I actually never use that the compiler needs over a minute :) Still great performant c++ apps are possible.
Tell me your angle. Are you a native app developer for mobile and you fear learning new things? Even if you invested a lot in coding in a language, I think 95% what your actual market value or knowledge is not the concrete language skill but years of programming experience.
In addition, you can use webassembly for c++ code, on the backend you can use normal strongly typed native languages, the web is beautiful, complex but beautiful. What you see on current websites is a horror. In a way on hover.com too but usability is ok.
Literally nothing about this is old school. Not single thing. It's a simple page with text information on it. It needs exactly three requests: HTML, CSS, and a few kilobytes of Javascript for the minor interactive functionality it has.
Because yes "inherently nothing is bloated". An yet this website requires 2.5 megabytes of Javascript to display a few kilobytes of text, and you offer this as an example of "minimalist website that is not bloated" or something.
> What I can tell you, that good web programming is totally possible
Yes, it's possible. And yet everywhere you turn you see bloated websites.
> Sorry but I do not really know actually what your point is
I think I've stated it loud and clear, and didn't hide behind several pages of demagoguery about the state of the world and possibilities and what not.
> Tell me your angle. Are you a native app developer for mobile and you fear learning new things?
1. What does this have to do with my questions?
2. What exactly in my questions prompted you to stoop down to ad hominem?
> good web programming is totally possible
> modern js, modern web api, V8 optimization
> you can use webassembly for c++ code
> What you see on current websites is a horror
Left without comment
the browser is the jvm of a web app, very secure and js engines like V8 is extremely capable... although js programs can be run at near native speed (the browser is a c++ program normally and there is native compilation of some code fragments)
you should also make yourself familiar with webassembly tech... some folks use even node.js on the server side... the js UI model is also very good
and nobody is replacing native apps, there will be a great competition and in those areas where native has competitive edge, it will win
No, no you don't
> the browser is the jvm of a web app, very secure and js engines like V8 is extremely capable
And what this has to do with apps and the fact that web apps are universally slow, bloated, underperforming, and require significantly more resources to do the most primitive things than native apps?
> you should also make yourself familiar with webassembly tech
Same question as above
> some folks use even node.js on the server side...
Some folks use even java server side... this surely means we have an abundance of amazing great apps written in Java?
> the js UI model is also very good
There's literally no UI model in Javascript.
> there will be a great competition and in those areas where native has competitive edge, it will win
There will be no competition because lazy people and people who have never seen the world outside their web bubble will simply opt for the cheapest option.
Yeah, yeah, he does. Not only C/C++ v. Java, but before that ASM v. C/C++.
> There will be no competition because lazy people and people who have never seen the world outside their web bubble will simply opt for the cheapest option.
This is what most people would consider an opportunity. Get off HN and write competing apps. If these are really "lazy" developers delivering "slow and bloated" apps, you should have no problem kicking their asses in the marketplace.
But you won't.
Argument from analogy is one of the weakest one can make. Because analogies are always incorrect.
Besides, two can play this game. I'm arguing to use cars to get from point A to point B when you're arguing to use horse-driven buggies.
> Get off HN and write competing apps. If these are really "lazy" developers delivering "slow and bloated" apps, you should have no problem kicking their asses in the marketplace.
> But you won't.
Ad hominem an kindergarten-level "I dare you" are even weaker arguments
you trust Mozilla and (the real) Firefox on iOS will not implement anything that is insecure
right now, Mozilla will not be able to implement plenty of web standards even if it was secure according to Mozilla browser engineers
no question with time, Apple will be forced to allow modern web capabilities in Firefox too and also make the iOS welcoming for modern web browsers like Firefox just like literally every other OS is welcoming, including macOS
it will be a debate around whether these OS changes Apple supposedly has to make are a reasonable effort for Apple to make... being that big and and having macOS already capable, iOS will be just as secure for Firefox as every other OS
however, you can trust Mozilla engineers that they will not expose Firefox browsers to security problems on iOS even when it is sub-optimal, so in some weeks just check out what Firefox on iOS already can and use it
in the US there are no alternative browser engines to webkit and the control of web capabilities is exercised through webkit, in the eu it is no longer possible and the control is planned to be exercised via iOS
if the profit threat is not there, why not allow web capabilities in competing browsers? Apple could even claim if iPhone got compromised via Firefox or Chrome that they told you so from the very beginning, on your next iPhone you would just use Safari...