I kinda disliked the default bundling, but I have always been a power user so it never affected me. It’s like tech users that complain when a device/OS defaults to Google Search rather than Duck Duck Go. So long as I have the power to change it from the default, I simply don’t spend that much effort caring about the “tyranny of the default”.
And requiring that apps use the Safari Mobile browser engine doesn’t seem anticompetitive to me. I simply see the browser engine as yet another smartphone API that every smartphone OS requires that developers use (like a file system or a network API).
Modern browsers are a rats nest of complexity. I can’t go a day without HN-type people complaining about the resources that Electron apps suck up - full native browsers embedded into iOS apps would not be much different.
If it's merely "yet another smartphone API" then why is bundling your own prohibited? This has nothing to do with (warranted) complaints about the state of browser complexity and resource usage. It's anticompetitive because you literally aren't permitted to compete with them.
An example, hopefully valid but I didn't double check. Android provides a file system API but presumably I can do FUSE-type stuff in an app without it getting banned from the Play store, right? Maybe "mount" an iso image and let the user browse around in it?
“It's anticompetitive because you literally aren't permitted to compete with them.”
That’s not what anti-competitive legislation says. You are making a cute argument using a slogan term and ignoring the definitions within the statutes.
The internals of a browser aren’t significant when it comes to product differentiation. They are significant when it comes to user-impacting features like battery life, security of data on the device outside of your app, and reasonable app sizes. These are the arguments I have seen that defend AAPL and their walled garden.
Anti-competition legislation is prosecuted based on whether prices for the end user are impacted, not whether there is freedom for a developer to rewrite some internal API that Apple already supplied.
There are much better arguments for anti-competitive behavior against Apple than the proprietary browser engine.
What about not having any form of programming language, interpreter what not on your phone? Or the heavy censoring of available apps, that one might very well not agree with?
For programming language/interpreter that's not true.
Lately I've been doing a lot of "self-hacking" on iOS and I'm quite satisfied with it. There are Python environments, some JS ones. Of course, they're not 100% desktop-like, but limitations aren't that different from various embedded systems. Those can be integrated into widgets/watch faces, on-demand and remote triggered scripts. There's also possibility to write webapps that run in full-screen form (good for calculators, small snippets, there's some iOS API to be used but I didn't bother that deeply to check). Some stuff can be ran completely, there's rich automation library and plenty more.
Could you give some examples? There is nothing for Java or Haskell, other than perhaps the almost killed iSH, but that is also a giant hack trying to balance on a thin wire. Apple didn’t take it down only because the huge backlash, which is not the case for smaller apps, unfortunately.
Most likely for Java and Haskell you won't be able to find anything. I personally used Pyto and Pythonista 3 for Python (there's also Juno for local and remote development if you're into Jupyter notebooks). I also use Drafts, which is editor, but uses JS for scripting and I and few my peers use it for automation and whatnot. I also seen Scriptable in use but I haven't used it myself.
As for other things - I'm Shortcut user and there are few extension to it like Pushcut or Toolbox Pro which extend it. I have shortcuts that manage my devices at home, when I'm there or when I leave, plus stuff I automated some with NFC stickers & Watch. Usually I start with it, when I want to get something automated. Shortcuts + servers provides a lot of automation (especially since I can get the data for widgets or make an action through it).
As for the other (especially compiled) languages I'm not sure if it's possible even possible without more advanced tools (and as far as I remember jailbreak voids warranty, but is confirmed to be legal). One can, however, create iOS applications without being part of developer program (this requires re-signing every week or two, which is inconvenience, but still something that can be automated) and for those 99$/year you don't have to re-sign every period. AppStore presence is not obligatory so one can make use of all sensors and data iOS applications have and even more (as AppStore rules don't oblige to your own personal apps) - and even share it to a small group of friends assuming they trust you, as they'd have to manually accept your dev certificate - something you can quite easily do with family or friends. It works for me but YMMV.
In general I'd say that for power user Apple's ecosystem isn't that restricted as people make it. On MacOS you get widely supported AppleScript that I personally despise due to syntax (and it seems like Apple dropped the idea of supporting JXA lately), on iOS there's reasonable x-callback/Shortcuts automation framework and quite a lot of commercial tools.
Afaik, JIT compilation is disallowed other than for Safari’s javascript engine. This is why x86 interprets instructions for example, which is more of a gray category.
And requiring that apps use the Safari Mobile browser engine doesn’t seem anticompetitive to me. I simply see the browser engine as yet another smartphone API that every smartphone OS requires that developers use (like a file system or a network API).
Modern browsers are a rats nest of complexity. I can’t go a day without HN-type people complaining about the resources that Electron apps suck up - full native browsers embedded into iOS apps would not be much different.