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)
> "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).
> 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.
Mostly just having to compile for an additional architecture, and a few new bugs to chase down due having to develop cross-arch.
If your code is all in a high level language and your libraries are ported (a big if) then it won't be a huge burden but if you're relying n dynamic code generation or self-modifying code or some arch-specific hacks or the like you may have a lot more trouble.
m12k|5 years ago
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|5 years ago
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).
skummetmaelk|5 years ago
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.
eterps|5 years ago
nutjob2|5 years ago
If your code is all in a high level language and your libraries are ported (a big if) then it won't be a huge burden but if you're relying n dynamic code generation or self-modifying code or some arch-specific hacks or the like you may have a lot more trouble.
jpambrun|5 years ago