Why Dolphin Isn't Coming to the App Store | Hacker News Reader

Why Dolphin Isn't Coming to the App Store

daringfireball.net

64 pointschmaynard75 comments

> Swift Playgrounds is an exception too. Apple trusts itself to use JIT compilation safely, but not third-party developers. That’s not unreasonable — but I’m not sure it’s compliant with the DMA.

> That’s not unreasonable

Is Gruber paid by Apple?

Are you implying Apple should limit Apple-made apps on the iPhone?

They should or allow other developers to use the same features.

In the past that was basically the rule OS vendors were expected to abide by

This has never been the case. Apple has always had non-core apps that use private APIs.

...which doesn't make it right. Even the existence of "private APIs" is a massive red flag. If an operating system feature is accessible from user space, then it should also be documented, supported and legal to use.

"Legal" is such a mind blowing term to use here. How can it be illegal for you to use the features that are designed into the device you bought?

Limiting it arbitrarily for an artificial advantage should be illegal.

I just don’t agree with this for a moment. And ironically the topic was covered in Gruber’s WWDC talk. What you’re proposing is exactly the same as saying that Apple is not allowed to privately test their APIs and frameworks in their own software before they let others use them.

Of course they should be able to do that. Of course they do not have an obligation to open everything to everyone at all times.

This is not like the bad old days where Microsoft used private APIs to disadvantage third party software in an operating system that literally had 95% world wide market share. I don’t know what share iOS has, but it’s a tiny fraction of the installed base of all operating systems.

>This is not like the bad old days where Microsoft used private APIs to disadvantage third party software in an operating system that literally had 95% world wide market share.

This is much worse than the bad old days. If an app is in a business Apple doesn't like or uses technology Apple doesn't approve of they just ban them outright.

It’s not worse at all, that’s ridiculous. Most devices now run Linux. The world of software is far more open than it was in the 1990s.

That doesn’t mean every device needs to be open.

>That doesn’t mean every device needs to be open.

That's your opinion.

It’s my device. I should have the right to invoke any API, public or private, just as Apple has the right to change the private APIs out from under me. Same as on the Mac.

I disagree. I want my phone to Just Work. I don’t want people to publish software that uses unstable APIs because that means your software running on my phone is going to break when I upgrade it.

There are many dimensions to “freedom”, and in the case of my phone, I want freedom from janky software that breaks when the OS gets a minor upgrade. I want the freedom of a device that almost never fails. I want freedom from malicious software that puts its fingers down my throat and rips out my private data because some alpha quality API has bugs.

In any case, you can and do have the freedom to use these private APIs on your phone, you can do it right from Xcode and install the software directly on your phone.

The only freedom you don’t have is the freedom to publish that software as a product and risk making my phone break, or worse.

Great, don't run janky software on your phone then. Exclusively use the App Store. Your preferences should not impinge on my freedoms.

Also, if you happen to use a Mac, all that same private data from your phone lives there too. I haven't heard a good argument for why this one class of device should be open while the others are locked down, especially given the availability of secure enclaves across Apple devices.

> You can and do have the freedom to use these private APIs, you can do it right from Xcode and install the software directly on your phone.

If I pay $99 a year, have access to the code, renew my certificate every week, and stay in Apple's good graces. To me — and seemingly to the EU — this is simply not acceptable.

> Exclusively use the App Store. Your preferences should not impinge on my freedoms.

I understood you to be arguing that the canonical App Store should allow use of private APIs.

If your argument is simply that there should exist other ways to get apps on your phone, then we agree. I wouldn’t touch an alternative App Store with your ten foot pole, but go nuts.

But you originally said,

> If an operating system feature is accessible from user space, then it should also be documented, supported and legal to use.

And it was this that I disagreed with. Apple has every right to test APIs without committing resources to documenting and supporting them.

ETA: also, as far as I know, you don’t need to pay $99 to compile and build locally. I did just that the other day and it seemed to work just fine.

> If your argument is simply that there should exist other ways to get apps on your phone, then we agree. I wouldn’t touch an alternative App Store with your ten foot pole, but go nuts.

Oops, I guess I should have read the rest of the thread more carefully. Yes, this is what I meant — sorry for the misunderstanding. Apple should be able to do whatever it wants in its own App Store, and I don't think that private APIs need to be documented or available to use without an entitlement. However, I don't think that I should be prevented from using those private APIs in apps outside the App Store.

I argue that I’d like to use a JIT in apps on the app store.

I would expect that of Apple, yes. Apple should eat its own dog food to make sure that the iOS security model doesn't require exceptions for their own applications.

Practice what you preach.

They should pay Gruber more then to keep him from publicizing the issue at all.

That aside, if Apple's sandboxing of the OS is solid, I don't see how a JIT would be problematic.

There have been bugs that allowed you to do crazy things because of Safari’s JIT before (to the point they added a switch to the OS to disable it). Maybe they figure if Apple can’t write a safe one nobody else can either?

I should think proper sandboxing of the rest of the OS should contain the mayhem to the process/container though.

I think most of us on HN understand that "safety" is something you just have to accept is never 100%.

As an example a team responsible for security can test the standard image libraries (libjpeg, etc.) using file-fuzzing to find any bugs around buffer overflows, etc. It's good they do this but we all know that this is still a statistical shot in the dark that may still leave a vector somewhere in the framework.

I am fairly confident that the JIT restriction is about preventing third party browser engines (chrome) from running on the iPhone, not about security. When Google looked like they were investing heavily in PWAs they could have become a threat to native apps

Apple’s BrowserEngineKit allows for the use of JITs. I have a link to the docs in my article.

Correct. If you enable Lockdown Mode, the JavaScript JIT compiler is disable by default in WebKit:

https://support.apple.com/en-us/105120

So Apple considers its own trusted JIT a security threat surface.

The problem is that a JIT implies that you can load arbitrary binary code into memory and execute it.

This means that your app can load arbitrary updates from the server and execute them, for example based on some purchase not made in the AppStore.

This is all about keeping the 30% tax and only tangentially about security.

Well, it's about bypassing App Review and other static security analysis, undocumented apis, etc. I think there's a fairly strong case here that it's about more than just protecting revenue (which it is also!)

Given the sandboxing and the security architecture of iOS, my conjecture is that apps could be perfectly safe even in light of the use of undocumented APIs (calls to which can be and are obfuscated even in today's setup) and accidental security flaws (which can and still do exist even in today's setup).

Not directly, but for about 20 years the foundation of his career has been professional Apple fanboyism. So, if what you're really asking is "does Gruber have a financial incentive to speak well of Apple?", the answer is "yes".

I don't know about "paid" but his column has moved from "shill who sometimes has a point" to "rabid fanboy" recently. As a recent example [1], he claims Japan's primary reason to punish Apple and Google is protectionism for Sony and Nintendo. His point is so strained he (intentionally?) fails to mention Microsoft, a check notes American company.

[1]: https://daringfireball.net/linked/2024/06/15/japan-app-store...

I’m glad I’m not the only one who has noticed this. Gruber’s take on Apple is generally good but politically his comments are often cringeworthy, to the point I don’t read the website regularly any more.

It’s not protectionist to force Apple to open up the App Store in your country. It might be disagreeable, for some people, and that’s fine, it’s ok to have an opinion. But if you’re going to throw around big words you should know what they mean.

He mentions the reason for being protectionist because rules are not applicable to Sony and Nintendo. It might be disagreeable but you have not given any reasoning.

If Japan applied tariffs to iPhones to raise the price of them relative to domestic phones then it would be protectionism. That is the dictionary definition of protectionism.

They didn’t, in this case, so it’s not.

Sony Interactive Entertainment (which I believe is the "Sony" he's referring to) too is an American company.

eh - I'm not a fan of Gruber, but Gruber is fairly consistent here. He strongly believes in low-government intervention into companies. He strongly dislikes regulation, especially of tech. You don't need to be an Apple shill to have those opinions.

Microsoft would welcome a law that forces Sony to allow Xbox Game Pass on PlayStation.

Gruber is part of a strain of thought that masks anti-anti-monopolist beliefs behind the idea of "realism", as Cory Doctorow describes it[0] (the same category blogs like Techdirt belong to). Basically he's operating under the idea that big tech is so massive that any attempt to regulate big tech will fail and just eliminate the smaller competitors in the market (they're arguing that anti-monopolist actions fit the idea of a "compliance moat", where entry in the market is made so difficult by regulations to the point where only big players can exist. A basic example of a deliberate compliance moat are banks - there's an absolute truckload of laws and regulations before you can become a bank because if you're going to keep people's money, you need to be goddamn careful with what you do with it. At least in theory; enforcement of banking regulations has been spotty before and that's why the 2008 banking crisis both occurred and saw almost no legal punishment for those involved.)

You can see this with his other articles on the DMA, where he argues that the EU (or Japan in the case of the recent law they passed, see other commenter) are doing this specifically because they want to punish US big tech[1][2][3], rather than acknowledging the fact that these companies all being US giants is a mere coincidence and this would have happened regardless.

Even if the monopolist manages to mask himself behind good PR (which Apple has), they're still a monopolist. It's just that the digital age created a new type of monopoly: the platform/ecosystem monopoly, where a company that on paper has other options available in its market, is able to lock in it's business partners and make them unable to move because of the sheer size of it's existing customer network (whilst also keeping those same customers locked to the platform in a vicious cycle).

Apple is but one example (and arguably the most egregious as they exploit and enforce theirs to a degree that's pretty extreme), but most of GAFAM operate their own platform monopolies with varying degrees of abuse.

It also goes hand-in-hand with absolutely bizarre arguments and misunderstandings surrounding the GDPR[1]. In their heads the destruction of the EU digital tracking market while (US) big tech washes it's hands of the regulation presents itself as a failed anti-competitive measure rather than the clear intent which is to well, destroy the digital tracking market in the EU, which is what the GDPR is entirely about. (Since the EU considers digital tracking to be unethical and a violation of the right to privacy.)

The weird thing is that both Techdirt and Gruber are otherwise pretty clearly pro-consumer rights but have this almost absurd belief in the free market self-regulating without laws while a free market without laws (well, they're mostly unenforced or weakly enforced) is what got us here to begin with.

[0]: https://pluralistic.net/2024/02/06/spoil-the-bunch/

[1]: https://daringfireball.net/2024/04/edpb_meta_pay_or_ok

[2]: https://daringfireball.net/2024/01/apples_plans_for_the_dma

[3]: https://daringfireball.net/2024/03/ec_non_compliance_investi...

> rather than acknowledging the fact that these companies all being US giants is a mere coincidence and this would have happened regardless.

LOL. I should just take it as a fact, right?

The short answer is "Yes." and the long and detailed answer is one that is longer and translates to "Yes."

Perhaps he's just calling it "not unreasonable" from the point of view of Apple, not from some objective definition of reasonableness. Of course, Apple is not going to consider itself an attacker in its own security model. Very few software companies are honest/realistic enough to consider "inside threats" from their own software. So if (and only if) you are Apple, it's reasonable for you to trust Apple to use JIT safely.

Of course, as an end user, you need to consider third party apps and your operating system as potential attackers in your own threat model. So, from a user's point of view, allowing the OS vendor to do something that a third party app can't do, doesn't make much sense.

As a user, I would like to use a Firefox that is a real Firefox, not some chrome on top of a Safari instance. Similarily, I'd like to develop apps that make use of NFC without paying apple a 100$ a year. As a user, I'd like to use JIT compilers in emulators. Maybe I'd like to run a Linux VM on an iPad Pro, we know full well the chipset supports this wonderfully.

As far as safety is concerned, memory safe JITs are a thing. If they're worried about secret APIs, an ACL can be enforced in many different ways. If they're worried about syscalls, apps with JITs in them can be sandboxed.

Every time Apple's restrictions come up here there are dozens of people who defend it and claim they love it. Why would Gruber need to be paid to have the same opinion?

So I'm not overly familiar with either JITs, Apple's policies or emulators, so this may be a stupid idea, but I was thinking: Apple does allow exactly one JIT on iOS, in its JavaScript engine. What, technically, is preventing anyone from writing a recompiler from PowerPC machine code for the Wii to ASM.js (or even WebAssembly) and then throwing JavaScriptCore at it? It's not gonna be as fast as a recompiler straight to native code I guess, but could it be significantly faster than interpreting?

From some quick Googling, it seems like JavaScriptCore is running with the JIT disabled in most apps, but surely e.g Chrome is running with JIT enabled. Convincing Apple to let you use JavaScriptCore with JIT enabled might be easier than convincing them to let one run one's own JIT.

JavaScriptCore doesn't use a JIT when used in your own apps. When you embed a WKWebView it runs out-of-process and has JIT enabled. Without the entitlement you cannot execute any written memory by your own process.

All 3rd party browsers today use WKWebView and add their own "chrome" over the rendered page. In essence Chrome/Firefox for iOS are really just Safari with custom chrome for bookmarks etc…

What exactly is preventing you from making an off-screen WKWebView and pointing it at some bundled HTML/JS which allows the app to run arbitrary JS through some IPC? I guess App Store guidelines would come in the way, but I bet it it would be technically possible

It is technically possible but the IPC will destroy you. You would need to transfer inputs and outputs as well as have JS shims to call it. Most of the code will be doing tons of memory accesses which will need to be transferred back and forth across the process boundary and orders of magnitude more cost.

If you did want to try the best approach is probably to compile Dolphin to WASM and render via WebGPU. Then you can JIT WASM. But I suspect that the overall performance will still be lower. (Although a web version of Dolphin would still be super cool.)

I don't think it would be as simple as compiling Dolphin to WASM. Since Dolphin itself implements a JIT compiler that emits native code you would need to also teach Dolphin to emit WASM code.

Other concerns raised by sibling comments aside, that'd amount to a new port effort, virtually equivalent to a web app.

Oh yeah it's a huge amount of work, I don't want to make it sound like I think people should "just" take Dolphin and port its JIT to JavaScript.

Bet there'd be interest in a web version of Dolphin.

Dosbox-on-the-web has proved pretty popular, and a lot of old games are available on the web that way.

Honestly it would be more cool if developers for once started to boycott Apple here, instead of jumping through their hoops.

Meh that won't happen until there are decent alternatives out there. Google's Android isn't such an alternative, and other options aren't supported by all the services people need to use.

> Google's Android isn't such an alternative

It absolutely is. Don't be delusional lol. Here's a video of dolphin running on android: https://www.youtube.com/watch?v=Tp-D4GvUxY4

Yes, but you get more money out a single Apple customer than from 5 android users, and that's the problem of this alternative.

It's about money, not technical capabilities.

Dolphin is free. 5x0=0. Then you have to consider the platform fees.

So for android: One time fee of $20, yearly $0 profit

For apple: Yearly fee of $100, yearly $-100 profit

It's an alternative if all you want is emulators on your phone of course. For me, Google Android isn't a meaningful alternative to iOS, simply because I trust Google even less than I trust Apple.

that's easy to alleviate https://grapheneos.org/

Custom ROMs is in the category of "other options", i.e not "Google Android" and not "iOS". I can't install the money transfer and banking apps I need on a phone with a custom ROM.

You can though. Google Play is available if you want it – preferably in a separated profile. Most banks work. Only NFC in Google Wallet/Pay is blocked.

Well I wish this was the case as well. Most developers writing apps are making them a for a company/employer. Try to telling whoever you work for to ignore iOS for moral/ethical reasons. Companies and even independent devs are just trying to make money. Also if a company or dev says no I am not going to jump through your crazy hoops Apple. Apple is not going to care some other company or dev will. It won't really effect apples bottom line much if at all. Entities publishing apps are a disparate group there is no coordination, Apple a single entity that also has the private cryptographic keys for these horribly locked down devices. So apple basically holds all the cards here when dealing with a non-coordinated of people and companies making apps. The only way Apple would care is you could some how basically get almost everyone to boycott making Apple apps.

It also does not help that most users don't understand that the way the device is locked down really limits their ability to truly own their device. Even those that have some understanding of how apple is basically infringing on the owners right of exclusion by not letting them load their own boot ROM and/or OS keys to sign OSes/apps themselves or sideload. Some how think that this being prevented is a good thing cause "security". Like what? You can't trust yourself, but will trust Apple okay then...

It’s a commonly repeated point that Apple needs developers, but it’s even more true to say that developers need Apple’s users.

Is the IT job market in such a state that we need Apple to have a decent income?

Isn’t that sort of what we’re seeing on VisionOS, where Netflix and YouTube are both like “Nah, we’ll wait…”?

A boycott here would be strange. This is a type of app that Apple did not support until recently, and I’m sure doesn’t really want to support. Finally they were strong armed into allowing it… I’m not sure what a boycott would prove, or to whom. Apple would just use it to argue against further opening up their App Store—saying “look, the developers don’t want to be here anyway”. The developers themselves wouldn’t lose out, since until recently it wasn’t even an option. I guess the only people who would even mind would be users who would want to run emulators on their iOS devices.

> What, technically, is preventing anyone from writing a recompiler from PowerPC machine code for the Wii to ASM.js (or even WebAssembly) and then throwing JavaScriptCore at it

Self respect. At some point you have to recognize that the platform is hostile and abusive towards you, and it's not healthy to continue to engage.

> recognize that the platform is hostile and abusive

That's how Apple lost me as a customer, who had been a life-long user since early Macintosh days. It's an example of enshittification, death by a thousand cuts. Shame what they've done to the legacy, but the magic has been waning for a while. The elves left a long time ago, replaced by greedy sneaky humans.

> e.g Chrome is running with JIT enabled. Convincing Apple to let you use

Current Chrome iOS app uses Webkit and JavascriptCore. I believe Chrome uses WKWebViews and so can take advantage of JIT-enbaled JSC.

As pointed out in the article, in the EU Apple has APIs and entitlements for other browser engines, including allowances for JIT. But as it's an entitlement you apply for, you'll only get it for web browsers

https://developer.apple.com/documentation/browserenginekit

https://developer.apple.com/support/alternative-browser-engi...

It's amazing how many nice things we could have if we stopped using criminal law to reinforce the power of OEMs to exert control over what software can be run on the devices they sell

The problem Apple's walled garden is that they don't mainly use criminal law but technology to protect it. Nothing really keeps you from legally jail breaking your iphone, but it's a painful process and staying up-to-date is a constant cat and mouse game with iOS devs.

Only competition law can force them to open up properly.

> Apple's walled garden

Lol repeating Apple marketing in plain sight.

There is no garden, its a prison.

"Garden" is marketing jargon to beautify the reality of things.

Think of the word Garden, fruits, vegetables, flowers. That word was specifically chosen by their marketing team for a reason.

The reality is that Apple has dictator-style control and the ability to ban/punish people with no oversight. "Garden"...yeah words paint prettier pictures than reality if you let them.

Apple is not using any laws here at the moment at least in the US. Jail-breaking got granted an exception from the DMCA by the library of congress. What apple is using cryptography. Basically, the cryptography gives Apple an extralegal means to enforce whatever it wants.

Also side note: I suggest you read this post/response I posted a while a ago: https://news.ycombinator.com/item?id=39349288

I understand your point and agree that the immediate-term solutions apple is employing are technological

However, the environment in which Apple operates is defined by anti-circumvention. Yes you can legally jailbreak your phone. You can't legally run an R&D program to circumvent part-pairing, or develop a business around aftermarket modification of phones to modify or replace the boot ROM or other components. There's a reason third-party aftermarket modification of vehicles used to be a much bigger market and it's not the technological feasibility of developing modifications. The same is true of consumer electronics

>The only exceptions are Safari and alternative web browsers in Europe.

So ship Dolphin with Opera for Wii and call it a web browser. :)

How about we think of emulation as making games accessible? I know, it wouldn't work for like 99% of use cases, but it sure makes my life easier, as a blind person. Since Retroarch now has accessibility support on iOS, and loads its screen reader when it detects that VoiceOver is on, I can open the game I want to play. And then, using VoiceOver's Screen Recognition, which basically works as OCR and basic image recognition, I can read game menus.

For now, this just allows me to play games on my phone who's gameplay is already pretty playable, like fighting games and visual novels. Except, now I can read menus, character selection screens, character dialog, stuff like that, all on my phone. Too bad Android doesn't have a screen recognition feature for TalkBack; they barely just got image descriptions that VoiceOver had for years. So, even though emulation is far better on Android, I still choose iOS. Apple could, I don't know, sure capitalize on that. I mean, even at the end of this article[1], it shows someone using what I suspect is emulation to play Metroid Prime on a Vision Pro, probably through Dolphin on a Mac. So they surely know about the need for JIT in emulation.

[1] https://nymag.com/intelligencer/article/apple-vision-pro-dis...

This sort of thing won't change unless customers stop buying user-hostile computers. This won't happen, so it'll continue.

Reply on news.ycombinator.com