34 ms·

I'm pretty convinced Apple's transition strategy for existing software will be "Recompile, retest, republish": No built-in emulation or other support for x64 b

by jmull 6y ago

I'm pretty convinced Apple's transition strategy for existing software will be "Recompile, retest, republish": No built-in emulation or other support for x64 binaries. In the past transitions they had to have a strong compatibility story. But I think that's not nearly as important anymore. For software that is being actively developed, releasing fat ARM/x64 (or maybe fat bitcode/x64) binaries can be worked into a release over the upcoming months. Software that is not being actively released... was pretty much mostly kicked to the side of the road due to the completion of the transition to x64 (if not sooner -- death by a thousand small transition cuts). There will certainly be casualties to this approach, but I'm guessing Apple will prefer to reap the benefits of a much simpler and straight-forward transition. They may also see it as no great loss. E.g., software that is no longer being recompiled is also no longer receiving security updates. If this happens, the big kicker will be dependencies. Your hyper-maintained, always-updated app will probably contain at least a few dependencies that stopped moving a long time ago, and you'll be forced to find alternatives. Also: x64 emulation (slow though it will be) will happen in any case. But from third parties. VMWare Fusion, etc. I think there will probably be a market for some kind of x64 container that "shrink-wraps" an x64 app or library with an emulation core as an alternative when recompiling can't happen (there's a lot of existing tech to build this on top of, so I think it will come pretty quick -- actually, in different forms for different migration scenarios. Because of the performance/resource penalty, you'll want to wrap as little as possible) edit: I meant to add: It will be funny to come back to this after Apple's ARM announcements and see how bad (or good?) my speculations are...

whywhywhywhy 6y ago
> But I think that's not nearly as important anymore I used Macs during Classic to OSX and PPC to Intel transitions but I'd argue it's actually way more important this time. Back during previous transitions fully native apps were really the only option but now... Almost all modern actively developed software on Macs is just electron wrappers Only a few exceptions of actively developed cocoa apps come to mind, Sketch, Omni Group, etc. The other half of the Mac ecosystem is exist outside of electron apps or cocoa good citizens and that's old but essential power user applications the Adobe suite, 3d software, science software and audio software which all have extensive custom Intel code and all the plugin infrastructure runs on Intel. To bring After Effects, for example to ARM is going to be an insane amount of work and a lot of it is going to sit outside of Adobe's control because so much of the application relies on plugins which all have to be recompiled too. I feel Apple might have lost the plot here a bit and has convinced themselves that this functionality vacuum is going to be filled with catalyst iPad ports, reality is if the computer can't run these apps people require for their jobs then they'll just buy windows machines.
- tonyedgecombe 6y ago
  Almost all modern actively developed software on Macs is just electron wrappers Which is exactly what Apple doesn't want to see prospering on its platform.
  - whywhywhywhy 6y ago
    I'd agree 100% but the state of how janky and alien their own Catalyst ports feel don't give me much hope. If they want this platform to remain the world class computing experience they actually have to invest in it fully not just hope that some work can be skimmed off the top of their iPad investment. Where is the example of a best in class 2020 Mac desktop app? Because it certainly isn't News.app.
- nextos 6y ago
  I think also code using x86_64 vectorization (AVX, SSE) is going to be non-trivial to port. Same applies to JITs, which I guess are a lot less mature on ARM due to lack of users at the minute.
- mpweiher 6y ago
  > it's actually way more important this time. How so? All the old legacy apps that nobody wants to (or can) recompile were just jettisoned in the 64 bit transition, as TFA duly noted. "In retrospect, the move to 64-bit software may have been made not just for its own sake, but in contemplation of the ARM transition."
  - whywhywhywhy 6y ago
    32 bit is going back a lot longer, although my machine which I haven't upgraded to Catalina still has a few 32bit applications kicking around on it including one that I was using in my professional work only 6 months ago. Plenty of 64 bit software exists that isn't being updated often or at all anymore.
    - mpweiher 6y ago
petercooper 6y ago
With the App Store, would fat binaries even be needed for the most part? Just upload all the compiled versions to the store and it'll distribute the right one to the right devices. For non-store software, I don't see a big deal in distributing x86 vs ARM builds separately, but that might be the developer in me speaking.
jmull 6y ago
> No built-in emulation or other support for x64 binaries. Well, I got that wrong. Rosetta 2 and some kind of virtualization support (no idea yet what that means)

by jmull 6y ago

whywhywhywhy 6y ago

> But I think that's not nearly as important anymore I used Macs during Classic to OSX and PPC to Intel transitions but I'd argue it's actually way more important this time. Back during previous transitions fully native apps were really the only option but now... Almost all modern actively developed software on Macs is just electron wrappers Only a few exceptions of actively developed cocoa apps come to mind, Sketch, Omni Group, etc. The other half of the Mac ecosystem is exist outside of electron apps or cocoa good citizens and that's old but essential power user applications the Adobe suite, 3d software, science software and audio software which all have extensive custom Intel code and all the plugin infrastructure runs on Intel. To bring After Effects, for example to ARM is going to be an insane amount of work and a lot of it is going to sit outside of Adobe's control because so much of the application relies on plugins which all have to be recompiled too. I feel Apple might have lost the plot here a bit and has convinced themselves that this functionality vacuum is going to be filled with catalyst iPad ports, reality is if the computer can't run these apps people require for their jobs then they'll just buy windows machines.

tonyedgecombe 6y ago
Almost all modern actively developed software on Macs is just electron wrappers Which is exactly what Apple doesn't want to see prospering on its platform.
- whywhywhywhy 6y ago
  I'd agree 100% but the state of how janky and alien their own Catalyst ports feel don't give me much hope. If they want this platform to remain the world class computing experience they actually have to invest in it fully not just hope that some work can be skimmed off the top of their iPad investment. Where is the example of a best in class 2020 Mac desktop app? Because it certainly isn't News.app.
nextos 6y ago
I think also code using x86_64 vectorization (AVX, SSE) is going to be non-trivial to port. Same applies to JITs, which I guess are a lot less mature on ARM due to lack of users at the minute.
mpweiher 6y ago
> it's actually way more important this time. How so? All the old legacy apps that nobody wants to (or can) recompile were just jettisoned in the 64 bit transition, as TFA duly noted. "In retrospect, the move to 64-bit software may have been made not just for its own sake, but in contemplation of the ARM transition."
- whywhywhywhy 6y ago
  32 bit is going back a lot longer, although my machine which I haven't upgraded to Catalina still has a few 32bit applications kicking around on it including one that I was using in my professional work only 6 months ago. Plenty of 64 bit software exists that isn't being updated often or at all anymore.
  - mpweiher 6y ago

petercooper 6y ago

With the App Store, would fat binaries even be needed for the most part? Just upload all the compiled versions to the store and it'll distribute the right one to the right devices. For non-store software, I don't see a big deal in distributing x86 vs ARM builds separately, but that might be the developer in me speaking.

jmull 6y ago

> No built-in emulation or other support for x64 binaries. Well, I got that wrong. Rosetta 2 and some kind of virtualization support (no idea yet what that means)