|
|
|
|
|
|
by jsjohnst
2149 days ago
|
|
|
> Take f.lux: they spearheaded a feature, were never allowed onto iOS, then Apple developed a copycat feature. I love the subjective memory / interpretation here. Apple didn’t block f.lux, there was no API available on iOS for it to work. Apple decided rather than provide a public API method, they’d just provide the feature itself. Sucks for f.lux, but far less than it did for LumaDisplay and Sidecar. > there is no technical reason for stopping alternative browsers from getting onto iOS 1) alternative browsers exist on iOS. Chrome for example! Sure, you’d be fair to say “not real Chrome”, but then see point 2 2) the technical reason you claim doesn’t exist very much does. Web browsers require the ability to have dynamic code execution from untrusted sources. Look at all the OS compromises historically from browser bugs and you can potentially understand why Apple wants to try to exert control there. The counter argument of course is that Apple has also failed here, there’s been multiple jailbreaks which could be triggered by visiting a webpage, but I see Apple using that to justify their actions further (if even we can’t get it right always, no way others will). I’m not claiming that parenthetical mentality is justified, but it likely plays a part in what Apple thinks. |
|
|
As for the browser: dynamic code execution is a red herring - there are plenty of runtimes like python available on the appstore, and they execute all sorts of crap just fine. Modern browser engines are sandboxed so hard, they are equivalent to (or better than) anything you find in an OS. The security angle nowadays is just a flimsy excuse to keep Safari (the IE6 of our times) from becoming utterly irrelevant overnight.