Hacker News Reader

Comment by musicale | Hacker News Reader

The evidence on the Android side doesn't seem to support this line of reasoning. There are multiple app stores on Android (including Amazon's), and sideloading is permitted, yet there is still a dispute over the platform fee rate that Google is charging for Google Play.

At the end of the day, it's a dispute over money, and specifically the platform commission rate: developers want a bigger cut of the retail app price on Google Play.

View on HN

While Android is more open than iOS in that alternative app sources are allowed, it's still far from a level playing field. The Play Store has special privileges that third-party ones don't, such as being able to automatically update apps, rather than forcing the user to hit "install" for each individual app to be updated.

This information is outdated. Android 12+ allows alternative stores to update apps automatically.

But manufacturers are holding users back on old Android versions

Your reasoning is faulty. There is no Android platform fee for app developers. In fact, alternative Android stores pay no fees at all. The Play Store has fees, and there's a dispute about them, but that doesn't make it analogous to the situation on iOS, which really has an iOS platform fee because it's impossible to install native code on the device you ostensibly own without Apple's ongoing permission.

You can install whatever you want on an iPhone if you’re willing to compile it yourself with one or two shell commands. You do need access to a Mac.

Contrary to popular belief, you can even install a non-safari browser:

https://chromium.googlesource.com/chromium/src/+/main/docs/i...

>Code signing identity

>Please refer to the Apple documentation on how to get a code signing identity and certificates. You can check that you have a code signing identity correctly installed by running the following command.

It has a secure chain of trust in the sense that the machine is secured against user control. Face, meet boot.

Ok? Doesn’t change what I wrote. You can install the cert and profile in a few minutes.

modeless: it's impossible to install native code on the device you ostensibly own without Apple's ongoing permission.

fingerlocks: here, just run these two easy commands to ask apple for their ongoing permission!

My mistake. I thought “asking for ongoing permission” means signing up for free dev account with a throwaway email.

... with a $700+ Mac purchased from Apple, and usually a $99/yr subscription purchased from Apple, plus a network connection to Apple's servers to obtain code signing permission, which must be periodically refreshed or your code will stop running, to ensure you are never independent of Apple's ongoing approval.

Far from “impossible”, which is what GP asserted.

"impossible to install native code on the device you ostensibly own without Apple's ongoing permission" is what I asserted, which is exactly correct.

Ha, was that a stealth edit? Fine, I’ll yield. You can have this win.

But really side loading is not as difficult as you’re making it out to be. The biggest hurdle for most is access to Mac, but renting a cloud instance an option too.

It's not about difficulty, like the number of mouse clicks or something. It's about who has ultimate control over your device. And with control comes the ability to extract rent.

Then you would agree it’s fair to rephrase your original post as “It’s quite possible to install native code on the device you ostensibly own unless you want ultimate device control”?

Your phrasing doesn't make sense. Whether you "want" ultimate device control or not is irrelevant because you can't have it. The relevant thing is that Apple retains ultimate control, you never have it, and Apple uses that control to extract rent. My original phrasing is correct and doesn't need to be changed.

BTW I forgot to mention that the "Chromium for iOS" that you linked to is not a "non-Safari browser". It is the same Safari-wrapper version of Chromium that you can already get from the App Store. The "popular belief" is correct. There is currently no port of any alternative browser engine for iOS. Why would anyone bother to maintain an iOS port for software that can't be practically distributed?

No the popular belief is not correct. Perhaps the link the wrong, but you can mmap W^X and roll your own JIT, which is the only syscall preventing non-safari browsers.

> Why would anyone bother to maintain an iOS port for software that can't be practically distributed?

There is very little difference between a Mac and iOS app these days, and could be practically none at all if engineered correctly.

LOL you think it would be easy to just recompile Blink/V8 for iOS and get a browser you could actually use day-to-day? How many web browsers have you worked on? I have done several years of work on both Chromium and WebKit and I'm here to tell you that an iOS port of Blink and V8 good enough to actually use as a replacement for WebKit on iOS is going to require a huge coordinated effort of a large number of engineers, with a large ongoing maintenance cost afterward. It would probably require a ton of private APIs other than mmap W^X, too.

You're not going to be able to do it in your spare time. You probably wouldn't even be able to get a crippled and buggy version to build at all by yourself. Google's not going to invest in it for no reason while Apple expressly prohibits distribution. The only way there will ever be an alternative browser engine ported to iOS is if the EU actually follows through with forcing Apple to allow alternative browser engines on their App Store and/or alternative app stores, and Apple subsequently loses all of their inevitable appeals in court. Only then would Google (or Mozilla) be able to justify the investment.

Well fortunately the JIT-less work has been done already. One entitlement and a compiler flag away from being done!

https://v8.dev/docs/cross-compile-ios

... except even just in that page there's at least one important feature listed as not supported on iOS (pointer compression) and I'm willing to bet that there are many other issues you'd need to fix before you could call a fully functional V8 iOS JIT port "done". And V8 is only one of dozens of components in the whole browser engine. You are vastly underestimating the complexity of these projects.

Are you sure my first link I originally posted wasn’t a full rendering engine? I know I had read it was included a few years ago. Looks like a custom renderer to me:

https://chromium.googlesource.com/chromium/src.git/+/refs/he...

I am absolutely certain. Chromium on iOS wraps WebKit and adds some features mentioned in the comments in that file, such as translation. But it's still just a wrapper and the rendering engine is still WebKit, not Blink. If you don't believe me, here is the implementation of CWVWebView where it creates the underlying WKWebView: https://source.chromium.org/chromium/chromium/src/+/main:ios...

I'm pretty sure you can sideload without an Apple developer account($99) but you need to reinstall the app every 7 days and you can only have 3 installed at once. The processing on refreshing the install and swapping between more than 3 apps can be automated by using desktop software like AltStore.

> but you need to reinstall the app every 7 days and you can only have 3 installed at once.

So not a realistic option, then.

OMG I wouldn't know what to do with such freedom.

And pay for an apple developer license.

Technically, that isn’t necessary. You ‘only’ will have to redeploy your apps every two weeks or so with a fresh temporary certificate.

And lose your app data each time?

That is not a non-safari browser

The arguments on Android are sometimes even simpler to make (which I appreciate might not be intuitive at all), as there is a space where there SHOULD be competition and clearly CAN BE competition and yet there are arguments being made that Google is going out of their way to stifle this competition regardless, by such techniques as limiting the functionality of third-party markets (a big one was preventing them from supporting automatic upgrades), or their included anti-virus software flagging alternative markets (which reminds me that I haven't caught up on the Epic lawsuit against Google recently, and really really should).

You'll find me ranting about making a non-system permission for automatic updates on Android for years on this forum. Now it's there, and I credit Epic.

But like Windows having IE/Edge installed by default (& being sued for it), Google Play is the default store for Android, & 95% of public doesn't know otherwise.

To be fair (pedantic? devil's advocate?) Samsung ships all their phones with the Samsung store as well. I suspect there's a few other bit names that do similar. A great many Android users have alternative stores, some some probably use them without knowing the difference as well.

To be honest, I doubt many of them care, given all they want is apps from a trusted source, and most people probably trust Samsung if they are buying Samsung phones with specialized Android builds made by Samsung, if they even know the difference.

My comment doesn't detract from that demand. What I'm pointing out is that Apple will suffer from this at a much larger scale, therefore it makes sense that they will fight tooth-and-nail to stop it.

The 'platform fee' shpiel is a distraction from the real problem: iOS must allow alternative storefronts if it wants to survive long-term antitrust scrutiny. There is no other logical outcome.

That may indeed be true. However, the core dispute over App Store fees will likely remain, irrespective of additional app stores or sideloading, just as it has on Google Play.

Solving the single app store antitrust issue doesn't solve the platform fee dispute.

Do you truly think antitrust scrutiny will stop if Apple lowers their rates again? I don't think that's all developers hate about the App Store...

it does, because those who don't want to pay the platform fee would move off to the other store-front (and not use any services provided by the apple appstore).

Reply on news.ycombinator.com