> It’s telling that this is the feature that Apple refused to share. And it makes sense: the idea that users could install safe and secure apps that Apple can’t tax, block or control is terrifying to them.
I think that’s what this decision is all about. When Safari was the only browser engine on iOS, PWAs didn’t threaten the App Store because Safari delivers a degraded experience with them.
With alternative browser engines mandated by law, Apple faced the possibility that Chrome or Firefox might make PWAs easy to discover, easy to install, and feature-complete. They might have begun to see serious adoption and investment. I think Apple did not want to risk letting that happen.
> I think Apple did not want to risk letting that happen.
they've already shown a shadow of their true colors when they banned flash under the guise of security (which is also a problem, but for which apple conveniently uses as an excuse).
This is their true intention. The app store and the easy revenue from those sales are just not something they'll willingly give up.
Apple banned flash when web apps were the _only_ apps on the iphone (besides the preloaded apps). The App Store [1] is ~18 months after the iPhone [2] was released.
This is true, but it's naive to believe that the App Store wasn't planned long before those 18 months and was written in just a couple of month before its release.
I think we can tell that the App Store wasn't planned that early because if it was the earlier Apple apps would have been using the APIs that needed to be implemented and documented for the first App Store, and they didn't.
Apple today is very different from the Apple that launched the iPhone and the original App Store - they started off thinking all apps could be PWAs, but the Web Platform wasn't mature enough at the time and they pivoted to native, that's the actual truth.
Now they're addicted to in-app-purchase money from casino games and don't want that money moving out of their 30% taxable grasp. It's a sad story, truly.
In the Gamecraft podcast, Mitch Lasky shares an anecdote about Apple asking his team to make apps for the iPod in 2005. Apple then calls them back in 2006 to make games for an 'App Store' on the iPod. Mitch claims this was all a trial run for how an app store would work on the iPhone. [1]
This interaction was with Tony Fadell who had been involved with an Apple smartphone since 2004. The iPhone App Store would launch in 2008. 'Thoughts on Flash' would be penned in 2010.
There's maybe not a straight line march from iPhone to App Store, but the right people had had years to think about how an App Store business would work. And even built a first draft implementation for the iPod. When they ultimately decided on that direction, they weren't starting from zero.
You’re kind of rewriting history there. App Stores were plentiful on other smartphones. Apple might have needed internal practice, but they knew how the business would work.
And Tony Fadell famously lost the job of making the iPhone. His idea was to use the OS used in the iPods. Jobs instead chose to minify macOS. Fadell then kind of lost his political grip at Apple and left afterwards.
The social casino space on mobile is interesting, because everyone basically accepts that their apps are a commodity. Therefore the winners are the ones with the best operations.
SciPlay in particular comes to mind because they have built out their own payment processing on platforms that support it. They explicitly want to avoid headwinds from Walled Gardens making decrees. They would already have momentum if/when mobile platforms allow third-party transactions.
That's not to say they would also abandon the distribution benefits the mobile storefronts offer over PWAs. But payment processing wouldn't be the sole thing that keeps them. This is why Apple fights so vigorously to defend their wall. The benefit isn't innate for players or for developers. Once developers reach a certain level of maturity, the wall benefits Apple at everyone else's expense.
With the recent cracks in the wall caused by Epic, I would expect social casino space to be an early adopter in any alternative payment flows that emerge. But honestly I would expect games in general to react quickly, since Apple is walking in Facebook's footsteps and actively detoxing their games revenue habit in favor of advertising revenue. There's more incentive than ever to build a direct relationship with your customers instead of having to proxy them through Apple.
So no major app developer has been motivated enough to create a PWA to avoid the “Google tax” even though the experience is suppose to be so much better on Android?
I don't get the point you're trying to make, nor do I understand your framing.
Historically using the first-party app stores for distribution & payment processing has been more profitable than doing those things on your own. The second it isn't, people won't use app stores anymore. There's nothing intrinsically good or bad about any of these technologies. They're all a means to an end - profit.
We are headed into the next era of mobile apps. Developers who initially found the app store taxes appropriate during the smartphone boom, are now looking to renegotiate the terms as the market stabilizes. There isn't enough growth to go around anymore and make everyone's shareholders happy, so everyone in the supply chain between developer and user will go to war over what's there and what's fair.
This will slowly pick apart all the unjust contracts preventing developers from pursuing alternatives. And as these contracts fall, other distribution technologies will gain momentum. It may be other app stores installing apks and ipas onto phones, it may be PWAs. It doesn't really matter.
You still don’t get it. If you look at the vast majority of money made in the App Store - 90% of it is casino style games with in app purchases. The app stores are used by those developers because they have direct access to the users wallets. No accepting credit cards outside of the App Store is not the answer.
There are plenty of ways to fund App Store purchases that don’t involve credit cards and parents aren’t going to give their kids their credit card numbers.
The other big revenue source from mobile - doesn’t involve money going through the app stores at all. They are services surfaced through apps where users already don’t pay through the App Store - like Netflix, Spotify, Microsoft office and all of the B2B apps.
Neither Apple nor Google care about the little Indy app developer.
You keep talking about “unjust “ fees. I’m talking about developers of casino style games that make almost all of the money in the App Store - this came out in the Epic trial.
It’s not about the little guy - no one cares about the little guy - including Apple.
What exactly don't I get? You're replying to a thread where I highlighted just one social casino company that makes over half a billion annually, doing exactly what you claim they won't do - hedging against walled gardens by investing in infrastructure to support direct relationships with customers. This space full of very big players absolutely will diversify away from app store payment processing if they find a more profitable path elsewhere. They don't care what technology they use.
I haven't talked about unjust fees I've talked about unjust contracts, which prevent forming a direct relationship with customers, aka export your business off the app stores. Once you build the business there they don't want you taking it anywhere else. And they'll wield their influence over smartphone hardware to keep developers complacent. There was just a big antitrust case about this, and the walled garden lost. The losses will continue. The big developers with big resources will use these new pathways to extract more revenue at Apple's expense. Nobody is talking about little guys except you.
They didn’t do anything to get away from the 30% App Store tax. They just chose another App Store - with same App Store tax.
They didn’t make a PWA.
And I don’t want a “direct relationship” with app makers for them to spam me. I use “Hide my email” for a reason.
And the “wall garden” didn’t lose the case.
Apple won on almost every account. The reason Google lost is that they changed the rules of the game after a consumer bought into their “open platform”
Honestly... the Apple/Safari "pay with Apple Pay" flow is super excellent. I'm literally excited when a web storefront supports "pay with Apple wallet" because it's secure, account-free, and defaults all the shipping addresses, etc. it's extremely low-friction, IMHO.
...now, putting on my conspiracy hat... how difficult is it for n00b-company/developer to get a business license to accept credit card payments (and issue refunds/chargebacks) for SlotMaster9000, versus "I'm and app-store developer, Apple fronts the income-washing and chargeback hassles as a first-line defense.
Literally: what's the difference in setting up a Shopify thingy full of digital-content-tokens and running Apple Pay on it?
Remember that WebGL video-poker thing a few months ago? Wire that up to Apple Pay and what's the difference?
Apple Pay is not available in every country, there are more ways to pay through in app purchases than credit cards and parents aren’t going to put credit cards on kid’s phones.
Besides, many people don’t want to pay every random website and they trust Apple.
Bear in mind that Apple and Adobe have a very long and close history - Apple did not kill Flash to spite Adobe, they did it because 1. Flash was plagued with security problems, and 2. Flash was plagued with performance problems and the iPhone was a very low performance device.
Adobe claimed that they could have gotten flash running on the first iPhone in 2007. The first iPhone had 128MB of RAM and a 400Mhz processor.
Safari barely ran on the first iPhone. It had to draw a checker box on the screen when you scrolled fast and then slowly render the image.
When flash finally did come to Android. It required a 1Ghz CPU and 1 GB of RAM in 2011. It still ran slow and ate up users batteries. That’s about the time the first iPhone came out with those specs
Steve Jobs's "Thoughts on Flash," was written when I was a tech at an Apple Store. I remember pulling up crash logs on a customer's computer and showing her over and over that Flash was related to Safari crashing. Flash was garbage on the Mac. Blocking (or not implementing) it on the phone wasn't a grand conspiracy. It was smart business.
I'm not denying that they're predatory with the App Store. I'm saying that not supporting Flash can be explained quite easily without ulterior motives.
People honestly believed that Apple could have flipped a switch and make Flash work on iPhone. It was garbage, which couldn’t run on such a puny processor without butchering your battery. Most people were using it for video anyway, and H.264 playback on the browser was well on its way.
It’s really weird because Flash existed on Android, and it sucked. Even the hardcore anti-Apple fanboys were unwilling to defend it much at the time because everyone knew how much battery and RAM it used, and how poorly Flash content designed for desktop screens and controls worked on phones.
I don’t love how other things were locked down, but losing Flash for the open web was an unabashed win.
It sucked but a lot of things on early android sucked. Browsers were a moving target in general for the first few years. I don't miss it (well, outside of my childhood web games. But much of that has been preserved or ported), but I sure don't hail Apple as a hero for accelerating the downfall.
I think the biggest issue here is that even a decade out there haven't been true flash replacements in some sectors of tech. e.g. we still call it "Flash animation", but I feel the early death of Flash stalled American animation for a good 5 years since there was simply no good artist tool for such stuff in the early 2010's
Another way of looking at that would be that the dead-end of Flash held the market back for 5 years. I miss the ease of the simple stuff but the support I had to give friends who got stuck in one of the pitfalls Adobe didn’t care to fix left me happy to move away. It does make a great what-if scenario, though, imagining how it might have gone if Adobe had felt any obligation to support their platform.
Yeah, the blame for Flash ending up dead rests squarely at the feet of Adobe. It wasn't invented in-house, so you can tell they clearly never cared enough, and were uninterested in solving the security issues permanently.
Flash was a security dumpster fire and wasn't designed for touch interfaces. That said, I don't think Apple - or any other vendor - should be able to prohibit users from running software on devices the user putatively owns.
Offer an (optional) walled-garden experience, ok, but locking down users from installing their own software is predatory.
Apple never banned Adobe from making a Flash player app on iPhone. They decided against shipping it as a plug-in for Safari on iOS.
The fact that Adobe could not have made a Flash player app (imagine an app which you point an URL at to load its Flash content) helps explains the problem.
Except when a manager learns that they can keep Apple’s 30% if they release a PWA instead. They don’t even need to know what a PWA is, they just ask the developer if it’s possible, who says “something something WebGL and web sockets?”
The manager thinks it’s a great idea.
Whether that translates to their users migrating to the new implementation could be up in the air. I suspect Apple will lose some revenue, at any rate, and they’re likely thinking similarly.
So you really think that none of these game developers or their management never heard about PWAs and if they thought they could avoid the 30% fee on Android by creating one without any loss in usage they wouldn’t do it?
if apple did not care, they would not have crippled web capabilities in the last 10+ years and they would just let chromium/gecko based browsers make use of web standards
web apps are the future that may take as much as 90%+ of the 100B app store revenue
web apps will succeed once good programmers and companies make strategic decisions to build good web apps
crippling web apps on one important major platform like iOS stalls these strategic decisions since it is not easy to tell your programmers that now you learn js and web technologies if you still need those native apps
in addition, most companies have already published native apps, web apps will start to gain success after apple is forced to let them work with feature parity on iOS etc. AND 3-5-10 years pass since rather new companies choose web apps
get back to your observation of "popularity" after apple is forced from governments and competition authorities to support web apps on iOS (just like on macOS or every other OS does) plus 5 years!
maybe there are still no great web apps because Apple is still crippling web capabilities on a major platform and the status quo is still hiring mobile app developers because not technical managers copy each other to stay safe and users are used to native apps
nobody said that you have to allow possible great standalone UX on major platforms like iOS because tons of managers made the mistake to invest in web strategy because they trusted Apple to be nice and hence they have these great products already
first step is open all major platforms so that managers and developers see the web as a potential alternative to native app stores, then we will see much more great web apps in 1-2-3-5-10 years... I think microsoft made outlook a web app to have one code base, it is a very big step that capital strong companies make first because it is reimplementing same functionality first...
we want great web apps in the future, the web capabilities are already there, we need investment and good app programmers instead of web designers to see great web apps that build on the great web capabilities
the web capabilities are already there, you should study them... the great web apps not yet because Apple has been crippling them for over 10 years now and they have sole power over one of the major platforms
Because Apple ruins the "cross platform" part by crippling it on their own popular platforms. It's a lot less appealing to develop cross platform code when you still have to make a native app for one of the biggest platforms out there: iOS.
I also wouldn't bet on games being exclusively native now that cloud gaming is available and WebGPU is in heavy development. Right now cloud gaming is locked out of the iOS App Store but Apple has managed to lock it into Safari.
Actually a lot of companies don't need something for desktop use, it's very common to adopt a mobile-first or mobile-only strategy especially if you're a startup. Usually the very largest services will have a good desktop experience. Even then you have services like Instagram and Threads where the desktop web experience is clearly not a priority. Desktop is increasingly irrelevant to consumer markets.
> Is it not worth the trouble of doing a PWA if it were good enough to avoid the “Google tax”?
No it's often not, Android is typically the smaller platform in terms of revenue. There are also easier ways to avoid the Google tax because both Android and Google Play Store is more permissive.
> BTW, Apple now allows cloud gaming in the App Store world wide.
That's a good step forward, although Microsoft's head of gaming claims it's still not open enough to support xCloud, which is probably due to Apple imposing the classic revenue cut on all cloud gaming purchases.
Edit: I forgot to address these two quotes, I'll just quickly note that the two statements literally contradict each other:
> Games - which make up 90% of mobile revenue already use cross platform frameworks.
> Cross platform frameworks have never been good enough and they’ve sucked since Java Swing all the way up to Electron apps.
> Actually a lot of companies don't need something for desktop use, it's very common to adopt a mobile-first or mobile-only strategy especially if you're a startup. Usually the very largest services will have a good desktop experience. Even then you have services like Instagram and Threads where the desktop web experience is clearly not a priority. Desktop is increasingly irrelevant to consumer markets.
And neither of those pay the “Apple tax” nor do most SaaS products. Again 90% of App Store revenue comes from games and in app purchases, why wouldn’t they be motivated to avoid the “Google tax”?
> There are also easier ways to avoid the Google tax because both Android and Google Play Store is more permissive.
Google is no more permissive about games and in app purchases - where most of the revenue comes from…
As far as cloud gaming, Apple is including cloud gaming in the “reader app” clause of the rule where apps like Netflix don’t have to offer in app subscriptions
And my last two statements aren’t contradictory at all. Cross platform games don’t depend on using native UI elements. Java swing and the other cross platform frameworks are not targeted toward games. But you knew this and are being pedantic.
> Google is no more permissive about games and in app purchases - where most of the revenue comes from…
Yeah they are. For one, you can bypass in-app billing altogether with third party app stores and side-loading. They are also permissive on cloud gaming beyond Apple's minimal "reader app" exemption, which is why Microsoft has an xCloud app on Android and hasn't planned one for iOS.
> And neither of those pay the “Apple tax” nor do most SaaS products.
Not sure what "neither of those" refers to, if you're talking about Instagram and Threads avoiding the Apple tax, they do so via ads, but Apple is going after that as well.
Most SaaS products that charge a fee to consumers do get hit by the Apple tax. Most services don't have the mainstream familiarity like Netflix and Amazon do to hide billing from the app.
> Again 90% of App Store revenue comes from games and in app purchases, why wouldn’t they be motivated to avoid the “Google tax”?
I feel like I'm repeating myself: because Android is the smaller platform in terms of revenue and therefore the ROI on moving to web just for Android is not great.
> Cross platform games don’t depend on using native UI elements. Java swing and the other cross platform frameworks are not targeted toward games. But you knew this and are being pedantic.
Cross platform apps don't need to depend on using native UI elements either. I'm not sure why you mention that Java swing doesn't target games, it's obviously not the only cross platform framework, the cross-platform frameworks that games use are obviously enough since so many games use it.
> Yeah they are. For one, you can bypass in-app billing altogether with third party app stores and side-loading
And yet no major developer does it. Why not? You think getting users to use a third party App Store would be easier on conversions than a PWA if they were good enough?
> Not sure what "neither of those" refers to, if you're talking about Instagram and Threads avoiding the Apple tax, they do so via ads, but Apple is going after that as well.
If you buy in the app yes they want their cut. Facebook gets to charge the difference. This does not preclude Facebook from selling the same thing outside of the App Store.
> Most SaaS products that charge a fee to consumers do get hit by the Apple tax. Most services don't have the mainstream familiarity like Netflix and Amazon do to hide billing from the app
SaaS apps are mostly B2B and involve contracts with the business where they just surface functionality through the App Store. I’ve worked for four SaaS providers that have Android and iPhone apps and none of them did there six figure contracts through the App Store.
> I feel like I'm repeating myself: because Android is the smaller platform in terms of revenue and therefore the ROI on moving to web just for Android is not great.
So it’s better to build an app for Android and pay the “Google tax”?
> Cross platform apps don't need to depend on using native UI elements either. I'm not sure why you mention that Java swing doesn't target games, it's obviously not the only cross platform framework, the cross-platform frameworks that games use are obviously enough since so many games use it.
People have different expectations for games. There aren’t any good cross platform frameworks that give you a completely native like experience on your platform / both Google and Facebook explicitly moved away from cross platform frameworks because they weren’t good enough.
Epic Games does it. Amazon does it. Here's some featured apps on the Fire tablet app store: Minecraft, Paramount+, Roblox, Netflix.
> You think getting users to use a third party App Store would be easier on conversions than a PWA if they were good enough?
> So it’s better to build an app for Android and pay the “Google tax”?
Yes, because you've already made the native app while a PWA is a very different platform. It's usually hard to justify a shift to such a different platform unless it saved you a lot of time by, for example, covering all major and popular platforms like iOS.
> SaaS apps are mostly B2B
B2B naturally having an out doesn't mean Apple's stranglehold over the B2C market through web platform limitations is okay. Apple never had a viable way to take a cut of B2B, no one is arguing that they are trying to protect B2B revenue, the point is that they are trying to protect B2C revenue and they shouldn't be able to
> People have different expectations for games. There aren’t any good cross platform frameworks that give you a completely native like experience on your platform / both Google and Facebook explicitly moved away from cross platform frameworks because they weren’t good enough.
Consumers don't strictly expect a completely native like experience on apps either. Both Google and Facebook are profitable enough (in fact some of the most profitable in the world) that they can afford to make the best experience on every platform, including desktop.
The McDonald's app is obviously some web wrapper, it doesn't stop people from buying McDonald's. So is Amazon Shopping and Spotify and your local bank.
> Epic Games does it. Amazon does it. Here's some featured apps on the Fire tablet app store: Minecraft, Paramount+, Roblox, Netflix
And how is that relevant for phones?
> Yes, because you've already made the native app while a PWA is a very different platform. It's usually hard to justify a shift to such a different platform unless it saved you a lot of time by, for example, covering all major and popular platforms like iOS.
A 30% savings in the cost to go after 70% of the market is not enough of a motivation? New games/apps are coming out all of the time. Why not do web first if web technology is good enough and capture both the desktop and Android?
In most of the rest of the world, iOS has much less market share than in the US.
> Apple never had a viable way to take a cut of B2B, no one is arguing that they are trying to protect B2B revenue, the point is that they are trying to protect B2C revenue and they shouldn't be able to
On my phone right now, I pay for Microsoft Office, Netflix, HBO Max, Kindle books, Amazon Prime (including Video) and Disney+ outside of the App Store.
I don’t subscribe to Spotify. But you can’t buy a Spotify subscription on the App Store.
All of Google’s apps that have a for pay component can be subscribed to outside of the App Store and you can’t subscribe to YouTube TV using in app purchases.
> Both Google and Facebook are profitable enough (in fact some of the most profitable in the world) that they can afford to make the best experience on every platform, including desktop.
The first B2B SaaS company I worked for after mobile became a thing had two developers writing the front end apps for both iOS and Android using native tools.
It doesn’t take a trillion dollar market cap company to maintain native apps.
Epic Games makes and publishes games for phones. Fire tablet apps and its app store are just Android apps, it's just that Amazon doesn't sell phones so they don't brand it like that.
> A 30% savings in the cost to go after 70% of the market is not enough of a motivation? New games/apps are coming out all of the time. Why not do web first if web technology is good enough and capture both the desktop and Android?
> In most of the rest of the world, iOS has much less market share than in the US.
That's why I precisely said "in terms of revenue". iOS has the users with the most spending even though they have vastly less marketshare. Apple has been able to evade antitrust action for this reason but mobile developers know that the majority of B2C revenue typically comes from Apple platforms, so they have a stranglehold there.
> On my phone right now, I pay for ... outside of the App Store.
Again with the "reader app" exemption. Yes, the largest content brands & services can sometimes get consumers to use alternative billing methods. Apple's heavy anti-steering rules (which are still heavy and obviously malicious compliance after the recent court case) still make it difficult, assuming it's even possible because most non-megacorp apps are not delivering content they are delivering functionality which has no "reader app" exemption.
Spotify used to use in-app billing but fortunately for them they became one of the biggest streaming services in the world so they have some leverage now.
> The first B2B SaaS company I worked for after mobile became a thing had two developers writing the front end apps for both iOS and Android using native tools.
A B2B SaaS company I worked for also tried to do the same thing and it worked out terribly, they ran away from native apps. Companies often make mistakes. It's not surprising, the ROI on native is almost never there which is why it's extremely rare in B2B. Hey, I can generalize from my one experience too.
That's not even the argument here, just because it doesn't require a trillion dollar market cap doesn't make it a business decision that Apple should be able to force. Profit margins on B2B are generally way higher than B2C, the way B2C companies typically achieve high profitability is via ads on valuable content which is a tough ask for smaller companies.
But let's really be clear here: just because your company could do it doesn't mean others can or should.
> Epic Games makes and publishes games for phones. Fire tablet apps and its app store are just Android apps, it's just that Amazon doesn't sell phones so they don't brand it like that.
And Amazon also takes a 30% cut…
> Profit margins on B2B are generally way higher than B2C, the way B2C companies typically achieve high profitability is via ads on valuable content which is a tough ask for smaller companies.
Where are all of these non game B2C companies that are using in app purchases? Which I keep repeating, can’t make up more than 10% of the total revenue of App Store profit?
In today’s market, if every single app that monetizes directly through in app purchases that was not a casino style game left the App Store, it wouldn’t make a difference.
First of all, it's not 10%, it's closer to 30% [1].
Estimates put 2022 App Store profits at ~$60B [2], 30% of $60B is $18B. Are you arguing that losing a portion of $18B doesn't matter?
$2B of those profits alone is more than any company I've worked for makes in revenue. It's also a lot of money for any company to be losing. If you're the type of business leader who's cavalier about a billion here or there, more power to you I guess.
> And Amazon also takes a 30% cut…
For the first $1MM it takes 20% (Apple offers 15%) but it offers 10% back in AWS credits, it's hoping the AWS credits are attractive.
90% _today_. Strategic chess moves like this are about the next decade. The web is becoming more and more powerful and who says Fortnite can't run in a browser in 5 years? Especially if EU forces Apple to allow alternative browser engines that Apple can't control. It's an existential threat to the App Store model.
Unreal and Unity tried in early 2010's to do web based deployment, and it was awful. They pretty much stopped by the mid 2010's. Basically the big game engines just don't support it. It's technically still in Unity at least (I don't think it's in Unreal, but I can be wrong), but it is far from stable.
WebGPU and WebAssembly is giving them both the optimism to try and boot some of that up again, and Cloud gaming is a big momentum factor that they will want to aim for. so I wouldn't rule out the idea of it coming back by the end of the decade. Will Fortnite specifically bother with it? Who knows? There's so many directions this can go and IOS's current decisions will affect a lot of that.
No, I don't think so, for the end user it doesn't matter a lot (though increased competition will be of benefit for the end user obviously). But what matters is that Apple can't be a gatekeeper for PWAs and so they can't charge their 30% App Store tax. So it matters a lot for developers. That's why it's a threat to the App Store model.
Because PWAs are not capable enough. But as I repeatedly said and will repeat again: it's not about today. What's true today doesn't need to be true in 5 or 10 years.
So any day now it’s going to be the “Year of the PWA”?
And in that case it’s not just mean old Apple keeping PWAs down?
Also, casino style, pay to win games won’t leave the app stores - which make up 90% of App Store revenue - because of the direct access to users wallets. People are not going to randomly put their credit cards on every website and parents aren’t going to give their kids credit cards to put on those websites. The app stores give parents control of how much spending their kids do.
WebKit development is Apple oriented leading to several incompatibilities with other major browsers. Reasoning is usually either WebKit works according to standards, or that bug is accepted but it is basically abandoned. Possibly strategically, to keep Apple controlling some niche use cases. Ingenious but nasty strategy indeed.
This is quite often where people make the greatest mistake. It's all about distribution and customer usage. Most people hate and don't use PWAs.
What stands in the way are Native iPhone apps are better. It also goes for android too. That's why PWAs fail. If they were successful Apple would find a way to monetise the hell out of them.
The only reason why I would install native application is if it's the only way of distribution and I absolutely NEED to use it (banking, government, etc.), for everything else if it's not in a browser - it doesn't exist to me.
Native applications might offer marginal performance boost, but given how optimized modern web is and how powerful are devices that I use - that's not an argument to me unless I do something computing intensive.
I don't know how incredibly self-centered and obtuse you might be to think that your specific crud #383835 is not like all those other™ crud apps and absolutely requires a native application.
In a browser I can:
* Freely select ANY text(unless for some reason some special snowflake website thinks that it needs to disable text selection)
* Bookmark, add tags, sort, organize websites how I want
* Sync all of my information and access it on all platforms, not platforms that vendor decided to lock me in
* Add plugins that allow me to modify and work with content how I see fit
* Prohibit JS, ads or any sorts of tracking
And probably at least another 10 things if I think longer than 2 minutes about it.
All of this is just from perspective of a user. If I were to write from perspective of a developer, that would take a whole blogpost to explain how native applications are relic of the past and should just roll over and die.
I highly disagree. Web apps are notoriously slow. I'm developing a Notion alternative in Qt C++ that load large text files on my 2017 MacBook Air while on my friend's 2021 M1 Pro, the fastest web based block editor (MarkText) takes around 11x longer to load the same file. So, essentialy, my 2017 MacBook Air is FASTER just due to more efficient software.
Why are we allowing this degradation of software? Each time I think about opening Spotify (Electron) on my desktop, I dread the loading time and the RAM it would use.
For very simple apps, frameworks like Tauri should do the job. But for complex applications, let's please not lose our benchmarking standards.
Nitpicking, but Tauri is still in beta for mobile, Capacitor is the incumbent. But these frameworks solely exist because the mobile OS doesn't provide sufficient access to native APIs. If PWAs would be supported properly, and the standard would evolve, then we wouldn't need Tauri or Capacitor. The web-to-native bridge would be part of the web engine that is installed on the OS.
The reason we allow these native bridges (Capacitor on Mobile, Electron on Desktop) is because they allow you to develop the same app once for all platforms. Without them you would need 3x the resources for each desktop app (Windows, Linux, Desktop) and 2x the resources for each mobile app (Android, iOS). Linux would be dead in the water without Electron. It's the reason we have Spotify, Slack, Discord, VS Code, etc. on Linux.
cherry picking examples does not mean the web MUST be slow, maybe the web apps were programmed badly... I can write even worse native apps than these web apps and it will not prove anything
did you ever try compile c++ code to webassembly and check out the performance "degradation"?
it still can be true that for this special task, a native app is the better choice and people would buy it from the App Store even if 30% more expensive
I mean nobody will and wants to take away the choice of using native tech. The degradation is on sooo many levels is not a necessity or consequense.
Web apps are not replacements, they are a choice, an addition. I really do not understan these kinds of comments that frame web apps as a compulsory security nightmare or replacing superior native with inferior web...
Safari stays, native stays, you and every developer can choose.
It may move better developers towards the web stack but then faster and better web apps follow. They will make use of web capabilities and technologies (like better js, multi core, web assemly, optimizations etc).
Chill! No self respecting company will publish inferior web apps if native is so much better in their special use case!
> Chill! No self respecting company will publish inferior web apps if native is so much better in their special use case!
Slack, Spotify, Teams, Notion...
Why do I need to buy the top of the line M3 MacBook Pro to run these apps with a sane performance? What tells you that these same bloated apps won't be even more bloated in the future? There's something fundamentally broken with web apps. It's no wonder the Zed team (that originally created Electron for Atom) has moved completely away from it to develop their own native GUI toolkit.
>There's something fundamentally broken with web apps.
While the web stack may be somewhat slower in the extreme, I think the reason why big bloated apps like Teams are slow is not down to technology at all.
I think the causality works the other way around.
Big corporations with large teams that are systemically incapable of paying attention to detail (including performance) choose web technologies because web tech allows them to churn out features faster and gain access to a large pool of easily replaceable developers.
That's all very well known. The fact remains that it's just too easy to write slow and resource hog apps (even when you really don't intend to) using web technologies. There are just countless examples. I think everyone can tell the difference when they run an Electron app or a native app.
The only exception of late seems to be Notion Calendar (used to be Cron). It's an Electron app but runs pretty smoothly.
But I blame web "designers" not web tech because it has become so powerful on so many levels
my favourite examples are:
- V8 performance (but gecko and webkit engineers are great too)
- webassembly
- modular modern js
- offline websites with service worker caching (I mean I see practically 0 websites making use of it... you download an asset, you cache it, even offline available... how many news sites let you read offline?)
- web crypto
- 100s of others
https://developer.chrome.com/docs/capabilities/fugu-showcase
I think given a certain limited amount of resouces, creating a single web based app will often result in far higher quality than spreading the same resources across four different native apps.
> Why do I need to buy the top of the line M3 MacBook Pro to run these apps with a sane performance?
What kind of future super computer do I need to run NATIVE Xcode with sane performance? Why NATIVE email client drops frames on scrolling thousand long email list while I can scroll Amazon web page forever without perceived frame drops?
Why opening NATIVE settings redesign on Mac OS stutters harder on my MBP 2018 than settings my shitty HTC from 2012?
Why do I need to go through billions of steps to get OSS application working when it’s not notarized by fruity dictator?
I do not use these but I find windows after linux bloated so it may have something to do with microsoft engineers? (teams)
spotify can choose its strategy, you can choose apple music native app (I guess there is something like this? I rarely listen to music but on youtube)
Idont know about teams but my partner has ipad and iphone and I hear often how teams and microsoft products behave bad on iHardware... it may have to do with the love these two big corps show towards each other :) maybe you have to buy a windows laptop for teams too, that is the walled garden philosophy you actually seem to protect :)
my partner now uses my laptop where I have a windows which I did not totally purged because I need this OS for testing :) hell there were chinese text the other day on the front page, you need to scan your finger twice (even if first was a success) sometimes, it cannot find the timezone from time to time :)
I am not linux fanboy, the first ubuntu I purged 20 years ago or so I tried, but in the last 5-10 years linux is just great and getting glimpses how windows works by free family IT care, pff... that is the world we live in :)
I added outlook as a web app for my partner and it has some apparent problems without testing it, but in the last 3 months I see it getting used and no problems I hear :)
I guess the web designers are not web app programmers and it takes time until a new breed of programmers takes over the web...
if I were spotify, I would keep the iOS app and you could choose 30% cheaper web or native... are they killing the native version?
and: maybe these companies are not self-respecting in the way I meant it :)
but every change is difficult... and again, it may turn out that the web just finds its use cases not totally taking over OR: Apple drops the fee to 3% and the change will not be so dramatic
...which is not native to the platform, so you're in a way proving my point.
Unless I become professional writer, or develop an OCD about typing latency - standard browser and Electron apps (looking at you VSCode and Logseq) are good enough for my use cases.
And don't misunderstand me, there's absolutely a place for native applications - when performance matters. Millions of CRUDs on app store are not one them.
It's not because it means a Qt app can match a native application in performance (actually, my note-taking app is way faster than Apple's Notes). In terms of styling, yes, the styling of Qt Quick Controls is not quite good as to resemble native widgets, and I had to do a lot of work to get my own styles right. At least on macOS, I believe my app looks and behave like a native app (with 2 exceptions that I aim to solve soon).
Press “parent” button twice to hear reasons for web applications.
Your “suck” doesn’t mean anything to me. There are benefits and drawbacks to every approach. Benefits and potential of web applications and browser far outweigh current and future drawbacks for me.
in the end, freedom of choice, diversity and innovation would make every service find its optimal incarnation (native or web)
in addition, web security is actually so robust via sandboxing that I feel more secure in a top browser on any web domains than downloading stuff from app stores
native apps have a built in "layer" of bot security, however... a website has to implement security itself because even a smart fridge can make GET requests :)
but I just play the devil's lawyer... I think 999 out of 1000 "standalone UX" better off delivered from the web
I agree that native apps can offer better experiences and often do because they get more development effort. I disagree that most people hate PWAs because they are just websites.
I think many mix bad websites with "PWA is a bad technology". All the cookie banners, ads and prompts to install the native app are the reason the experience is worse.
What could a native app for Wikipedia, Google or a basic news pages (without ads) do better? I use the Twitter PWA for years as it saves battery and offers the same experience. Maybe animations are not as smooth but most people won't even notice that. I also rather use YouTube in Firefox mobile so I can use uBlock even though the app offers more features and generally more ambition. For hardware heavy use cases native apps are obviously better.
Also when companies push people to install the native apps for quick access, push notifications and better data collection you can't take customer usage as a metric for people's taste.
> I think many mix bad websites with "PWA is a bad technology".
Exactly. I put together a demo a few years ago that employed somewhat novel interaction design to showcase some machine learning tech. A number of people were gobsmacked by it and asked endless questions about what framework it was built with. I didn't use a framework. I dug into the deep recesses of CSS to make it do what I wanted. Really, you can accomplish almost anything with HTML/CSS/JS/SVG (though I'll admit it might be painful).
js web api-s have become so powerful (web animation instead of css)
of course you have to know what dom is (and there is cssom as well, modifiable via js)
but it took me some time to realize all you need is js (and understand what js-async really is)... actually I love the js async model for UI
the only problem is that js is a scripting language... some may use typescript for stronger types but what I would love to have and will never come since all web API is for js is a new language...
however, you can use webassembly for critical frontend tasks (like stockfish chess engine on lichess) or actually last time I checked V8 was so optimized that good js code was practically not inferior to webassebly or native...
but web apps can usually offer the same experiences if programmed well
it may be a current situation that some web apps seem inferior, but it is not a necessity
plenty of web developers cannot even use js as a programming language or companies do not heavily invest in web apps since 1. they already invested in a native app 2. apple crippled the web via webkit and now tries to flat out crash web capabilities on iPhones
I mean who will invest in a country with a dictator? Would you build something if the dictator can demolish it any time? Like Apple actually does this with businesses that had a web app strategy?
once companies see all platforms supporting web app technology, wait 5-10 years and then judge
if 90% of the best app programmers migrate to the web stack and flickering html-sites and css stylests are history, I would be surprised if anybody could say whether an app is native or not...
and again, you do not really see native AND web app from the same company on the same platform
but actually commanding pixels on a screen is just as possible with js as with other languages, in the end you instruct c++ or rust coded browsers with js to perform tasks and there is webassembly too
and of course, backend with supercomputers but actually it is possible from native too
I fully agree, and that is precisely why the EU is doing a great job regulating this, and they shouldn't stop and punish Apple more for their response actions.
Apple should allow other browser engines, and these should be able to leverage the OS capabilities comparable OSes are giving to their browsers.
> if 90% of the best app programmers migrate to the web stack and flickering html-sites and css stylests are history,
Why would they be history? What's stopping these developers (or the developers not working on native apps) from creating non-flickering html-sites? Are you seriously suggesting that the only reason these sites flicker is because all capable people are creating native apps?
> but actually commanding pixels on a screen is just as possible with js as with other languages, in the end you instruct c++ or rust coded browsers with js to perform tasks and there is webassembly too
So where is this abundance of great beautiful amazing non-flickering web apps? What's stopping you from creating them now?
If PWAs are so bad, why is Apple utterly terrified at the idea of letting them compete with native apps? I avoid native apps at every turn. If an app is only available natively, I look for a competitor who offers a web version. Finding native apps is a mess compared to finding a website; it's truly impressive how app stores still manage to have worse search results than Google despite Google's quality plummeting. Installing native apps is a hassle. Managing permissions is a hassle. Dealing with their internal ads is a hassle.
Yes. Yes, among other things the point of the app is to look good: be fluid, performant, responsive and conform to the platform look and feel and HIGs.
All the things that web apps objectively fail to do.
And if I can't find the app because of the awful app store interface, and if it's stealing my information by demanding permissions that it doesn't need, and if it's showing me ads that I can't block, and if it's bothering me with constant updates, why should I care if it's "fluid"? The goal of software is not to look pretty, it's to be functional. Web apps are more functional than native apps by my metrics. I do not care if it's less fluid, because I use software to do things.
> The goal of software is not to look pretty, it's to be functional.
Funny how web apps invariably fail in that regard, too.
> Web apps are more functional than native apps by my metrics.
So far you haven't described any metrics
> because I use software to do things.
So do I. And web apps always get in the way of me doing things: they lag, they perform poorly, they break al platform conventions, they hog resources,they can barely display static information without breaking etc.
Most people don't use PWAs... as they exist today.
What would happen if Google added all the APIs to Chrome that are needed for every one of their iOS apps, and then offered them as "PWAs that work best with Google Chrome"? Google would not have to abide by App Store rules, nor the rules for app marketplaces, nor pay the Core Technology Fee of half a euro per install. Apple's entire approach of using their status as a popular phone manufacturer to control the software market would fall.
It may have to do something that if you cannot trust Apple not to break web apps like they are planning to do now, companies will not invest in web apps.
Also, most companies have native apps already... Web apps are the future competitor, not present.
it is not breaking native apps, it is pushing you to update your tech... currently you cannot update some code for your website to work offline on iOS
like there is a competition... few companies have great websites/web apps and if a native app worked, people will not abandon it for a web version of course... the competition you claim web apps lost (even on android) has not yet even started :)
in a very huge article-like top level comment I wrote about how this "install" web apps is misleading and comparing native apps directly to web technology
web technology is not all about apps... I just checked one good example: hover.com has no native app, never had... they made the website work on all screen sizes.
actually I never cared if they have web manifest implemented so that I can switch them to standalone (web app, vow)... now I see I could do this but I will not because this particular domain I choose to use NOT standalone (not as an app) but from the browser... it is a well written website that could be used standalone but since I rarely use it and from linux desktop, I do not care
all it does (what some people love to call "install") is initiating standalone usage and you can get a home screen button
each and every web capability practically has its own standard... caching and offline websites are possible via service workers, orthogonal to standalone and "web app"
what I want to say it is not that simple that web app vs. native... hover does not pay Apple or Google because they were capable of responsive design... if you use a service like it every day or standalone is crucial or your choice of using it, use it that way, it is still run in your chosen browser sandbox whether you hide browser UI or not
it is about choice and it is about the future... what I can tell you knowing web capabilities well, 99% of the time it is possible to deliver the same experiences with a browser as native apps deliver
the web is an alternative, even for standalone experiences (apps)... it may be like linux and stay niche or become like chromium
And you still haven’t answered the question - 90% of App Store revenues comes from games and I’m almost positive the same is true for Android. Wouldn’t they be motivated to use PWAs to avoid Play Store’s 30% cut if PWAs were so great on Android?
It may have to do something with the fact that if you cannot trust Apple not to break web apps like they are planning to do now, companies will not invest in web apps.
Also, most companies have native apps already so no need to reproduce them.
Web apps are a future competitor, not a present one. They are really suited for smaller cross platform projects but if you follow how the web evolves, nowadays they are just a serious thing to consider for any kinds of software projects.
PWA's can do most things: https://whatpwacando.today. Steve Jobs also preferred PWAs and hated the app store. I'm curious as to ask what they can't do that a native app can do without any workaround whatsoever?
I don't know of a single person, ordinary person, who uses PWAs. A Cordova app is a better experience.
I think he's referring to the justifications Steve Jobs gave to kill Flash. Apparently, it was because he really wanted a complete web standard that didn't revolve a particular framework. Apple then introduced the App Store and forgot all about its desire for (complete) web standards
So apple has killed both Flash and (useful) web standards and we are left with unnecessary, gate-keeping, expensive, price gauging App Stores. Hypocrisy at its finest. But at least it's got an Apple on it, so I guess it's fine
It used to be possible to "grow" stuff online. People made a living from developing Flash games (and websites). Aggregators competed and paid well for content. It's now all going to Apple's shareholders and Wall Street, and it's a complete waste of time to develop anything that needs publishing via the App Store. What a sad state of affairs
People often forget this, but before the App Store, the idea was that you would use HTML apps, added to the homescreen. It was in the very first iPhone. It was not called PWA then, and technically a PWA need not be a homescreen app either.
Whether Steve hated the App Store I do not know, but it was not in his original vision for the iPhone.
Or maybe they knew things like the ipaq had third-party software, and they didn't have time to add such capabilities in time for launch, so they only encouraged PWAs as an interim measure.
I find PWAs great for all those little used or temporary apps.
I have a bunch of specialized calculators installed as PWAs - they work great for the purposes.
Similarly, there's no reason a conference should have a native app that will only pollute my system over time - PWAs are ideal for once-only events that aren't going to reuse the app for next edition.
> Can you not install a native app one day, and uninstall it the next day? Or does it not count as "temporary"?
"Don't you guys have phones?"
> Or are PWAs uninstalling automatically somehow?
They don't weigh 100MBs. I feel extremely privileged to have access to super fast networks, but it doesn't mean that lazy developers get right to hog it all.
I agree that the main difference is developer skill, not whether an app is native or website.
One little advantage for web apps: the app (js code) can be downloaded just in time (not that 99,9999% ever make use of this).
If you have a game with 100 levels where a map of one level is 1mb, and 50% of visitors do not like your app and leave at the first level, they may have downloaded some fix code and 1mb, but 99mb stay on server...
Js has modules and dynamic imports for quite some time. Even app logic can be built with dynamic loading in mind.
Again, not that a news site like cnn will not make 300 request and 20mb download on first visit, showing one image and less than 1kb text :) Just checked.
A web app, in theory, is perfect for dynamically loading things but not inherently more lightweight. As always, it depends. On the task, on the programmer.
My point is that if you write a native app and can't make it smaller than 100s of MB, then you're maybe not a really good mobile dev.
Are you implying that web developers are better than mobile developers? Because let me tell you that there are plenty of bad apps on both sides. It's not like PWAs are solving the problem that most software is extremely bad.
On the contrary, cross-platform frameworks often lower the bar.
Of course a web app can be heavyweight or lightweight just as a native app. Still in a sense that smaller companies might publish smaller apps as web apps to have only one codebase justifies a web app niche for lightweight apps.
Lightweight in interaction pattern and size on the device. Yes, they can load quite a lot of stuff in service worker etc, but it's not the same as coming all at once with everything in application archive.
I don't mean just adding an improved notification API, I mean they could literally allow access to the entire SwiftUI and all other iOS APIs from the web. Heck, they could allow PWAs to run in Objective-C instead of JavaScript. At that point it would be indistinguishable from a native app, except that it would not be beholden to Apple's policies like Core Technology Fee, notarisation, payment scare screens, etc ( https://proton.me/blog/apple-dma-compliance-plan-trap )
You can use web notifications, and you can compile Objective C to webassembly. You're also able to use apple pay. Everything you've mentioned has a workaround.
I'm really getting at how PWAs are basically something most people wouldn't use, not because they're missing APIs but because they're just a terrible experience and difficult to install and use.
If its Apple that is holding back PWAs so much, its not that they're any successful on Android either.
And then to extend the argument further, "App Clips" or "Instant Apps" aren't much success either from an adoption perspective, despite having full access to the APIs native apps have.
There is another thing holding PWAs back: they don’t offer as much data mining potential as native apps. A lot of companies sabotage their own web apps just to force you to use the spyware in the App Store, and I’ll admit that isn’t Apple’s fault.
> And then to extend the argument further, "App Clips" or "Instant Apps" aren't much success either from an adoption perspective, despite having full access to the APIs native apps have.
They never had full access to the APIs native apps have, what are you talking about? Last time I tried to develop instant app on Android (and that was like 4(?) years ago), it didn't have access to network interfaces or something like that. It was a great idea on paper, but terrible in execution.
your comment is terrible and a big tell you have no idea of web technology :)
there are plenty of web capabilities that have web standards, PWA is not even a thing officially... no such thing as PWA
actually, no such thing explicitly as web app, either... "installing" web apps is also non-existent officially, it is a very misleading buzzword
if you could call something web app it is a website that was switched to a "standalone UX" from a browser tab UX, according to this non-standard draft (!)
https://www.w3.org/TR/appmanifest/
last time I checked, zero manifest members were mandatory... the ones you would use are "name" and "icon" which is how your homescreen button etc. would show up
nothing will be installed (but if we use this word, how on earth is "installation" difficult, you press a button and it is "installed": really fast I guess since nothing will be downloaded extra or installed... all that happens is you get some OS integratin in app discovery UI or a homescreen button or it actually depends on the OS and you can launch the website directly in standalone mode as an "app"... it is still browser run, browser sandboxed etc. just browser UI you have not
the real "progressivity" is entangled from standalone... the website may be a beast or a shitty scam site that just wanted homescreen presence and send you notifications (same with native, depends on developers not distribution platform used)
so objectively bullshit calling web apps in general terrible, difficult, something people would not use...
practically every website is a potential web app if they add a manifest file with 2 members and people use websites all the time...
the question is how good a website written, is it responsive, can it do offline etc... there are so many web capabilities now...
whether a website or a standalone website is good, easy, something people would use depends 100% on the quality... no website or web app is inherently something you described
accepting the moderation, in my defense: I just saw I added a smiley at the end of the problematic sentence, which I actually probably did to remove sharpness but still being able to formulate myy strong conclusion/opinion
of course it is also possible to just argue against somebody with less emotions and being more polite, without saying such things which I will 100% try in the future! my personal style is also harsh but I never intend to be offensive and surely have zero joy in attacking, insulting or making other people small
harsh honesty is difficult to separate from attacks so it is legit to ban this style altogether
I almost universally prefer native apps, and I'm also an iPhone user, but it's hard to claim PWAs are unpopular on their own merits when Apple has seemingly deliberately stifled them.
On Android you can go to a mobile webpage and see a fairly unintrusive, one-time banner which will let you install it to the homescreen. Sure it's only two taps on iOS (Share -> Add to homescreen), but for a start your users need to know that functionality even exists, which alone is a massive roadblock to adoption.
As a user, if I want to get notifications and an "app-ish" experience, and the developer is unable or unwilling to create decent platform-specific apps, I would happily take a PWA over a "native" app that is actually just an embedded web view or something trying to recreate the world like Flutter. If I'm not gonna get the benefits of my chosen platform, I'd at least like to not also have to deal with the downsides of App Store apps, like large install sizes and stuff getting held up or nerfed by app review.
I recognise that giving PWAs unimpeded access to the core capabilities that native apps have might result in a worse offering of native apps—as more developers choose to just not bother—but then I'd say it's on Apple (and Google!) to step up and make native a more compelling option. Any veteran iOS developer will agree there's an enormous list of stuff dying for improvement in the development and submission process.
Our apps are available as webapps. 100% identical user experience. All functionality. Including notifications, offline, storage, performance and more. We have over 50m installs. Where do you get your info from? Really curious.
it must be for all websites since a web app is just a website that may or may not implement web capabilities
actually no such thing as PWA, there are plenty of web standards but no web standard about PWA
the web standard that governs standalone mode and home screen button and such is a draft (web app manifest)
the website does not need to be progressive, not even offline capable to get standalone and home screen button
the "very dangerouos" service workers can run in any website silently without standalone mode or app buttons or any user interaction (maybe because they are not that creepy after all, an open source javascript that tells browsers how to cache)
I really hate this web app distinction and install language because
1. it is not standard
2. it is not true
3. it is contra-productive
I wrote a piece about this somewhere in a top level comment. Apple breaks web capabilities both in websites and standalone websites (web apps).
The biggest one is that Apple allows local storage to last longer than 7 days for webpages installed as apps on the home screen, but deletes local storage for ordinary websites 7 days after they are last opened.
I made the mistake of only carrying an iPad during my most recent holidays. What a useless piece of junk this is.
iPads work well enough at home to watch movies or play a couple of games, but trying to do any kind of serious work on them, either editing photos, writing something, sending files, even trying to use a sequencer is an exercise in frustration.
We are sooo lucky there (still) exist alternative computing solutions other than these things made by a company obsessed with control and extracting the maximum possible value out of every movement of their users.
Apple is the evilest of evils. It must be fought with great determination if we are concerned with freedom.
> Apple is the evilest of evils. It must be fought with great determination if we are concerned with freedom.
Continuing using Apple products while periodically expressing your frustration on Reddit/HN is not a good way to "fight" Apple. Consider using PC with Linux or something.
I would assume that popularity of second had Apple products increases their resale value and indirectly benefits Apple since people consider their products to be a better investment and buy more of them.
You can code on it, design, edit photos, write books, sketch, edit videos... and a lot more with ease. For 3 years, I used only an iPad for work. Can you expand on your problems? Or was that a "it works differently on my beloved OS" kind of thing?
You can’t compile on it. You can’t run software in the background (for example a terminal, where you don’t have to bring the app to the foreground every few minutes). You can’t install software on it that Apple doesn’t want you to (regardless of whether or not they’re malicious). And the software you can run is more likely than not a subscription, because the only place you can buy it is the App Store, which pushes the subscription model unto users and devs.
You can't install a random program. You need to go through the appstore for everything. There is no shared filesystem. Trying to export an image from a photo editing app takes a couple of seconds just to build the list of possible target apps. Everything is not only gratuitously complex, but reminds you you're not in control. You're a guest in Apple's world, instead of Apple being there to serve you.
iPads aren't setup for "serious work" out of the box. There's a whole community who have developed workarounds and apps for serious work on it, but it prioritizes being "grandma proof" over a serious work machine from the get go.
My Grandma has an iPad. Every time I visit we end up sitting down for hours reviewing how to do things in various apps and switch between them. The system constantly hide navigation control, moves things around in response to scrolling, and requires precise swipes or taps on flat or near-invisible controls to reveal information or get around. Watching her try to use iPadOS is always useful in keeping myself grounded in terms of UI design. Suffice to say that the thing is not at all Grandma-proof.
And sure, at least there aren't tens of sketchy toolbars doing god-knows-what each time she opens Safari, but there are tens of sketchy-looking games and apps installed on the 4th home screen that she doesn't want or use, and opening any immediately throws up full-screen autoplaying ads with audio before letting her into some cheap sudoku implementation. I don't want to hear this "walled garden keeps you safe" nonsense; there are plenty of scams on the App Store.
> but it prioritizes being "grandma proof" over a serious work machine from the get go
Which is kind of absurd considering they sell a device called "iPad Pro" which costs as much as their entry-level laptops, which are—by and large—enormously more capable, despite sharing the same internals.
I appreciate the iPad as a computer for people who aren't interested in computers (my mum has been happily iPad-only for years now), and I recognise that I have a degree of saltiness because I'm a software developer and the "Pro" in "iPad Pro" seems far more geared to artists and other creative professions, but it's a terrible shame there's no way to take the training wheels off what is otherwise a fantastic ultraportable computer.
My MacBook Pro is a great computer that I like a lot, but the only reason I even need it is because my iPad is incapable of doing anything I need for development, and the ~15% of dev I do away from my desk is still important to me. If I could do some casual noodling or prototyping work on my iPad with a keyboard, I could have just bought a desktop Mac instead.
It weird so many young people do most of their work on iPhone, including producing videos, photos, and text. Yet when it comes to iPads most people don't want to touch it for work.
For a lot of use cases, iPads are worse at those things. For video and photos, the iPhone camera is night and day better. It's also easier to hold for taking those photos, while also being portable (so you don't have to carry an iPad around).
For a generation that has been texting on touchscreen for years, the muscle memory for typing on a phone is pretty well defined. In my experience, typing on a tablet requires different muscle memory and is slower.
If you add a keyboard and stylus, the iPad could be more useful than a phone. But at that point, you're spending a lot of money to improve a device that still has all of the limitations of iOS.
I remember everyone always was fascinated by all the kids in Japan that had a fancy flip phone but not a computer. Seems like Japan was simply 20 years ahead of everyone, as usual.
The creation of the Vision Pro, and now this direct assault on the open web, makes me believe that Apple is no longer has the vision to lead the industry effectively. It's a shame because it has enormous momentum behind it, which means every bad decision, like this one, will be felt be millions of people for years.
Apple is a 3 trillion business that is out of growth drivers. They will need to squeeze more money out of everybody in the ecosystem to appease wall street. Or launch a new 500bn product line but I don’t think they have anything big in the pipeline.
I agree. Money is not in the cars. Money is in the data collected from the users - 360 degree camera footage, offloading AI training risk to users, and of course collecting all of that sweet user data [1]. In some cases, the car manufacturer will somehow collect your sexual history.
The AVP is one of the most out of touch products I've ever seen from a respected brand, and I can almost hear Steve Job's scathing criticisms of it, based on everything I know about him. Not to mention, it goes against the increasing trend of less screens and less tech. The fact that it got made and is being pushed so hard as the next step in computing, is bonkers.
So to me, it contributes because it is another data point that the leadership has compromised its ability to consistently make forward thinking decisions.
Have you looked at the patent? How is that supposed to be the Vision Pro?
It's just a pair of sky googles with 2 displays in front of the eyes, connected to an Airpod for watching media. It's not so much Vision Pro as it is Nintendo Virtual Boy. Actually the virtual boy was more advanced since it let you play games.
That kind of stereo display headset for watching videos inputs from external sources has existed since the 70's, long before Apple's patent 2007. How did they even get a patent for it? Another proof the patent system is broken since it seems they'll let you patent anything.
Apple not allowing the open web stifles innovation, including the AVP. The apps in the app store will be dictated by Apple. So whatever their ethical framework is, that is what will receive innovation.
While that seems fair, the problem is that the strongest form of software innovation I have seen is where developers can freely plug in.
AVP has support for WebXR behind a flag in Safari that allows the full immersive mode of spatial computing (don't say Vee Are) and that -- so far untill now - is an opening for non-app store third party experiences.
Every mbp looking the same with their attrocious glowing branding on the lid.
One-button mouse.
No audio jack.
The walled garden.
Charging a fee for the dev tools.
Yeah, these are all subjective - it's all crap I hate.
But my point is: is anything that anyone dislikes actually out of character for Apple? Or is it business as usual? Maybe Samsung will also create a useless headset and directly assault the open web too, making Apple still the 'industry leader'.
OK, I'll bite. While I agree with many of your criticisms, some are IMHO incorrect.
- Apple did Firewire at a time when it was the leading interface for professional video stuff. As Apple marketed their computers to video professionals back then, it made a lot of sense. Also, USB 2.0 wasn't on the market yet or hardly had any adoption, and FW was pretty much the only modern high-speed serial interface. At the time, FW was also a much more capable (if more complex) interface than USB. After USB 2.0 got more adoption, FW 800 was released with almost twice the bandwidth of USB 2.0.
- Forcing USB C adoption upon the industry was a good thing, just like getting rid of floppy disks, serial and parallel ports, and Flash (the latter one being debatable as the beginner-friendly authoring system still leaves a big gap that hasn't been filled since). The transition period was admittedly very painful with all the adapters. But now pretty much all devices charge via USB C, just how neat is that? I know that Apple didn't give up Lightning for USB C in iPhones voluntarily, so they needed a bit of help by the EU in their own mission here :)
- They reversed on the touch bar, thus admitting their mistake. It was indeed horrible, though.
- The glowing Apple on the lid hasn't been there any more for a decade or so
- Dev tools aka Xcode are free, the fee you're probably referring to is for getting stuff into the App Store
In the end, you're correct - haters gonna hate, Apple will be Apple, people will buy their stuff anyway.
Because in the US they will not be forced to (and likely won't) allow Firefox, Chrome, Brave, etc, with their own rendering engines, on the App Store, and if they do, they will definitely not allow them to become the PWA storefronts they are on Android.
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.
One example: a while ago I worked on a bluetooth le based companion app for industrial sensors. The client would absolutely have built this as a web app if iOS had offered web bluetooth. With alternative engines this would be possible and Apple does not want these kind of applications outside the App Store.
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
> One example: a while ago I worked on a bluetooth le based companion app for industrial sensors. The client would absolutely have built this as a web app if iOS had offered web bluetooth. With alternative engines
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?
Well on desktop Chrome/Edge has a high enough market share that the client would not have cared.
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?
> Well on desktop Chrome/Edge has a high enough market share that the client would not have cared.
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".
You need a competitive browser if you want to convince people to use it. Apple's only distribution scheme for Safari is forcibly pre-installing it on all of their devices. It's not akin to Chrome or Firefox where people deliberately install their app and weigh it against alternatives. You don't get a choice.
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.
> You need a competitive browser if you want to convince people to use it.
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".
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.
> It's "you need to ship whatever features Chrome ships at neck-breaking speed, all consequences be damned".
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).
> Given that Chrome isn't shipping ActiveX or Flash, what's the issue?
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]
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.
> 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.
This thread isn't about the one-sidedness of Apple's criticism. It's about criticizing Apple, and you're deciding to derail it with an unrelated strawman arguement.
If you want to circle back around to the point, I'm glad to keep discussing it.
This is the comment I was replying to in this thread: https://news.ycombinator.com/item?id=39408640 Where the person quite literally said "I don't care if it only works in Chrome, since its market share is high enough".
And then the second sentence following that is: "I don’t think Apple can tell alternative browser engines what features it will allow and which not."
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?
I replied to a post asking „And if PWA were such a threat to Apple's business then why are they allowed in US.“
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.
is it not chromium, because Chromium browser, Edge, Brave, Opera, Vivaldi, Yandex, Samsung etc... (and Google Chrome) all use the open source chromium engine
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
> because Chromium browser, Edge, Brave, Opera, Vivaldi, Yandex, Samsung etc... (and Google Chrome) all use the open source chromium engine
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.
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
It's unfortunate that the whole discourse is about one of the worst imaginable outcomes: replacing apps with shitty slow bloated underperforming web apps.
That is, the discourse is valid, and Apple is to blame. But why did it have to be around PWAs of all things?
Web apps aren’t inherently slow, bloated or underperforming. You can absolutely build a snappy, polished web app with a UI layer that rivals a native app.
(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'm genuinely curious: do you have any examples you'd like to share? Not that React Native is the same as a PWA, but even in that space I have yet to find an RN app (at least those I know about from their Showcase page [1]) that rivals a native app on iOS, but perhaps it's wrong to assume a React Native app would be comparable to or strictly better than a PWA.
I don’t have an example I can show, unfortunately.
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
Which modern web capabilities for a strategic investment that Apple tries to eliminate require you to load 2.5 megabytes of Javascript to show a few lines of text? https://news.ycombinator.com/item?id=39413396
Funny how the vast majority of web apps are not snappy, or polished, or rival native apps.
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.
Electron-based apps are not PWAs. PWAs do not need to be wrapped in a browser engine of their own, they use the installed browser engine. They are not inherently bloated or resource-intensive in any way.
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.
Just as I said: you add a P in front of web apps, suddenly as if by magic all the issues disappear.
> 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 :))
I personally prefer native apps, but there are some nice things I can (could) do with web apps that I can't with native ones, like adding multiple copies of a PWA to use with different accounts or creating personal web apps without needing to go through the app store approval process (all it took was a web page with some meta tags).
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.
Web apps and Electron apps are two different things. Entirely.
> 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.
> 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.
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, 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.
So, a day and a half later still no answer why "nothing is inherently bloated" is illustrated with an example of a few lines of text rendered with 2.5 megabytes of Javascript
I rarely use mobile and social networking and I actually rarely come back to my comments, so much time
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
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.
> Yes, hover makes 70 requests, 5 mb on first load, it is an old school website
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?
do I just hear the arguments again how java is slow vs c++?
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
> do I just hear the arguments again how java is slow vs c++?
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.
> Yeah, yeah, he does. Not only C/C++ v. Java, but before that ASM v. C/C++.
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
Yes - the submitted title ("iPissed: Apple is after web capabilities to protect close to 100B App Store Tax") broke the site guidelines badly and a moderator reverted 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...
Tip: To be taken more seriously, don't use such childish language. I was reading the first part and nearly switched off without checking the comments here. I'm glad I did, because I see now how serious (and maybe _illegal?_) this is.
Don't turn your audience away with emotional wording, for something that can easily have impact if you communicate it purely for what it is.
It's not childish it's manipulative and it's the sort of rhetoric that only manipulates people at least a standard deviation to the left of the bell curve here. But even by that standard, gosh this piece lays it down so thick that it honestly made me cringe.
What I find especially conspicuous is that they quote Apple's reasoning for doing that and then do nothing to counter it. If they find Apple's decision so wrong, they should say why.
This subject was already discussed here 2 days ago (819 points, 778 comments) [1] and the top comment highlighted that Apple gives its reasoning in a way that is at least worth considering. From Apple [2]:
----
The iOS system has traditionally provided support for Home Screen web apps by building directly on WebKit and its security architecture. That integration means Home Screen web apps are managed to align with the security and privacy model for native apps on iOS, including isolation of storage and enforcement of system prompts to access privacy impacting capabilities on a per-site basis.
Without this type of isolation and enforcement, malicious web apps could read data from other web apps and recapture their permissions to gain access to a user’s camera, microphone or location without a user’s consent. Browsers also could install web apps on the system without a user’s awareness and consent. Addressing the complex security and privacy concerns associated with web apps using alternative browser engines would require building an entirely new integration architecture that does not currently exist in iOS and was not practical to undertake given the other demands of the DMA and the very low user adoption of Home Screen web apps. And so, to comply with the DMA’s requirements, we had to remove the Home Screen web apps feature in the EU.
EU users will be able to continue accessing websites directly from their Home Screen through a bookmark with minimal impact to their functionality. We expect this change to affect a small number of users. Still, we regret any impact this change — that was made as part of the work to comply with the DMA — may have on developers of Home Screen web apps and our users.
----
There were 451 comments responding just to that [3].
> Without this type of isolation and enforcement, malicious web apps could read data from other web apps and recapture their permissions to gain access to a user’s camera, microphone or location without a user’s consent. Browsers also could install web apps on the system without a user’s awareness and consent.
I’m not sure I fully understand the ire at Apple here. If any of this is true, killing PWAs sounds like the right move.
Everyone who is pissed off at Apple is just fine with this? The fact that this can all happen without user consent completely throws away any arguments of “I’m a responsible user who should be able to choose what apps run in my phone, not some big company”. Because if you really believe that, then you would also not want apps like this to exist under the new EU rules.
> I’m not sure I fully understand the ire at Apple here. If any of this is true, killing PWAs sounds like the right move.
Well, that’s just it: it’s a lie.
Full-screen web apps are using the same web APIs that websites in browser tabs use. The exact same hypothetical security risks exist for ordinary browser tabs. Full-screen web apps pose zero additional security risks.
All Apple has done is to harm the usability of web apps. Not one user will be made safer by this move.
in a hypothetical spy browser maybe :) not in any of the modern browser engines like Gecko/Firefox
just be responsible and use Safari if you want the status quo or use a trusted browser engine like from a big company like Firefox/Edge/Chrome
do not be fooled, you people use web capabilities including service workers on websites in all OS, you even did it with Safari on iOS
if iOS had some vulnerability vs. android, windows, linux, mac that made this possible in other browser engines than webkit then Apple has to make the changes
you really think it is an effort if every other OS does this, including macOS?
and if with more information you see Apple tried something fishy here, do not forget like most LLMs most of the prompts in the past... never trust Apple again in this regard!
but you can use other browser engines in macOS (where no app store revenue originates) and Apple never had a problem implementing it and never fear mongered... this should be some kind of implicit proof
but of course Apple will have to prove this and they will fail to do so... they are just pushing the boundaries
> in a hypothetical spy browser maybe :) not in any of the modern browser engines like Gecko/Firefox
But that's the whole point of security -- you're protecting precisely against the disguised malware, not the well-behaved software.
To say that this isn't necessary because there exist browsers that are well-behaved misses the point of security entirely.
And remember that iOS was built with a new model of security in mind from the start. They don't want their security guarantees becoming undone because suddenly third-party browsers can start installing things on the home screen that look like familiar apps and inherit all sorts of permissions.
That explanation doesn't make sense. Apple is not permitting arbitary browsers on the platform.
> To help keep users safe online, Apple will only authorize developers to implement alternative browser engines after meeting specific criteria and committing to a number of ongoing privacy and security requirements
Given Apple is going to continue gatekeeping browsers, the malware excuse just doesn't work. Malware browsers wouldn't get on the stores in the first place, unless Apple fucks up. And even if that happened, it would be quickly revoked.
This is one of those places where Apple's restrictons conflict with their scaremongering. If they'd only done one or the other, one could buy it. But when the combination of the two is nonsense, it becomes clear that the scaremongering has no basis in reality, and is just a justification made up after the fact and the real motivation is something else.
people who are these children you are describing SHOULD all stay by Safari and never download a browser app...
other adults may still want to stay by Safari
some people will just use Gecko or Chromium based browsers, as far as I know Chromium and Brave are totally open source :)
I would not recommend chinese or russian developed browsers but heck is America not a free country?
iSpyBestBrowser shall apple users download, I do not think anybody would blame Apple if their iPhones get compromised
hold back your long protective arms and concentrate on:
1. Safari security, providing a secure Apple-Level security choice
2. You may want to prompt users and tell them who owns the company and who develops the browser they are trying to download and what could happen if...
I mean do you really think somebody has to fear Microsoft Edge or Google Chrome?
> [it] would require building an entirely new integration architecture that does not currently exist in iOS and was not practical to undertake given the other demands of the DMA and the very low user adoption of Home Screen web apps
So it can be done, DMA doesn’t require this, even according to Apple.
Apple cannot simply invoke DMA (50) as a free pass. For its arguments to align with the intent of the legislation, here's a roadmap of what they need to do to justify their security-based restrictions on iOS:
Apple must be transparent about the exact security issues posed by alternative browser engines with concrete instances (not merely speculative risks). They need to prove that these are unique to iOS, given the successful use of unrestricted browser engines on macOS (and every other OS).
Before opting for the extreme step of removing functionality, Apple needs to offer documentation of all the methods for managing and mitigating specific threats that were considered and subsequently ruled out as infeasible (sandboxing, enhanced APIs, etc.). This emphasizes that their actions are indeed the last resort and not merely a way to suppress competition.
The company needs to demonstrate how they would proactively work with browser engine developers to establish strong security controls and threat monitoring on par with or exceeding their current practices for native-only experiences. This shifts the focus to building a safe environment rather than merely limiting the scope of capabilities.
Apple must guarantee that if and when these security challenges are met, it will progressively expand support for unrestricted use of web standards for third-party browser engines. This creates the long-term perspective the DMA is designed to protect and gives confidence to developers investing in advanced web app solutions.
Without taking action in these key areas, Apple's reliance on this DMA portion won't hold up to regulatory scrutiny. They cannot cite generic security dangers then fall back on "practicality" arguments without robust, evidence-backed reasoning.
I was an original Mac OS Developer, and way back then I saw that Apple wanted to create monopoly and deeply hates any developer not on their payroll whose output they own. As a result, I have never published Apple software. It is not worth it, never has been worth it.
For me, this shows fear and a sense of insecurity within Apple. They've built their walled garden and are doing whatever they can to protect it. They've probably even convinced users that it's in their interest. Yet, they know there is an inevitability that polished web apps will exist (and that time will come fairly soon, imo), and will match and replace their native counterparts. They also know, it's the correct and overwhelmingly more efficient way to deliver 99% of apps. Yet they want to stifle that future, all in the name of money.
Create all the titanium cased phones you like - eventually, the masses will be smart enough to prioritise openness and forward-thinking over almost anything else. If you start to hold people back with your decisions, questions will start to arise about your priorities and eventually your products. And people are fickle enough, that they won't be your fanboys/girls forever.
I checked DMA and Apple will be forced to comply (this thing they do is far from it), however, they can prolonge it with this tactic and break all existing web apps for a year on iOS to punch them in the face...
however, web apps are the future and not the present... we will have them on iOS in 1-2 years in Europe, I dont know when everywhere in the world
Kinda funny but when the rubber hit the road they did delete the word “Progressive” from “Profressive Web Apps”. Talk about a complete failure in branding, they should have done that years ago but the PWA pushers had the congenital fault almost all marketers have which is the inability to see themselves the way others see them.
“Progressive” just sounds too good. Who wouldn't want to be associated with progress? Today we have the label “AI” for stuff that has nothing to do with intelligence whatsoever, but who wouldn't want to be associated with intelligence?
I dont like the progressive word because you do not need it and I am minimalistic
however, at the beginning they tried to force some "progressive" things like responsive design or offline etc. I can understan what they wanted, no need to think of it as self marketing
I like the clarity of websites and we should learn that they can be very powerful: responsive websites, offline functioning websites etc... they can use sooo many web capabilities
I define apps as standalone UX and I use "switch to standalone" instead of "install" (that is what actually happens if someone creates a manifest file which is governed by a draft, not yet standard)
so a website can be implicitly a web app in the sense of rich functionality (responsive, offline) without being used in standalone mode
it will be explicitly a web app if switched to standalone mode from tab mode... this is an important distinction since even if nothing is installed this is a decision from the user to use it from the OS and outside of the browser as a standalone window and on some platforms it may give it some extra rights (local data storage will never be cleared by nice companies like Apple without asking the user, push notifications might be coupled with this decision now or in the future etc)
but I agree, this progressive thing is the past... it actually became the past when browsers gave a shit about what the site ctually functionally can when granting that app button and standalone mode
I was using X's PWA for years, but I recently gave up on it because it's just very janky and the opposite of smooth, it also drained the battery much faster than the native app.
This may be an issue with android, but even with 12GB of ram the PWA still crashes often, something I never get when using the app.
Luckily I didn't have to compromise on my AdBlock thanks to vanced patches, which patch the x app to remove ads.
The solution is to improve web app capabilities and security, not to devolve back to platform-specific fiefdoms just because there’s kinks to work out.
Disentangling apps from OS-specific environments is how we introduce competition back into computing.
Apple and Microsoft are the most valuable companies in the history of earth due to these fiefdoms and it’s about time we got some reversion to the mean.
“Web” as an OS is overbloated, with decades of legacy junk. It was never meant to run applications, and yet it does.
The strong indicator for this is that there are only, what, 3 (two sharing common ancestor, so more like 2.5?) non-dead rendering engines, and it’s practically impossible to implement a new one? (Yes, a toy engine is possible, but anything practical is out of reach.)
My point is, you can’t introduce competition over this platform - it’s the same sort of a walled garden, just with different owners.
it was meant to run applications, that is why V8 is developed and optimized like hell, that is why we have webassembly to port c++ programs (try stockfish on lichess, it is webassembly)
originally, the browser was not meant to run applications, modern browsers are... strong indicator for this is chromium V8 performance and webassembly and the evolving js language with modules and node.js on server side
jvm introduced a competition to c++ and java is still top language, a browser is a kind of a jvm... you can use kotlin and other languages to compile to jvm and you can use js and webassembly to write apps on browsers
my point is, this is the best platform to introduce competition to native apps on walled gardens
the walled garden is not the os or browser but the company behind a closed os platform or closed single browser
on iOS, you had both: closed OS and closed single webkit browser engine
on every other os platforms you have true browser choice... since chromium is open source, you can create not just your toy browser but one of the most powerful ones... you can download the source code and if it goes in a restrictive direction, everybody can fork the web standard friendly versions
it is open and powerful, that is why most companies give a shit about browsers but it is not difficult for the EU for example to hire great browser engineers and create a beautiful stron free browser from an appropriate chromium version if things turned bad
whereas there are only 2 mobile operating systems that really work, from 2 giant US companies
where it is much more difficult to introduce competition is creating alternative mobile OSs... and then what, developers should create apps for this additional one two with another codebase?
browsers are the perfect level to introduce competition, in a way blink, webkit and gecko are all open source and chromium has a stron focus on improving web capabilities, pushed by 2 giants too (Google, Microsoft)
I'm sorry, but your comment has a lot of simple facts stated plain wrong, and then it entirely misses the point (which could be my fault for not making it clear what it was about).
macOS and iOS are based on Darwin, which is a BSD-derivative, IIRC there's nothing from Linux in there at all (although IIRC macOS used to ship some GNU programs). Chromium is not the engine, Blink and WebKit are. Android has almost no relation to GNU - sure, it has Linux kernel, but, it's entirely different system on top of it... but all of this is not important.
It doesn't matter if the browser choice is good enough or not. That's not the point at all - today's browsers are going to become irrelevant, just like '90s and 00's browsers don't matter anymore (Trident? Presto? CERN and NSCA stuff?). The fact there are only few engines remaining is the indicator, not the problem.
The core issue that the entry barrier is extremely high, and the foundations are still almost as bad as they were when Web2.0 was conceived. There's a giant baggage of legacy stuff that has pretty large impedance mismatch. The colossuses are growing so fast no one can realistically build a competing one anymore, yet all of them have feet of clay, as they were never meant/designed to grow into what they became through their twisted evolution.
By the way, I can totally understand if someone would disagree with this. Evolution takes weird paths, but somehow ends up achieving impressive results, and if we would stop caring about how things are working underneath (think of a recurrent laryngeal nerve analogy) and only focus on what they can do, maybe it's fine.
thanks for the details, you are probably right, then change linux to unix and chromium to blink in my comment, however, browser engines are all open source and they are the exact pitch perfect level to introduce competition
I am not so sure that chromium "kernel" or linux "kernel" ever become irrelevant... gecko or webkit maybe
even if only chromium engine stays, it is open source, if something goes wrong, you can fork or get back to gecko, webkit... we are all carbon based lifeforms, still there is great diversity I guess
why would we need to make so much effort to compete on browser engine level if it is so great that you cannot differentiate native to browser run programs?
I really do not understand what the point of your comments actually are... it is simply not true the browsers are not good for competition and I do not see what alternatives you suggest instead?
Got any examples to prove that? The only reason why features might be "worse" is by vendors artificially limiting browser access to native APIs. And "blazing fast performance" over features is not argument.
> security, and privacy
I can block every invasion of my privacy in a browser. Can you say the same for native applications?
Definitely, but only the simple web apps (like an icon that links to an url in the browser) that aren't affected by Apple's changes, so no notifications and stuff because it wasn't a PWA. It was a nice experience. I had a fast hosting provider and it worked seamless.
Right now I use Android on a cheap Samsung and loading webpages takes ages with Firefox. I don't think Google goes freely in killing the web, but we already knew that.
and I guess we all use a lot of responsive websites that are minimally web apps in funtionality, even if they did not offer manifest files for standalone mode
I just found out that hover which is a responsive website without mobile apps can be added to home screen ("install") on mobile...
well I tried it and it is on my home screen as a web app! vow!
I mean a web app is not a website you download or install, no need to ask how many are on the home screen...
the real question is web capabilities, we need good web programmers, companies with web strategies to get a lot of powerful websites
it is actually not the most important thing whether you add it to the homescreen or what...
the most important thing is to support the web capabilities with security in mind
it is not a fight against native, it is a choice and competition, freedom, free choices are normally good
If the site has some special meta information, it can display like any other app (full screen, its own entry in your multitasking UI). Otherwise it just opens in your regular browser.
Perhaps they didn't want to give Apple the leverage over their companies right to run software freely without red tape in between them and their customers.
Having to worry about rejections, API deprecations, architecture changes, Appearance guidelines et al would defiantly make me want to avoid it as much as possible.
It's akin to avoiding a marriage to an aloof partner that will never love you.
I think it's a bit of a stretch to call a web app "develop[ed] for iOS"
The whole point of the web is that it is cross platform. That isn't a negative thing it's a positive, but calling it "develop for iOS" is arguably disingenuous.
Most people just want to make apps for themselves. If you use an iOS device but not a Mac, there was no way to do that before web apps (which still offered a terrible dev experience, without debugging) and now there's again no way to do it.
had the ability... he did not mention specifically
and yes, with web apps you can develop for iOS too, one code base for all
and whether it is criminal, sadly, must be determined on court... the DMA explicitly supports web apps without rstrictions, so in the enfd it can turn out to be literally criminal what Apple does
I usually find myself rolling my eyes when HN collectively complains about Apple, because the perspective is so dev-centric, completely ignoring the concerns of the actual users.
But this is a kick to @#&!s of users (and devs).
Even you stipulate that the DMA is a horrible, terrible regulation that should never have been enacted, Apple still absolutely has to find a better way to comply than this. This isn't going to just piss off some whiney developers, but also hit their customers.
I think this is a major screw-up by Apple that will have long term consequences for them.
(BTW, we don't have to wonder if freely allowing "side-loading" will cause a security catastrophe, as Apple claims. We already know it won't. "side-loading" is just called "installing" on Mac OS, linux, windows, and various other OSs, and is being done all the time on those OSs now. Yes, it's not perfect and people get scammed/pwned/etc, but that's true of iOS anyway. Go ahead and make the apple store the only built-in one and make a scary prompt to do others and have your kill switches and other modern protections -- its a rather dumb straw man to pretend the alternative to the current system is literally nothing.)
Apps are standalone user experiences. Native apps play by the operating system's security rules, while web domains operate within the sandbox of the browser. Web apps are just websites in standalone mode. If you misunderstand web apps as some wicked things coming out of your trusted browser to party on your device, you might not see clearly in the Apple vs. EU debate.
Apple hides no longer behind browser engine restrictions, they are going after the heart of what lets developers deliver full-fledged app experiences without the need for native installs from app stores. Apple sees these capabilities as a direct threat to their app store model: the web IS the potential rival store diminishing that sweet revenue close to 100 billion dollars a year.
Apple loves to claim in legal debates and at congressional hearings (which is a company smell) that web apps offer a viable alternative, thus denying an App Store monopoly. But behind the scenes, they've choked browser engine choice on iOS and crippled WebKit to undermine that exact web alternative. The ability to deliver compelling standalone experiences from the web stalls because major platforms like iOS can't be trusted to keep pace with industry standards.
It's like a public transport company deliberately making their service inaccessible: "Sure, wheelchair ramps are nice in theory, but since nobody really uses our trains this way (because we never installed toilets for this user group), forget the ramps. Sorry for the inconvenience it might cause to this group who tried using trains anyhow, instead of the suggested Apple Car with our innovative iPiss system. Oh, and those pesky other train companies we're forced to allow on our tracks? You have to make your trains just as inaccessible because, uh, Apple Car is just safer to deliver wheelchair experiences!
Security is not an argument. WebKit was capable of sandboxing websites, as are Gecko and Chromium. If Apple wants to protect its users and treat them as adults, they should warn them when downloading browsers, that is it. If you want to play apple safe, stay by Safari. You do not need web apps, anyways. Your system is not in danger if I download “shit” on MY iPhone. In addition, Apple is capable and it is not an unreasonable ask to make iOS secure for web browsers. Every other OS, including their own macOS, does this.
It's baffling how Apple underestimates the intelligence of judges and lawmakers. Should Apple try to cripple web capabilities for alternative browsers (directly like the current plan is or even subtly with keeping iOS sub-optimal regarding web app security), may those fines come and let them be staggering. Apple choked web capabilities with WebKit and now does this directly by misusing the power of iOS. Apple shouldn't get to block the web alternative to their App Store while pretending to offer one on legal battlefields.
For web apps you need developers who are not threatened by Apple and iOS to pull the plug on their product any time. Like they are trying to do now. Web app usage and adoption would also be boosted if the developer community stopped calling “install” what is a switch from tab to standalone mode. Using the word "install" undermines not just the inherent simplicity of web apps but the long established trust in the safety of browsing websites within a controlled tab. The word "install" creates a false sense of heightened risk and potential device alteration. This creates unnecessary confusion and suspicion, hindering user adoption. We should build upon the success of the web, emphasizing the truth that web apps are simply enhanced websites and leverage the implicit trust users already place in the web security model.
I agree with all of this except for your bafflement. Justice doesn’t always prevail and Apple’s legal gambit might work.
Remember how Microsoft got in legal trouble for bundling software in the 90s? A judge ruled that Microsoft had to be broken up for their monopolistic and anticompetitive practices. And today Microsoft has leveraged the popularity of Excel and Powerpoint to get every business to use Teams and the rest of the suite.
Sometimes big business can just defy the courts and get away with it.
but I just did not... I did not expect Apple to try another round... their argument is just so transparent and weak in my eyes
I am studying DMA and I still think there is no way they can get away with this
I would really love some open discussion somewhere with legal experts and Chromium, Gecko, Webkit engineers, even android, windows, linux, mac, ios engineers.
But even without them, web apps just literally work in all OS so Apple cannot really claim it is that much effort to be secure on iOS.
Does anybody know any security issues that ever happened because of modern web app capabilities?
How on earth is a native app more secure, does apple has access to source code?
Apple uses W^X, meaning all the executable code is included in the app download. If the app writes to some memory, eg after downloading something from the internet, it can't then jump into- execute- that memory.
When Apple or anybody reviews an app's compiled code, the code they review is always the entirety of the code that can run on a user's device. This applies for App Store and for new post-DMA marketplaces (that can only install Apple Notarized apps).
The exception is Safari because it can compile JS into machine code and jump into it. That allowance is now being extended to new post-DMA web browsers. It's up to Safari and other post-DMA web browsers to prevent any JS from making nefarious machine code.
The exception is already bad for iPhone security, but without it battery life and performance of web browsing would tank. Actually, you can remove the exception with the Lockdown Mode setting, eg if you are a politician or think advanced hackers might target you.
well if you trusted Apple with Safari you can do so
why is it such a problem foryou if I trust Google with Chrome on an iPhone or Microsoft or Mozilla?
I find this extremely misleading: "the exception is already bad for iPhone security"... not if you stay with Safari
I travel regularly on rails with a private train company instead of the train company that actually built those rails... Apple has nothing to do with iPhones that get compromised because of Google or Microsoft or Mozilla
Apple should concentrate on Safari and stop fearmongering... or just solve these iOS challenges to make every web browser more secure
how come macOS is just fine with fully capable web browsers?
Three vulnerabilities that involve visiting a webpage, and all are due to the W^X exception I mentioned. Something that users do very often, unlike with installing an app. Apple also can't remove webpages from the internet, it can remove apps. It doesn't scan webpages before they're published, it does this with apps. A webpage can have an advert, which is loaded from a different server. A webpage can redirect you to another webpage run by another company, without user confirmation. Etc.
> or just solve these iOS challenges to make every web browser more secure
That comes at a cost though. Increased battery usage, memory usage, and slower web browsing. As I explained, there is a setting called Lockdown Mode which enables this, but it's a user choice.
> how come macOS is just fine with fully capable web browsers?
Well macOS is less secure than iOS - and Safari is a weak point on macOS as well - but users also don't expect it to be as secure. For example I expect that apps can read data of other apps on the desktop, but on the phone there is a separation enforced. There is a clause in the DMA for Apple to maintain security which is their justification for Notarization and some other stuff that isn't done on desktop.
Also macOS started in 2001 and has been basically backwards compatible since then, if it started in 2010 like the iPhone then it would be a lot different in terms of the security architecture.
You are being very argumentative and hostile without understanding what I'm saying, which I don't appreciate because I was just trying to answer your question about security.
I would like this thread to be a somewhat deeper discussion about DMA and web apps.
I would welcome true tech or legal arguments. But please if you are an apple-bot or rather less familiar with web tech, read more before commenting. I don't really want spam arguments like you claim I must be protected from myself using web apps via Gecko or Chromium. I am fully capable to make my decision and you can make yours: just NEVER download a browser engine other than Safari and you are Apple-Safe.
I miss a discussion about legalities and technicalities, about freedom of choice and competition. Apple must prove why users who trust other browser engines should not get access to web capabilities those OTHER browser companies find secure enough. Some potential talking points I would suggest:
– concrete examples of web capabilities that are NOT going to be available on iOS versus macOS (and every other OS): service workers, camera access, local storage persistence? Does anybody know?
– do you think Gecko and Chromium are just as safe on the CURRENT iOS as Webkit was when Apple allowed service workers for example? Apple cites dangers, are these theoretical dangers of potential not-industry-standard-browsers or does these dangers apply to Firefox and Chrome too? Is it really necessary and to what extent for Apple to make changes on iOS so that battle tested browsers from companies like Mozilla, Google, Microsoft could use modern web capabilities with clear conscience on iOS too?
https://developer.apple.com/support/dma-and-apps-in-the-eu#8
– what is this ”new integration architecture” that would make web apps more secure and how much effort would it really be to foster web app security on OS level if not already in place on iOS? Being Apple one of the richest companies in the world and having macOS that has a good enough architecture I am sure Apple legally is bound to change iOS to support secure web apps if the effort is reasonable.
– Apple was forced to allow competing browser engines and apparently must be forced to give other browser engines access to modern web capabilities. How?
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...
“In particular, each browser is built on a web browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications.”
Will this suffice legally or does the DMA text need improvement? I think this is enough since the text requires Apple to give way to alternative web browsers with the CLEAR INTENTION that the gatekeeper could not determine the functionality and web standards that are accessible on iOS. The text explicitly mentions web apps and that the goal is breaking a gatekeeper's power to cripple web apps.
You are right. I was sure that something like this cannot happen and I was a bit in shock, I must admit. Web apps on macOS and on every other OS using modern web standards, it seemed the final step to allow alternative web engines on iOS. I mean the arguments of Apple are so weak. But I understand now that the existance of the DMA is not enough and Apple must be forced along the way. Just sad.
> what is this ”new integration architecture” that would make web apps more secure
I think this "new integration architecture" is a very flimsy excuse. To host PWAs, a browser needs the ability to (1) ask iOS for permission to place an icon on the Home Screen, (2) launch certain "tabs" (Home Screen apps) in a separate window. Safari can already do this; they just need let others do the same. Since the PWA is hosted by a specific browser, I suppose you also need a dialog telling the user that XYZ app will also be deleted if they try to delete the browser.
When you have a tiny market share, argue for open standards. When you gain the majority, close the gates and pull up the ladder. Oldest playbook in tech. We've particularly seen it many many times with chat platforms.
You are right. At the very beginning, Safari was innovation and Jobs wanted the web succeed. I meant of course the period when webkit was the only browser engine allowed and Apple claimed the reason was they wanted security etc. Now it is clear that even then, the true target was web capabilities and the hindrance of them via webkit control. Now that they use iOS to disallow these modern web capabilities in competing browser engines too, they admit to their true target of the past 10 years or so too.
Dupes are not just for the exact same URL. This topic has gotten a lot of attention on the frontpage, and there's no significant new information in this article.
you seem to be protecting people from discussing what they want to discuss
in addition, I wrote 2 first comments asking people to focus on a deeper conversation
and my focus was both in my forcefully changed title and in my first article-like comment that what is actually happening is attacking web capabilities
the first 2 comments were mine, an article and an ask towards the community to discuss things on a higher level (tech, legal) and forget these emotional outbursts that I hate pwa and I just dont want you to install another browser and that oh I love my walled garden because peopel just can use Safari with its protections
even if my thread was also flooded with not too deep comments, I think shadow banning was uncalled for!
A submission getting comments isn't automatically a sign that it should be on the frontpage. Anything controversial or outrageous is likely to get a lot of comments any time it makes the frontpage. The really insidious part is that unlike the really interesting submissions which are one offs, these topics are being fed by a news cycle and a content treadmill, with a steady stream of new articles mostly rehashing the same information. So they tend to crowd
To use this article as an example, you say you want to see a higher level discussion about the legal and technical aspects. A proper legal review of Apple's DMA position vs. the actual regulation text would definitely be fascinating to read and new information we haven't already seen multiple times. I'd totally upvote that. Maybe there's even a chance that such an article would lead to the higher level discussion you ask for. But it doesn't feel like that's at all what the article is? There's no analysis, just an assertion that this breaks the spirit and the letter of the law.
(I don't know anything about the various grivances you listed. I was just replying to agust since they were under the false impression that dupes were only for exact submissions of the same article.)
Keep in mind the criterion for dupeage: has the story had significant attention yet? One can argue that this story was major enough that half an hour of front page time wasn't significant, even though the thread did get 100 comments.
The second submission, however, spent 16 hours on HN's front page and got over 800 comments. That clearly qualifies as the story having significant attention, meaning that it was both standard and correct to downweight the current submission. The only question is whether it should have been formally marked [dupe] or merely downweighted as a follow-up (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...), but we don't have precise rules around that.
not just the link was new from open web advocacy, I also posted actually a piece to try to have a more focused and deep conversation
so they changed my original title that was actually funny and to the point, marked as duplicate and so the writer of the article from open web advocacy and my article-like comment was shadow banned, thanks!
apparently my former title was too much for this site: "iPissed: Apple is after web capabilities to protect close-to-100B App Store Tax"
which was relating to the article (and you can read the title of the original article after clicking) but I did not like "kills web apps" because it is not true in my opinion, tries to kill web apps or fights against them or cripples them in the next iOS release...
it sounded too eternal and I think Apple will be forced by DMA to do the opposite
I really am curiouos why and who did my creativity bother?
I found guidelines not rules:
"Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize."
For me, "kill web apps" is misleading since we have to wait and see how the EU reacts. The original title is more of a clickbait.
I am not a power user of hacker news. I found a title to fill in and did my best.
Had I seen there a link to the guidelines or a text like: please use original title if possible, I would have done it. It is actually 1 minute "site engineering" to mention this on the submission page.
The title you submitted ("iPissed: Apple is after web capabilities to protect close to 100B App Store Tax") broke that guideline badly. It's standard moderation practice to revert titles when submitters do this. If you felt the original title was misleading, then it would have been correct to change it, but definitely not by editorializing and making it more baity. On HN, being the submitter of an article doesn't confer any special rights over the title—I know other forums work differently, but this is an important point to understand about this one.
It's also standard moderation practice to downweight follow-up stories when a major ongoing topic has already had significant discussion recently, as this one has. We can argue about whether or not the story should have been formally marked a [dupe], but the basic moderation call to downweight it as a follow-up thread was, again, the standard one. Otherwise HN's front page would routinely be filled with follow-up discussions of the same few topics—whichever ones are most controversial that week—and that is not the site we're trying to have here.
It's not a problem, of course, that you were inexperienced with how HN works and broke the rules by accident. HN can be a cryptic place and it can take a while to get oriented. What's not fine, though, is posting indignant comments complaining about how you've been mistreated by what is in fact ordinary practice. Such meta drama is off-topic in the threads and has a way of taking over discussion if allowed to, so please don't do it again.
You're welcome on HN! Just please make sure not to post in the flamewar style to HN threads. Again, I know other forums work differently, but we're trying for thoughtful, curious conversation here, and flamewar destroys that, so that's the most important thing to avoid while commenting.
you have experience with others and if clickbait is a problem, original title is totally ok for me
others wrote it is outrageous I think I would not have even recognized the duplicate flag or that the title changed myself :) it gave me the false impression something bad happened to me :)
you can totally remove these comments of mine complaining, I iterated on this now and everything ok!
yeah this you are terrible comment may have been too much, I will not be personal in the future!
Thanks for the kind replies! Don't worry, the only thing that matters is using HN in the intended spirit going forward. If you have questions in the future, feel free to send them our way at [email protected].
It's alright, you know now for your next submission.
Regarding the dupe removal: I am slightly inclined towards your side, because it's not really a dupe, but, still I understand where the mods are coming from, especially if a good amount of discussion already happened around the same topic recently.
and I wrote a nice article-ish piece myself, trying to get above "I want my walled garden" and "everybody hates pwa" comments you find under those links above...
I think that’s what this decision is all about. When Safari was the only browser engine on iOS, PWAs didn’t threaten the App Store because Safari delivers a degraded experience with them.
With alternative browser engines mandated by law, Apple faced the possibility that Chrome or Firefox might make PWAs easy to discover, easy to install, and feature-complete. They might have begun to see serious adoption and investment. I think Apple did not want to risk letting that happen.