Hacker News Reader

Comment by heisenbit | Hacker News Reader

"It is striking that developers no longer send the final binaries when submitting an app, but a bit code. This bit code is then used by Apple to convert the application to the specific platform. Which means that Apple can easily make the transition to a different instruction set, for example, switching from x86 to ARM without all apps need to be resubmitted. It is probably also one of the reasons why legacy applications have recently been removed from the App Store."

I guess this is somehow related to the LLVM toolchain. Is now intermediate code submitted and Apple really generates the final one? Can anyone elaborate how this works and how realistic this it is that Apple would generate two/fat binaries?

View on HN

Having spoken to an LLVM developer about this, unfortunately it isn't quite true (as he understood it).

Essentially, developers submit the LLVM intermediate representation to the App Store. This means that chip-specific optimisations can be made by Apple (such as expanding the number of registers used, or swapping a few small operations for one slightly bigger instruction), however the LLVM IR is already architecture specific, so a change from x86 to ARM would require re-compilation from source.

You assuming Apple doesn't have their own architecture neutral fork.

LLVM used by Apple isn't 100% like the open source project.

Source?

Experience, Apple official compilers aren't 100% equal to what you can download from llvm.org.

For example the set of available optimisation passes, or for a long time not all Objective-C features were available on on the public clang one.

It has been said that the LLVM bitcode is too low-level and architecture-specific to allow switching between x86 and arm for the final compilation pass that Apple performs in the app store. It's more likely this feature is here to enable hotfixing compiler bugs and micro-optimizations and perhaps taking advantage of new features in new chips within a given architecture.

additional: bitcofe is not used for macOS apps, making this irrelevant.

> It is striking that developers no longer send the final binaries when submitting an app, but a bit code

This bit is very expected, along with Arm architecture. It makes sense for Apple to lock down entire ecosystem. It is also terrible if you use Mac to develop anything except iOS/Mac apps, which is what I do. No more windows and half working Linux is not what I need. How long before you can't even compile Obj C or Swift code without going trough app store route?

I don't know if they will do all the steps in a few days or years but I know they will. Also not sure if it will backfire because people need occasional Windows app to run, I suspect huge majority won't care at all.

Lenovo, I know you think I neglected you but I am starting to look your way once again.

Given there are extremely high barriers that are preventing an ARM Mac and very little reason to do it, lets hold off on declaring the Mac dead until they actually do something.

I didn't declare it dead, far from that, it can only grow for the Mac only user population. I said the direction it is going for years does get further from what I need, year over year.

Can you please elaborate what are 'high barriers'?

'Very little reason' - really?

This is the trend of mobile OSes catching up with mainframes.

I guess everyone knows about Android, and on Windows case at least for .NET, version 8.x introduced AOT compilation to native code on the store, which was then improved to .NET Natt in 10.

One day we will have mainframes on our pockets. :)

Reply on news.ycombinator.com