Not just that - but the many, many legacy apps professionals rely on. The 64-bit move already decimated the professional audio space. The cynic in me can't help but see this as a move towards pure consumer device. As a development machine it will be all but useless as you find things that won't compile or work correctly on the new CPU arch.
I mean, I suppose it depends on what sort of development you're doing, but in 2020 most libraries do work on ARM. There'll no doubt be a painful period (as there was with the death of PPC), but it shouldn't be that dramatic.
I'm not a developer so forgive my ignorance, but isn't this what cross-compiling is for? I get that compiling natively can increase performance and find obscure hardware issues, but it's my understanding that, for example, ARM builds of GNU/Linux binaries are just cross-compiled by server farms that are also natively compiling the AMD64 builds.
Also, fat binaries and JIT emulation have been a thing forever, especially for Apple who has dealt with these changes twice now (68k -> PPC -> x86-64).
I just don't see this being any different than current multi-platform efforts like Debian, NetBSD, etc., except it's a for-profit company with billions of dollars and thousands of expert employees behind it.
I recently committed a change to FreeBSD's kernel (written in C) which I'd tested on amd64 and x86. Much to my surprise, when I did the cross-build for all platforms, I had a compile-time assert fail on 32-bit arm because the size of a struct was too large. It turns out that 32-bit arm (at least on FreeBSD) naturally aligns 8 byte data types to 8 byte boundaries, whereas x86 packs them and allows them to straddle the 8 byte boundary. This left a 4-byte hole in my struct, and caused it to be 4 byte too large.
These are the sorts of things that bite you when moving from x86/x86_64 to a risc platform, even when its the same endian.
https://www.realworldtech.com/forum/?threadid=183440&curpost...
Granted, the move to ARM is a bit more work, but again I don't think anyone should be especially surprised by it. As soon as the "A" processors started posting real, positive benchmark numbers I figured that Apple would move to them and away from Intel. In my minds eye I can see Apple differentiating machines depending on how many ARM chips it has. MacBook Air - 2 A15; MacBook - 4 A15X; MacBook Pro - 12 A15X; Mac - 128 A16X (or something like that)
A lack of sympathy does not make my audio software work, however. And I believe what parent is driving at is that should the ARM transition take place, even more stuff isn't going to work for the end-user. So a little empathy for the user, eh?
When I hear that some group (ie. pro audio software makers) won't update their offerings I have to believe it's because they don't want to or they just don't want to serve the market anymore. In either case it seems like there is an opportunity for someone to create an alternative, and possibly make some great money.
The problem with the 32->64 transition (or x86->ARM) doesn't lie with active businesses failing to "get with the program" and update their software - it lies with abandonware. With software that's been put out either by defunct companies or sometimes literally deceased programmers.
In some niches, this sort of stuff is really, really common - generally this is the case if there's a really stable API for building things, like VST plugins, and if the niche in question has a lot of failed businesses. A lot of times in the pro audio space, a musician will spend a large part of their career "collecting" a ton of little one-off sound libraries and fx plugins, because these are the only way they can get the computer to produce that exact kind of sound they're looking for. This collection slowly builds up over the course of, say, a decade - just like a graphic designer would collect fonts.
The difference is that unlike fonts, which last had their "greet the reaper" moment back when bitmap fonts got scrapped in the mid-90s (despite OpenType becoming a thing, TrueType fonts from the 90s still work fine, some 30 years later), any audio plugins that aren't compatible with the cpu architecture die out. And that's just really brutal to a working musician.
You can't get an update to most of those because there's a ton of attrition in that industry; lots of small-time plugin makers realize pretty fast that it's a very difficult place to make any kind of ROI, so they quit after a few years.
--
Games are in a really similar place - they're a business slaughterhouse where most companies that attempt to make something discover they're not going to cover the initial investment, so after the game's produced it typically gets a couple of years of barebones support, and then gets abandoned - or the company just croaks. Any kind of rewrite is completely out of the question. The tragedy is that most of these games are pretty good and fun, they're just not economically viable.
I love apple moving the tech forward, but we desperately need a better emulation solution, and/or we've got to get the industry off of coding for bare metal.
There are very few creators who actually create the things they rely on to create, ultimately we are all consumers even inside our professions. And like any consumer, we are all at the mercy of a market we don’t control. Either you have to accept that everything must come to an end and plan for that eventual end, or you have to dig deeper into your creativity.
Everyone has something they rely on that will disappear before they’re ready to lose it. It’s a reality of life and as much as humankind has experienced that loss for thousands of years, we never seem to get any better at accepting it or planning for it.
...was slow.
Every architecture switch has casualties, what I feel might be shortsighted by Apple this time is the x86 Cocoa apps that die this time are not going to be replaced by Catalyst iPad ports or ARM builds, they'll be replaced with Electron apps.
At least both architectures are 64 bit little endian, so all those buggy C programs that do illegal type casting might still work.
One issue might be that X86 is pretty relaxed when it comes to unaligned memory accesses. I'm not sure how ARM64 handles it.
Anything external will suffer, and apple probably aren't gonna cry about that.