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.
... 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.
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.
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.
... 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:
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...
>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.
