Apple is arguing as if accessing their platform for free was a crime. This makes sense, since they have costs associated with reviews, code signing and distribution. But that is of their own making. Walled gardens should be outlawed.
Apple is arguing as if accessing their platform for free was a crime. This makes sense, since they have costs associated with reviews, code signing and distribution. But that is of their own making. Walled gardens should be outlawed.
Of course, that doesn’t mean I like being stuck with an American cultural hegemony that says sexual content is forbidden, or that needs an encryption export licence from the USA government for apps written by non-Americans for non-Americans, and which still demands annual reporting to the US government for using https.
I’m happy with any walls that meet basic security standards, but I do want a wall, even if it would be nice to choose which wall.
Heck, you could easily imagine a system where software distributed outside the app store can only access a subset of perms if security is such a concern, and that'd still be less anti-competitive
And many of those APIs can be used to extract enough information to fingerprint the device, determine your location or steal your data e.g. accessing the list of WiFi networks or browser history.
So no. The two concerns are very much related.
That's complete nonsense.
Dynamic dispatch has nothing to do with the ability or not of a program to access API. Dynamic dispatch is the selection at runtime of the correct version of a polymorphic function. Obviously, you can sandbox programs written in languages using dynamic dispatch.
I am sure Apple would love to know how you've managed to solve this.
The point of a private API not security, it's to distinguish between the public interface that is meant to be stable and implementation details that might change.
They might do some rudimentary checks to catch obvious usage of private APIs, but it's not part of the security model and still apps show up on the App Store that use private APIs, all the time.
but there is nothing intrinsic to their operation that requires it, and apple could un-plug it.
this is like apple arguing that IE is central to the fabric of windows, and can't be removed during the european antitrust suit.
it's dishonest, but apple will likely make the same claim.
I think this system is called the world wide web.
Apple would have a much stronger case if mobile safari were a first class PWA platform, instead of being almost useless for PWA's. Then the choice would be: make a PWA and live in the browser sandbox, or go through approval and be on the app store.
A podcast player or music and video streaming app, or a game like fortnite, are not going to work as web sites.
> but the two concerns are orthogonal really.
They are not, really.It's clearly not possible for Apple to actually check all functionality of every app, particularly as it's so easy to hide it or to put it in an embedded web view.
In this case, Epic managed to put an alternative payment method in - but they are a trusted brand, so there's no real security issue overall.
But could some other developer do the same thing and harvest payment details? Of course.
Sorry I'm not following. What does any of this have to do with the app store?
The iPhone is a hardware device, not a platform, and it's not fine if Apple wants to be the sole guardian of it. Even the court response here conflated the two. Epic doesn't want to be on the App Store for free (that wouldn't be fair), but it does want to be allowed to install its software on iPhones for free (that is fair).