
Educated Guesses on Software Transitioning to macOS on ARM - ingve
https://shapeof.com/archives/2020/6/educated_guesses_about_a_mac_transition_to_arm.html
======
thevagrant
Is it possible that Apple could add the ARM cpu to be a co-processor alongside
x86? Macbook Pro 16 then has an additional powerful processor that devs can
target while remaining compatible with x86. Allows a 4-5 year cycle until x86
gets dropped completely. Perhaps overly complicated and expensive to do this?
I can see small/light machines (Macbook/Macbook Air) would shift to ARM only.

~~~
ksec
The T2 inside MacBook Pros is basically an A10. So it certainly isn't too
expensive to do.

But it certainly is an additional complexity from software perspective.

------
ornxka
Isn't moving to a new instruction set only a problem with proprietary
software? Open source operating systems seem to be able to be ported to new
architectures almost effortlessly, some of them quite old or obscure. It's
true that some programs require modification to be able to run on new
platforms, but the cost of doing that is minimal compared to the cost of
"porting" binary software to new architectures, which is that of simply
rewriting it from scratch. Why is everyone talking about emulation and
coprocessors when the real issue is basically just a matter of source code
availability?

------
new_realist
I would love to see a provisional x86 compatibility layer baked into the
silicon itself.

~~~
throwaway2048
considering that the latest OSX is x86-64 and AVX2 only, that stuff is
patented for decades to come, and its pretty much absolutely 100% Guaranteed
that Intel/AMD will not give Apple a license, for any amount of money Apple
would be willing to pay.

~~~
jki275
x86-64 core patents expire in 2023.

~~~
throwaway2048
Yes, but extension instructions OSX relies on are much newer than that.

------
orionblastar
They better have an emulator to run Intel Mac apps.

~~~
Tagbert
They will probably not need that. Most apps should be able to be recompiled
for Arm with no changes. Only a small number of apps (some audio pipeline apps
for instance) are written so close to the metal that the processor change will
require more work.

~~~
_bxg1
But there are lots of apps that aren't actively maintained, and so will never
get recompiled, even if they could be. And even the ones that are actively
maintained might not be ready and recompiled on day 1. Emulation would go a
long way to make the transition less painful.

~~~
jkestner
Bitcode[1] would’ve been a good way to handle that, if Apple had ever
supported it for Mac apps in addition to their other platforms.

1\. [https://thenextweb.com/apple/2015/06/17/apples-biggest-
devel...](https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-
news-at-wwdc-that-nobodys-talking-about-bitcode/)

~~~
therockhead
I don’t see how that helps apps not in the App Store, as bitcode need to
changed to a platform specific type .... unless this was done on the fly on
the host platform.

~~~
htfu
Apart from a return of the dreaded Win-style endless installer progress bar
surely doing it on the host, once, wouldn't be a problem. The "issue" would be
squaring the result with notarization and bundle integrity, but that solves
itself since it means Apple is already sitting on the (in this case bitcode)
app whether it's in store or not.

But they'd probably use it as an incentive to drive stuff further towards the
app store.

