Ios Allows Alternative Browser Engines in Japan
Key topics
The cat's out of the bag: Apple's iOS is now allowing alternative browser engines in Japan, sparking a heated debate about the implications of this move and whether it should be extended globally. While some commenters, like shmerl, are cheering this development and calling for Apple to open up to alternative browser engines everywhere, others, such as signal11, warn that naive enforcement of competition laws might inadvertently entrench the dominance of Blink, the browser engine used by Chrome. As the discussion unfolds, perspectives range from concerns about Safari's popularity dwindling if developers start recommending Chrome to users, to observations that Safari remains a top choice among tech-savvy users due to its battery efficiency. Amidst the chatter, a consensus emerges that the web is becoming more compatible and less of a monoculture, thanks in part to efforts like WPT.FYI driving towards perfect compatibility.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
3h
Peak period
143
0-12h
Avg / period
40
Based on 160 loaded comments
Key moments
- 01Story posted
Jan 1, 2026 at 8:30 AM EST
9 days ago
Step 01 - 02First comment
Jan 1, 2026 at 11:24 AM EST
3h after posting
Step 02 - 03Peak activity
143 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 5, 2026 at 9:17 PM EST
4d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
There's a chair in every hotel room for iOS users. You can't even chose the software that runs on devices you bought (i don't even say "own").
https://en.wiktionary.org/wiki/cuck_chair
Did Japan decide to push proper competition laws?
I’m sure some devs will love this. But equally, some may worry about the monoculture implications.
It has nothing to do with people no longer using Safari and Apple being sad about that. Other browsers can technically be installed on iOS, but the underlying browser engine is forced to be Safari, which lacks many APIs other web browsers could implement, reducing the need for a native app. It's purely Apple's anti-competitive greed that drives this situation. And the EU, Japan, and the US DOJ have noticed. So far only the EU and Japan have actually taken measures to force Apple to change this.
Here's the entire DOJ lawsuit which includes many other instances of anti-competitive practices by Apple.
https://www.justice.gov/archives/opa/media/1344546/dl?inline
No, we do not want to write our own iOS app where Apple can then extort us for a percentage of any sales through the app, and we have to pay for the priviledge to develop that app, as well as buy Apple hardware to do so.
So instead we use Wifi, where we can maintain one single codebase - the web application, which works on both Android and iOS, but has to use Wifi. If Apple allowed Chrome to use its own browser engine, we would simply tell users to install Chrome to interact with our device. Then we don't have to pay Apple for anything, nor should we have to.
Apple purposely won't implement some APIs so they can force developers to create an app for their app store where they can collect money from any additional sales through the app. It's all spelled out in the DOJ suit, why won't you just read it??
https://www.justice.gov/archives/opa/media/1344546/dl?inline
It would be good to see Firefox with its own engine there for example.
> Use memory-safe programming languages, or features that improve memory safety within other languages, within the alternative web browser engine at a minimum for all code that processes web content
Would Apple themselves meet this requirement? Isn't WebKit C++? Of course, I'm not sure what would be considered a "featur[e] that improve memory safety within other languages".
So any language should be allowed as long as they instruct developers to be careful.
I am sure that Apple will make no other efforts to impede others from unwalling the garden. That would be completely ridiculous, uncalled for, and frankly, un-Apple-esque.
There is absolutely zero way to satisfy the latter part here. It's at best non-enforceable. If I'm using C++ and use std::span instead of a c-style array, is that good enough?
It doesn’t say that it needs to provide absolute memory safety. Based on the linked WebKit guidelines, it seems like they meet the criteria.
My point is the requirement is too broad. It cannot be meaningfully enforced.
And heres a nice video about it: https://youtu.be/Gv4sDL9Ljww?si=Z4riPMKAKcIKaU0s
They are the ones allowing the alternatives because they are the gate keepers. They have "the keys"
For many Hacker News readers who check the website every day, this is not really news. Japan’s been pushing for this for several months.
• (4 years ago) Japan forces Apple to slightly loosen restrictions on ‘reader’ apps — https://news.ycombinator.com/item?id=28387094
• (2 years ago) Japan to crack down on Apple and Google app store monopolies — https://news.ycombinator.com/item?id=38773429
https://www.justice.gov/archives/opa/media/1344546/dl?inline
Who knows if this will actually move forward now that "Tim Apple" gave the current leader a meaningless golden trophy.
https://developer.apple.com/documentation/bundleresources/en...
As absurd as this sounds windows -> iPhone via their phone link is actually almost as good as apples built in ecosystem to the point where I can make phone calls and send texts on my computer. It’s not quite as seamless especially the setup but that is a well done wizard and it mostly works.
Looks like you can thank Apple for that one.
https://github.com/KDE/kdeconnect-ios?tab=readme-ov-file#kno...
https://tailscale.com/kb/1106/taildrop
look at all of that, lol. iDevice is literally copy and paste any file. the end.
Installation: Install the tailscale client
Sharing: Click on the share menu and select tailscale
It's a beta feature so there's also a switch you have to flip for now.
Installation: nothing.
Sharing: Cmd+C/Cmd+V
Similarly with Linux, the sheer number of rough edges, papercuts, and quirks is still too high (regardless of if I’m using a big name DE or hyper minimal tiling WM or somewhere in between) for them to serve as my main desktop environment.
Freedom and privacy exist on graphene.
Why? I am a very tech-minded person but simply don't care about running alternative browser engines on my phone. Am I "wrong" in your opinion?
For example I'm running a pretty sweet calibre-web automated setup with Kobo readers. Ive changed the storefront on my kobo and have seemless sync OTA of selected shelves. And even I struggle to get my wife to choose that setup over Amazon kindle. The very minute there is a single snag, normies (sorry wife dear) lose interest.
https://en.wikipedia.org/wiki/PRISM
https://sneak.berlin/20201112/your-computer-isnt-yours/
https://www.cbsnews.com/news/apple-siri-lawsuit-settlement-i...
Linux on mobile is probably even more behind than Linux on desktop was in the 90s.
Coercion and surveillance problems are pretty far down the list of complaints most people have with their personal devices.
Also the EU, no?
Yes.
Wrong, they do specify "standalone web browsers as well as web browsers integrated or embedded in software or similar" are both covered, that's in the law.
What you're referring to is how Apple chose to implement it. The EU hasn't opened a compliance case on Safari yet but I expect they'll do so at some point.
https://www.theverge.com/2024/1/26/24052067/mozilla-apple-io...
But right now you can use uBlock origin lite in Safari. Or any other of multitude of other adblockers.
Anybody that thinks otherwise is hopeless naive, Steve Jobs himself envisioned a web app future as the future of technology; before Apple found out the gold mine that the app store became.
This is inappropriate. People can reasonably disagree without being insulting to each other.
Just read the summary that Gemini provides for a good quick understanding, and follow up the multiple articles about it. Then please don't come back and say that there is nothing concrete about this evidence, that is just people speculating about a behavior that Apple has been engaging repeatedly and continuously for over a decade.
I think that's the hypothetical part, it's not reality. Safari continues to be a fully modern browser. It doesn't release new features quite as fast as Chrome, but it does generally adopt them.
If Apple were attempting to put a "stranglehold on innovations on the web", Safari's feature set would look very different. But that's not what's happening.
The only reason Apple has banned alternative engines and continues to hold back on major web technologies is anticompetitive behaviour.
I'm torn on this honestly. Safari (particularly mobile Safari) is literally the only thing keeping the web from becoming Chrome-only. While I would love to see Safari-alternative engines on the iPhone, I fear that the "open web" in terms of browser compatibility is cooked the day that happens: Commercial web developers are supremely lazy and their product managers are, too. They will consider the web Chrome-only from that day forward and simply refuse to lift a finger for other browsers.
That's a bizarre take. It's not even available on most computers. IE was about Microsoft not following web standards and abusing its monopoly position; Safari is a minor browser by market share and is broadly standards-compliant.
> the fact that PWAs didn’t take off in the last decade js purely due to Safari.
So then why aren't PWA's super-popular on Windows and on Android? Since Safari doesn't affect those?
It's officially compliant but in practice there's a lot of buggy implementations in Safari and you'll spend lots of time on workarounds and debugging.
It's also the last non-evergreen browser being tied to the OS so it's the slowest to update, compounding that effect.
IE had a lot of browser features which officially were there but in practice didn't fully work.
I had issues with forms, zIndex, SVGs, backgrounds and localStorage with Safari. All of which I consider basic browser features which should always work.
Of course it's not as bad as IE but Safari is clearly lagging very far behind Chrome and Firefox
Says who?
"Yes, PWAs have become popular on these platforms. I work for Microsoft on the Microsoft Store (app store on Windows) and I work with the Edge team, and I work on PWABuilder.com, which publishes PWAs to app stores. Some of the most popular apps in the Microsoft Store are PWAs: Netflix, TikTok, Adobe Creative Cloud, Disney+, and many others.
To view the list of PWAs in the Store, on a Windows box you can run ms-windows-store://assoc/?Tags=AppExtension-microsoft.store.edgePWA" - https://news.ycombinator.com/item?id=46457849
https://www.google.com/search?q=safari+is+the+new+ie
And Apple purposely will never implement lots of APIs that only their native apps allow (which other browsers implement), specifically to force many developers to create a native app to use these APIs, so that Apple can force the developer to give them a percentage of any purchases made through the app. They can't force a developer to give them a cut of purchases made through a web browser, which is why they purposely hobble the Safari browser engine and then force all other browsers to use this engine. If you can't see how bad this is, then you've been taken over by the reality distortion field.
It's spelled out in the DOJ lawsuit against apple, among many other anti-competitive practices.
Microsoft got sued and lost in an antitrust suit for bundling IE with Windows. Apple bundles Safari with iOS but forbids any other browser engine but their Safari engine. Can you imagine if Microsoft forbade any other browser from being installed on Windows? It's time Apple was brought to justice over their abusive anti-competitive practices.
Here's the whole DOJ suit against Apple:
https://www.justice.gov/archives/opa/media/1344546/dl?inline
>Hard disagree on safari being even in the same ballpark as IE;
It's a crap browser, and Apple implements things the way they want to, especially around touch interactions. So I have to have a real iPhone to debug problems with Apple's implementations. Safari fucking sucks, it just does, and your trolling comment doesn't disprove it.
>what’s your alternative, Google owns the entirety of the browser space?
I don't care if they do or if they don't. All I want is an alternative to Safari on iOS. Is that really so bad??
https://www.justice.gov/archives/opa/media/1344546/dl?inline
You'll still have to debug it. Even when other browsers are allowed, Safari isn't going away.
"Safari fucking sucks" isn't an argument that Apple is being anticompetitive. There are a bunch of things that suck about Chrome too. And Firefox as well. No product is perfect.
>There are a bunch of things that suck about Chrome too. And Firefox as well. No product is perfect.
Google doesn't prevent Apple from offering Safari for Android, Apple just wouldn't be able to make money offering it through Google's app store the same way they can extort iOS developers that sell anything through the native app.
"Chrome sucks too" is very subjective. I've never had a problem with it. I'm curious what you think sucks about Chrome. Firefox - well, I used to use it a while ago, but not so much anymore. I will fix bugs there and they are easy and free to fix. I can't say the same about Apple's Safari.
Apple used to make Safari for Windows, but it sucked so badly, and they figured they couldn't make any money from it, so they discontinued it. So they could definitely make Safari for other platforms, but they would rather force developers to buy an iPhone instead. Fuck that.
I'm sorry iPhone users, but you'll forever be second class citizens in my product sphere, and you can blame Apple for that, until they allow other browser engines.
I can’t help but wonder if your leadership shares your level of disdain for your customers.
Yeah, if you want to test against Safari you need Apple hardware. If you can't be bothered to get some cheap secondhand Apple hardware for testing for your business, then that says more about the business decisions you're making. The idea that Apple ought to be obligated to make its browser available on other platforms seems pretty silly to me.
Sorry, which company is this? Surely you’ll have no problem telling us all, given the strength of your conviction.
They generally are pretty caught up on features. They have webgpu, they support the web notifications API (once a PWA is installed), lots of stuff. My main gripe is that they make it too hard to install PWAs, but we're still waiting for an actual API for that. (Maybe in 2027? [0])
> And Apple purposely will never implement lots of APIs that only their native apps allow (which other browsers implement)
Can you give an example?
[0]: https://blogs.windows.com/msedgedev/2025/11/24/the-web-insta...
>Can you give an example?
Web Bluetooth, Web USB, Web NFC, Web Serial...
Of course Apple will uphold its usual charade to claim that it's about pRiVacy & sEcuRiTy to maintain plausible deniability. They could easily implement it and keep it disabled by default, such that users could make the conscious choice to enable it or keep it disabled. Any adequate analysis of Apple's behavior and motivations has to be checked against their conflict of interest, because they will be biased against technology that could diminish the value proposition of "native" apps which Apple has been taxing so unchallenged for all these years.
Chrome-only non-standards. Note that Firefox is against these, too.
> Any adequate analysis of Apple's behavior and motivations must mention Apple's conflict of interest
I've yet to see an adequate analysis that doesn't pretend that anything Chrome shits, sorry, ships is immediately a standard that must absolutely be implemented by everyone immediately.
Funny how you agree that Firefox opposes these non-standards, and how Google rushes things. And immediately turn around and basically say "no-no-no, Apple is to blame and Safari (and, by extension Firefox) must absolutely implement these non-standard features from Chrome".
The rest of demagoguery is irrelevant.
BTW literally the moment Firefox relented and implemented WebMIDI they had originally opposed, they immediately ran into tracking/fingerprinting attempts using WebMIDI that Chrome just couldn't care less about.
Yes
> but if it’s not that, then refusing to ever adopt those standards (or to provide their own alternatives) is either foolish NIH syndrome on Apple’s part or it’s greed.
Note that Firefox's position is literally exactly the same as Apple's on these Chrome-only features: https://mozilla.github.io/standards-positions/
>Can you give an example?
Web Bluetooth API, and lots of others. My product could use bluetooth but we're forced to work around Apple's Safari limitations and use Wifi instead, which drains the battery faster. We do not want to write a specific app for iOS (which costs us money to build and maintain), which then allows Apple to extort us for a percentage of sales through the app. Bluetooth would be the better option, but Wifi works although is a bit more cumbersome to deal with. So sorry Apple fans, you have to use wifi with our product because Apple reasons.
I am going to open a bottle of champagne when the DOJ finally forces Apple to allow other browsers on iOS.
https://www.justice.gov/archives/opa/media/1344546/dl?inline
Interop 2025 is a subset of web features, but Apple gets a veto on which features get included in each Interop round, and vetoes heavily. It doesn't reflect interoperability in general. Safari also consistently starts out the worst each year, and improves the slowest.
They don't support notifications correctly, they have a semi-broken implementation. Only a subset of sites will work, even though they'll work perfectly on Chrome or Firefox or even minor browsers.
But there's still all sorts of wonkiness they just makes Safari non viable. If you don't PWA install, your storage gets cleared alarmingly quickly. If you do install it's still cleared wicked fast. Notifications seem to have incredibly unreliable delivery issues and require PWA installs to work at all. The features are closer to parity than before but the base functionality is still sabotaged deeply. 'The user is secure' with Apple is amazing doublespeak (the second meaning being securely in Apple's pocket with no where to go).
It's worth noting that Interop participants meet and decide via unanimous consent what they are going to work on each year. The anti-trust case against Apple would be far stronger if they didn't show up & find some stuff to work on, to agree to. And with apologies as I break out the tin foil hat, showing up also gives them some leverage to shape what doesn't get worked on too.
No, we do not want to write our own iOS app where Apple can then extort us for a percentage of any sales through the app, and we have to pay for the priviledge to develop that app, as well as buy Apple hardware to do so.
So instead we use Wifi, where we can maintain one single codebase - the web application, which works on both Android and iOS, but has to use Wifi. If Apple allowed Chrome to use its own browser engine, we would simply tell users to install Chrome to interact with our device. Then we don't have to pay Apple for anything, nor should we have to.
Apple purposely won't implement some APIs so they can force developers to create an app for their app store where they can collect money from any additional sales through the app. It's all spelled out in the DOJ suit, why won't you just read it??
https://www.justice.gov/archives/opa/media/1344546/dl?inline
DID YOU READ IT? Below are some of the relevant sections.
https://www.justice.gov/archives/opa/media/1344546/dl?inline
Rather than respond to competitive threats by offering lower smartphone prices to consumers or better monetization for developers, Apple would meet competitive threats by imposing a series of shapeshifting rules and restrictions in its App Store guidelines and developer agreements that would allow Apple to extract higher fees, thwart innovation, offer a less secure or degraded user experience, and throttle competitive alternatives. It has deployed this playbook across many technologies, products, and services, including super apps, text messaging, smartwatches, and digital wallets, among many others.
9. Apple suppresses such innovation through a web of contractual restrictions that it selectively enforces through its control of app distribution and its “app review” process, as well as by denying access to key points of connection between apps and the iPhone’s operating system (called Application Programming Interfaces or “APIs”). Apple can enforce these restrictions due to its position as an intermediary between product creators such as developers on the one hand and users on the other.
16. Apple wraps itself in a cloak of privacy, security, and consumer preferences to justify its anticompetitive conduct. Indeed, it spends billions on marketing and branding to promote the self-serving premise that only Apple can safeguard consumers’ privacy and security interests. Apple selectively compromises privacy and security interests when doing so is in Apple’s own financial interest—such as degrading the security of text messages, offering governments and certain companies the chance to access more private and secure versions of app stores, or accepting billions of dollars each year for choosing Google as its default search engine when more private options are available. In the end, Apple deploys privacy and security justifications as an elastic shield that can stretch or contract to serve Apple’s financial and business interests.
43. Developers cannot avoid Apple’s control of app distribution and app creation by making web apps—apps created using standard programming languages for web-based content and available over the internet—as an alternative to native apps. Many iPhone users do not look for or know how to find web apps, causing web apps to constitute only a small fraction of app usage. Apple recognizes that web apps are not a good alternative to native apps for developers. As one Apple executive acknowledged, “[d]evelopers can’t make much money on the web.” Regardless, Apple can still control the functionality of web apps because Apple requires all web browsers on the iPhone to use WebKit, Apple’s browser engine—the key software components that third-party browsers use to display web content.
60. For years, Apple denied its users access to super apps because it viewed them as “fundamentally disruptive” to “existing app distribution and development paradigms” and ultimately Apple’s monopoly power. Apple feared super apps because it recognized that as they become popular, “demand for iPhone is reduced.” So, Apple used its control over app distribution and app creation to effectively prohibit developers from offering super apps instead of competing on the merits.
That seems like victim blaming. Apple is the tyrant here.
> If using Bluetooth is a customer requirement (as opposed to merely a “nice to have”), why wouldn’t you go to the lengths to provide an app for them?
Because then have to hire an iOS developer and pay for everything to develop an app, which Apple can then use to extort a percentage of sales for anything purchased through the app. Or I have to write the app myself, and I'm already working 18 hours a day. FUCK THAT. Not going to happen. Apple users will always be second class citizens to me as long as Apple treats other browsers like second class citizens and forbids other browser engines. Making an iOS app isn't a clear pathway to riches, so Apple users will just have to use a more clunky wifi experience. That's just the way it is.
So then why doesn't Firefox support the Web Bluetooth API either? How can you jump to the conclusion that the lack of Safari support is about apps?
The reality is that the Web Bluetooth API is a draft. Not ratified. Not on the formal standards track. And Firefox does not intend to implement it, due to security and privacy concerns around it and the fact that is it not ratified.
But go on assuming it's all about being anticompetitive...
> It's all spelled out in the DOJ suit, why won't you just read it?
I just did a Ctrl+F for Bluetooth and everything relates to smartwatches. There are only two references to Safari, none of which say anything about standards. The phrase "web standard" appears nowhere. The document is 88 pages long, and it's not immediately obvious to me where any of what you're talking about is spelled out.
>Not on the formal standards track.
What a coincidence, Apple gets to vote on what the "formal standards track" is, and they have voted against anything that would hurt their app business.
>But go on assuming it's all about being anticompetitive...
Okay... Apple are anticompetitive and always have been. They forbid their OS from being installed on any hardware that isn't manufactured by Apple, even though it was easily possible to do. Their walled garden is very famous for being anticompetitive - banning any browser from using their own browser engine and forcing Safari is absolutely anti-competitive.
You know what? Just go fucking read the DOJ antitrust suit against Apple, it details the very many ways Apple is anti-competitive:
https://www.justice.gov/archives/opa/media/1344546/dl?inline
But I bet you won't.
But that's not what the conversation is about. I pointed out that in this area, it doesn't appear to be.
So I don't know why you keep pushing this PDF. It doesn't say anything about this specific area. I already checked.
And if you don't care about what Firefox does, then I think it's clear you're not having this conversation in good faith. You're not open to evidence or counter-argument, you just have a knee-jerk reaction that Apple is bad. Well, I'm not going to waste any more time with someone who "doesn't care" about the most obvious counterpoint to their argument.
Which is of course bullshit
--- start quote ---
The allegation that Safari is holding back web development by its lack of support for key features is not new, but it’s not true, either. Back fifteen years ago IE held back the web because web developers had to cater to its outdated technology stack. “Best viewed with IE” and all that. But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds.
...even though Chrome is not the standard, it’s treated as such by many web developers.
https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
--- end quote ---
His remarks at the time of the initial iPhone release (with the benefit of hindsight) were clearly because they weren't ready to expose any sort of native API's when iOS was initially released.
Pissing on you and telling you it's raining was typical Jobs reality distortion field marketing, and not an indication that he actually believed it was raining.
Security-wise, the sandbox should limit damage to within the browser, and if it doesn't that's not the browser's fault. Maybe restrict access to password filling and such though / figure out how to offer an API to reduce the impact.
Standardization, eh? Forcing Safari on iOS and not making it available on the mass market platforms (Android and Windows) makes it a pretty wonky standard. I guess there's a claim to be made for the embedded browsing engine, but IMHO, that should be an app developer choice.
No they won't. People on HN will. Not the average person.
> Security-wise, the sandbox should limit damage to within the browser
The problem is, arbitrary code execution vastly expands the risks. Your "should" is doing all the work there.
> Standardization, eh? Forcing Safari on iOS and not making it available on the mass market platforms
Huh? Apple follows web standards. Why the heck should it make Safari available on Android and Windows? Safari isn't a standard, web standards are.
>No they won't. People on HN will. Not the average person.
Yes they will, Apple has made it very easy to see.
To check iOS app power usage, go to Settings > Battery, where you'll see a breakdown of battery consumption by app for the last 24 hours or 10 days, showing usage time and background activity, allowing you to identify power-hungry apps and manage settings like Background App Refresh to improve battery life.
So yeah, it's easy to see which app is taking the most power, and users can do this easily, unless you think Apple's UX is so bad that users won't know how to read it?
>The problem is, arbitrary code execution vastly expands the risks. Your "should" is doing all the work there.
If that's a problem for web browsers, then it's a problem for every single app in the app store. There's nothing really unique about a web browser app that makes it more risky than any other app. Javascript is already very much sandboxed. And there have been plenty of exploits that already target Safari. So saying other browsers are the problem is like blaming the victim (of Apple's anti-competitive practices).
>Huh? Apple follows web standards. Why the heck should it make Safari available on Android and Windows? Safari isn't a standard, web standards are.
If web standards are standards, then let other web browsers on iOS.
The real reason Apple disallows other browser engines on Safari is so they can force developers to create native apps where they can get a cut of any purchase made through the app. The problems with Apple's anti-competitive practices have been spelled out in the DOJ lawsuit against them:
https://www.justice.gov/archives/opa/media/1344546/dl?inline
And what percentage of users do you think ever check that, or even know it's there to check?
> If that's a problem for web browsers, then it's a problem for every single app in the app store.
No it's not, the app store disallows arbitrary code execution.
> There's nothing really unique about a web browser app that makes it more risky than any other app.
Yes there is -- JavaScript.
> Javascript is already very much sandboxed.
It wouldn't be if you allowed any developer to write their own JavaScript interpreter as part of their own browser.
> If web standards are standards, then let other web browsers on iOS.
That's a non-sequitur.
It does not matter. The functionality is there. If a user can't figure it out then they have other problems that having a smartphone won't fix for them.
>No it's not, the app store disallows arbitrary code execution.
You mean Javascript interpreters inside a web browser? lol. You mean like Safari is allowed to do? So only Apple can allow Apple apps to do this? I'm not sure you're thinking this through. Apples rule is a made-up rule designed to keep competition out, and force developers to write native apps so Apple can extort the developers by taking a percentage of purchases made through the native app.
>Yes there is -- JavaScript.
That's the dumbest possible argument you could make. Javascript has been very much sandboxed and secure for a very long time. There have been flaws in Safari that allowed remote code execution had nothing to do with Javascript, so good luck moving that goalpost somewhere else.
>...by Safari. It wouldn't be if you allowed any developer to write their own JavaScript interpreter as part of their own browser.
I'm not recommending my users use H@ck0rbR0Ws3R, I'm recommending they use Google Chrome, specifically because it supports the APIs my company needs to use for our product (on Android at least).
Okay Tim Apple, the DOJ is coming for you. You can explain this all to them when they come knocking, and they will.
It's easy to see, but seeing doesn't mean the user will do anything about it. I guarantee that for the average user, their list goes something like Instagram/TikTok/FaceBook/Twitter, and they haven't uninstalled any of those yet due to battery drain...
https://www.justice.gov/archives/opa/media/1344546/dl?inline
252 more comments available on Hacker News