4 ms·

All the things you listed aren’t blocked by the App Store. They’re system level restrictions based on the security model (whether or not one agrees with them)

• lukeschlather 3y ago
  The DMA also prohibits companies from placing restrictions on third-party apps that don't apply to their own apps. So if any first-party Apple apps can ignore these "security restrictions" then Apple may have some compliance issues that force them to remove the restrictions.
  • theluketaylor 3y ago
    But the DMA also requires (not just allows) platform owners to maintain the security of their platform. Many of the security model restrictions for iOS that app developers bump into are unlikely to be lifted by Apple. Most of the places Apple has given themselves special powers is mostly a shortcut to avoid the hard work of a publicly accessible API and entitlements. Not always, sometimes it really is them favouring themselves, but I'd say that's the exception rather than a rule. I'm guessing Apple will mostly do the legwork to create entitlements and APIs and transition the Apple apps rather than actually remove the restriction. This will result in some types of apps that are currently not allowed being possible, but I think it's going to be a lot fewer use cases than people think. For example, I don't see side loaded NES emulators being allowed to have a JIT.
    • cglong 3y ago
      > For example, I don't see side loaded NES emulators being allowed to have a JIT. Why not? If third-party browsers are allowed to have a JIT, why couldn't an emulator?
      • theluketaylor 3y ago
        Apple has a slam dunk case to place a ton of barriers on browser vendors being allowed to JIT code due to the risk to the rest of the platform and the user's data. Little emulators for NES and Sega Genesis are not going to meet those barriers and Apple will have a pretty easy time excluding them under the security provision. Dev environments like VS Code will be more interesting. I suspect Apple will choose to build a VM layer to execute complied code inside an even deeper sandbox rather than allowing execution directly inside the iOS layer, thereby severely limiting what a binary complied on device is able to interact with. This would almost certainly be hidden behind an entitlement that Apple will be try to be allowed to gatekeep under the DMA requirement to maintain platform security.
        • Rinzler89 3y ago
          Samsung already offers virtualizations and containerization via KNOX for you to run apps you don't fully trust safely without disk and shared memory access, on their midrange phones. Surely Apple being wealthier and selling higher priced phones, with even more powerful SoCs can definitely offer similar security functionality for non-IOS appstores. The reason they aren't is they want to push the security boogieman scaremongering to defend their monopoly.
        • nox101 3y ago
          By every measure (go read and told up the CVEs), Chrome has a better security track record than Safari. That means by not allowing users to use Chrome (or a Chromium variant), Apple is forcing users to use a less secure browser and a less secure JavaScript and less secure JIT.
    • CogitoCogito 3y ago
      By what possible reasoning would the DMA forbid things in the phone that have always been standard on all major computer operating systems as well as with Android? It’s pretty clear the DMA does not intend for such specious security arguments to allow Apple to avoid the obligation to open up their platform in th EU.
      • Kon-Peki 3y ago
        You can read the DMA yourself. In fact, you should read the DMA yourself and not rely on what EC commissioners say on their social media accounts. The EU court of justice can and will throw their rulings and fines out the window when (not if) they overstep their authority to score popularity points. If Apple were to create an OS from scratch tomorrow, and that OS was subject to the DMA on day 1, they probably would not be allowed to do many of the things that Apple does in iOS. But the DMA can never apply to an OS on day 1 and the DMA cannot force Apple to roll back many of their security features once an OS becomes subject to the DMA. It’s all in the text of the DMA. Read it.
      • gmueckl 3y ago
        There is a provision in the act that gatekeepers can still restrict access if it that required to maintain the platform's security. If Apple will continue blocking on device compilation and other app functionality, they may well have their interpretation of what is and isn't a security measure tested in court. If there are competent lawyers involved, it will likely come down to the question of which rules are technically meaningful vs. present only to stifle competition.
        • CogitoCogito 3y ago
          But it obviously isn’t required to maintain security of the platform. Apple manages to run MacOS in a more open fashion. Is the argument that MacOS is illegally insecure or something? If the enforcers of the DMA allow a company to simply build their security policy in a way to avoid the rules enforcing the opening of the platform, then what’s the point of the DMA in the first place? Honestly I don’t think Apple will talk their way out of this. EU regulators seem to be much less forgiving of such shenanigans. It’s obvious the point of the DMA is for Apple to open up their platform. That said only time we’ll tell how this plays out.
    • OatmealDome 3y ago
      fwiw, I submitted a DMA interoperability request for JIT access on non-browser apps. Apple denied it on the grounds that it doesn't fall under Article 6(7) for "multiple reasons". One such reason they gave is that JIT is only used for web browsers on iOS.
      • int_19h 3y ago
        Sounds like all you need to do is write a web browser that just so happens to include an emulator...
    • hamandcheese 3y ago
      What is it about JIT that makes it more risky than running non-JIT code?
• trws 3y ago
  This is all technically true, but an IDE that cannot compile and run the code on the local device is missing something. The prohibition on JIT or otherwise compiling on device and running the result is a big blocker for a lot of true native dev experiences. I say this as someone who really mostly likes the App Store, but who would really like to be able to compile some code or run a VM with decent efficiency.
  • dwaite 3y ago
    Sure, but does side-loading or alternate app stores of notorized apps mean that you'll be able to ship arbitrary JIT-enabled apps and apps which allow arbitrary execution of downloaded native binaries?
    • trws 3y ago
      Yes. That’s the point. Edit: that’s too glib. The restrictions currently aren’t technical, they’re enforced by what is and isn’t allowed in the App Store. It’s perfectly possible to build the software on iOS today, you just can’t distribute it within apple’s rules
      • fiddlerwoaroof 3y ago
        Not a JIT, iirc: from what I understand, without a specific JIT entitlement only Apple can give an app, it’s impossible to mark a memory page writable, write code to it and then mark it executable and run the code. This is a core security feature of the operating system.
        • trws 3y ago
          That’s correct AFAIK, but assumes a specific kind of JIT. It’s entirely possible for a JIT compiler to produce shared libraries (dyld files in this case) which are then loaded into the process with dlopen. It’s slower to produce a compiled function or module this way, but we actually do it in practice to allow use of compilers that aren’t traditional JIT compilers or to work around similar selinux policies. This means something like luajit wouldn’t work out of the box, but a single-pass JIT binary translation like Rosetta would work fine. Same thing for a JIT like that used in Julia IIRC.