[m12k]

Mostly, it means apps will need to be re-compiled for the new CPU architecture. For a while now, apps uploaded to the Mac App store are uploaded in an intermediate representation, so the final compilation to the specific architecture happens on Apple's servers. This puts Apple in a place where they can launch a new computer with an ARM CPU, and (ideally) all apps on the Mac App Store will "just work"TM out of the box. And they can know whether that will be the case before the launch, maybe even reach out to developers to solve issues ahead of time.

So the biggest potential problem will be for of apps outside the app store. Developers will need to re-compile their apps themselves - I hope this will be possible with cross-compilation, so it's not necessary to get a new mac in order to do so (that would severely limit how many devs would do so). Maybe the norm will be 'fat binaries' like in the PowerPC->Intel transition period, where apps ship with binaries compiled for both architectures. Also, apps that haven't been updated for a long time might not receive updates and would get left behind (although switching off 32-bit support in Catalina could be seen as a test run for the same disruption).

Also, any apps that are using specific x86-instructions for optimization might take a while longer to port - e.g game engines (luckily most game engines are cross-platform these days, so Unity, Unreal and the others already have ARM-targets from iOS/Android/Switch to base this on)

[Reason077]

> "Maybe the norm will be 'fat binaries' like in the PowerPC->Intel transition period"

Multi-arch "fat binaries" have been the norm much more recently than that. For a long time, typical macOS binaries supported both 32-bit and 64-bit x86.

Likewise, fat binaries are used to support the various different ARM variants on iOS devices (armv7, arm64, etc).

[Someone]

The first fat binaries on the Mac were 68k-PowerPC.

That time one could also patch 68k OS calls with PPC code and vice versa. Depending on your viewpoint, making that possible, where the 68k OS calls had about 10 different calling conventions (the ABI of some of the callbacks seemed to be chosen by what registers the arguments happened to be in in the first implementation), that was either a can of worms or a brilliant hack.

[skummetmaelk]

> Mostly, it means apps will need to be re-compiled for the new CPU architecture. For a while now, apps uploaded to the Mac App store are uploaded in an intermediate representation, so the final compilation to the specific architecture happens on Apple's servers. This puts Apple in a place where they can launch a new computer with an ARM CPU, and (ideally) all apps on the Mac App Store will "just work"TM out of the box. And they can know whether that will be the case before the launch, maybe even reach out to developers to solve issues ahead of time.

That sounds like an absolute nightmare. Imagine having to track down a bug that only appears after your program has gone through cross compilation on Apple's servers.

[DagAgren]

You wouldn't, you'd compile it yourself at that point.

[eterps]

Which intermediate representation is being used?

[m12k]

Actually, it seems I misremembered, and the bitcode representation is still only used for iOS [1]. Will be interesting to see if that changes with the next release of macOS.

https://www.highcaffeinecontent.com/blog/20190518-Translatin...