How to See Which Mac Apps Will Stop Working After macOS Golden Gate

[bpb]

I'm not that rich to have two macs. And I didn't know that was an issue until now. They should have released a stable version of xcode 26 that is compatible with macos 27 beta. Anyway, it seems Apple at least provided a solution. I used xcode cloud in the end to ship new version of my app. They give 60 minutes of free xcode cloud compute per month. Seems enough for me, updating my app once per week. Each build takes 6-7 mins on their cloud device.

You don't need two macs. You can run the beta in a virtual machine or you can dual boot. That way your main machine is safe.

It's a pretty long-standing truism that you don't run a beta OS on your main production/development computer.

 

[bpb]

Umm

No

You can run multiple versions on the same machine

You are correct. The main point still stands... don't run a beta OS as your main development machine. As the original poster found out.. it will not work.

 

[visualseed]

I don’t see why Apple should have to maintain legacy code for those sorts of edge cases

Any posix compliant command line utility shouldn’t have an issue anyway

POSIX compliance has nothing to do with CPU instruction sets, nor does it relate to commercial or enterprise software beyond basic included operating system utilities. What might seem like edge cases to you are actually the reason Macs can be purchased and used in a lot of enterprises, government, and research fields. I wouldn’t go so far as to call code that runs on the majority of computers sold today, tomorrow, and for the next decade “legacy” just because Apple decided to make it incompatible.

 

[hagar]

Im an app developer and I’m basically unable to upload new update for my app to app store connect after new macos 27 update. It doesnt accept app binary from xcode 27 beta and if I use xcode 26 to compile, it still doesnt allow because my os version natively blocks xcode 26. I run it from terminal to compile but app store connect still somehow understands that im on incompatible os version. Only option seems to be xcode cloud which i dont want to share my code on github even if its private repo. So what to do? Am i supposed to wait until september to distribute new version of my app? Lol apple.

Why do you have a macOS 27 beta on a production machine? That’s on you. Not Apple.

And good for them for blocking App Store updates from beta dev software.

 

[whelmedjedi]

Why do you have a macOS 27 beta on a production machine? That’s on you. Not Apple.

And good for them for blocking App Store updates from beta dev software.

? macos beta is their software. xcode 26 or xcode 27 beta is their software. they know these are not malware. they could make their software be able to manage these things. WE SUPPOSED TO INSTALL BETA SO WE CAN TAKE ADVANTAGE OF APPLYING NEW FEATURES UNTIL SEPTEMBER! WE SUPPOSED TO INSTALL BETA OS. And not everyone has to have 2 macs or a mac with 500gb+ ssd to install a vm on their machine. Apple dont care these things because of people like you. now take your disagree and go to somewhere else.

 

[bpb]

? macos beta is their software. xcode 26 or xcode 27 beta is their software. they know these are not malware. they could make their software be able to manage these things. WE SUPPOSED TO INSTALL BETA SO WE CAN TAKE ADVANTAGE OF APPLYING NEW FEATURES UNTIL SEPTEMBER! WE SUPPOSED TO INSTALL BETA OS. And not everyone has to have 2 macs or a mac with 500gb+ ssd to install a vm on their machine. Apple dont care these things because of people like you. now take your disagree and go to somewhere else.

You don't need a 500GB SSD to install a VM.

Multiple people have told you what you did wrong, why it was wrong, and more than one viable solution. And yet you keep digging in as if you're not the one who shot yourself in your own foot.

I hate to tell you this.. but you're terrible at your job. A software developer should know better. Sit back, take a break, think it over a little, then really apply yourself and I'm sure it will get better.

In the mean time. Revert to macOS 26, download UTM (it's free) and install macOS 27 beta on it. You can do it. I have faith in you.

Edited to add: in your signature you even say you have a Macbook with 512GB SSD. So what the heck is the problem here? I can only conclude that you are trolling us all at this point.

 

[Charlie Bonesx]

You are correct. The main point still stands... don't run a beta OS as your main development machine. As the original poster found out.. it will not work.

It would have been fine to use the same machine if they used a separate container

That’s the whole point.

 

[Charlie Bonesx]

POSIX compliance has nothing to do with CPU instruction sets, nor does it relate to commercial or enterprise software beyond basic included operating system utilities. What might seem like edge cases to you are actually the reason Macs can be purchased and used in a lot of enterprises, government, and research fields. I wouldn’t go so far as to call code that runs on the majority of computers sold today, tomorrow, and for the next decade “legacy” just because Apple decided to make it

POSIX compliance has everything to do with cpu architecture in the sense that if the code is posix compliant, it doesn’t matter what the cpu architecture is. That’s the whole point


None of what you are saying really makes much sense

First you said some CLI utilities that weren’t even made for Mac

Now you are on to enterprise, government and research

Can you give us some examples of the actual software you are talking about?

 

[visualseed]

POSIX compliance has everything to do with cpu architecture in the sense that if the code is posix compliant, it doesn’t matter what the cpu architecture is. That’s the whole point


None of what you are saying really makes much sense

First you said some CLI utilities that weren’t even made for Mac

Now you are on to enterprise, government and research

Can you give us some examples of the actual software you are talking about?

I suspect your confusion stems from a fundamental misunderstanding of what POSIX compliance actually means. You are confusing source code portability with compiled binary execution. That is exactly why your argument falls apart when applied to the real world, where software is procured and deployed at scale in enterprise and government.

Yes, POSIX compliance means source code can theoretically be compiled for any CPU architecture. In business, however, computers do not run on source code. They run on compiled, closed-source, proprietary binaries. If you don't have the source code and the vendor isn't going to recompile it, then POSIX is useless in the small examples of code that retained compliance anyway. For the most part, POSIX compliance has largely been relegated to the open source binares that ship with the OS. Abstraction layers, high level programming languages and their compliers, as well as proprietary API calls pretty much neuter it.

I have clients using older Oracle databases who have built entire workflows around specific CLI tools on the Mac, and Oracle is absolutely not going to upgrade those for Apple Silicon. There is no incentive to upgrade to newer Oracle DBs either. In fact, it would be financially business ending for them to spend hundreds of thousands to millions of dollars on new Oracle licenses and professional services just to upgrade a system that has worked perfectly for years and will continue to do so for many more. I also consult with a government agency utilizing custom licensing managers and a PKI smartcard authentication clients originally ported to Mac by their vendors from WinX86 code. It is currently updated and supported by the vendor, but it will never be rewritten for ARM. Consequently, those Macs will simply be replaced with PCs during the next upgrade cycle instead of with newer Macs as Apple would like.

For bulk signal processing in wireless network deployment planning, I use drop-in math libraries compiled for me by a third-party in 2004. They originally ran on MIPS64, then Alpha, then Itanium, and were eventually cross-compiled for x64. I first used them on Windows XP64, then moved to the Mac in 2007 without so much as a recompile. Raw machine code is great like that. I ported them when OS X first supported 64-bit in 10.5 with a CLI wrapper I built in Ruby, later porting it to Python. The core libraries remain compiled, with no source code available to me or likely anyone else at this point. People retire and die, businesses close, and projects with them. However the code still run perfectly under Rosetta nearly 20 years later, faster than ever.

Mac support in business was low-hanging fruit that did not require massive resources, it simply worked because of the shared architecture. Macs in the enterprise were a joke until the switch to Intel. Now, Apple is actively destroying the very bridge that made them viable. They are once again demanding costly, unnecessary effort from developers to rewrite mission-critical software, aggressively burning their enterprise goodwill for what ultimately amounts to marginal hardware efficiency gains and minuscule, if not negative, revenues. It is remarkably easy for self-proclaimed pundits and Apple fans to be dismissive, but the iPhone halo effect that put the Mac in business would truly not have been possible without x86 support and will likely fade once it is removed.

I did not even touch on my personal use case in home recording, which relies on tens of thousands of dollars in audio plugins collected over decades. Those will not be upgraded, and I am not going to repurchase them even if they were. They function flawlessly, and it would be cheaper to buy a new PC to continue using them since they were always cross-platform... or were.

Of course, you will likely dismiss all of this as "legacy code" or an "edge case." But the longer you work in tech, the more you realize that unless you are strictly using the same dozen or so mainstream applications, everything is an edge case and legacy code is simply the code that lets you sleep at night because it actually works.

 

[bpb]

For bulk signal processing in wireless network deployment planning, I use drop-in math libraries compiled for me by a third-party in 2004. They originally ran on MIPS64, then Alpha, then Itanium, and were eventually cross-compiled for x64. I first used them on Windows XP64, then moved to the Mac in 2007 without so much as a recompile. Raw machine code is great like that. I ported them when OS X first supported 64-bit in 10.5 with a CLI wrapper I built in Ruby, later porting it to Python. The core libraries remain compiled, with no source code available to me or likely anyone else at this point. People retire and die, businesses close, and projects with them. However the code still run perfectly under Rosetta nearly 20 years later, faster than ever.

I'm gonna skip over the rest of your post but this I can't let pass. There is no universe I've ever worked in in which a library that was compiled for windows x64 will work without a recompile on an intel mac. The file formats are not compatible, regardless of the similarity of the CPUs.

 

[Charlie Bonesx]

I suspect your confusion stems from a fundamental misunderstanding of what POSIX compliance actually means. You are confusing source code portability with compiled binary execution. That is exactly why your argument falls apart when applied to the real world, where software is procured and deployed at scale in enterprise and government.

Yes, POSIX compliance means source code can theoretically be compiled for any CPU architecture. In business, however, computers do not run on source code. They run on compiled, closed-source, proprietary binaries. If you don't have the source code and the vendor isn't going to recompile it, then POSIX is useless in the small examples of code that retained compliance anyway. For the most part, POSIX compliance has largely been relegated to the open source binares that ship with the OS. Abstraction layers, high level programming languages and their compliers, as well as proprietary API calls pretty much neuter it.

I have clients using older Oracle databases who have built entire workflows around specific CLI tools on the Mac, and Oracle is absolutely not going to upgrade those for Apple Silicon. There is no incentive to upgrade to newer Oracle DBs either. In fact, it would be financially business ending for them to spend hundreds of thousands to millions of dollars on new Oracle licenses and professional services just to upgrade a system that has worked perfectly for years and will continue to do so for many more. I also consult with a government agency utilizing custom licensing managers and a PKI smartcard authentication clients originally ported to Mac by their vendors from WinX86 code. It is currently updated and supported by the vendor, but it will never be rewritten for ARM. Consequently, those Macs will simply be replaced with PCs during the next upgrade cycle instead of with newer Macs as Apple would like.

For bulk signal processing in wireless network deployment planning, I use drop-in math libraries compiled for me by a third-party in 2004. They originally ran on MIPS64, then Alpha, then Itanium, and were eventually cross-compiled for x64. I first used them on Windows XP64, then moved to the Mac in 2007 without so much as a recompile. Raw machine code is great like that. I ported them when OS X first supported 64-bit in 10.5 with a CLI wrapper I built in Ruby, later porting it to Python. The core libraries remain compiled, with no source code available to me or likely anyone else at this point. People retire and die, businesses close, and projects with them. However the code still run perfectly under Rosetta nearly 20 years later, faster than ever.

Mac support in business was low-hanging fruit that did not require massive resources, it simply worked because of the shared architecture. Macs in the enterprise were a joke until the switch to Intel. Now, Apple is actively destroying the very bridge that made them viable. They are once again demanding costly, unnecessary effort from developers to rewrite mission-critical software, aggressively burning their enterprise goodwill for what ultimately amounts to marginal hardware efficiency gains and minuscule, if not negative, revenues. It is remarkably easy for self-proclaimed pundits and Apple fans to be dismissive, but the iPhone halo effect that put the Mac in business would truly not have been possible without x86 support and will likely fade once it is removed.

I did not even touch on my personal use case in home recording, which relies on tens of thousands of dollars in audio plugins collected over decades. Those will not be upgraded, and I am not going to repurchase them even if they were. They function flawlessly, and it would be cheaper to buy a new PC to continue using them since they were always cross-platform... or were.

Of course, you will likely dismiss all of this as "legacy code" or an "edge case." But the longer you work in tech, the more you realize that unless you are strictly using the same dozen or so mainstream applications, everything is an edge case and legacy code is simply the code that lets you sleep at night because it actually works.

I am not confused at all and do understand exactly how all of these things work

Yes, of course if you want to run already compiled x86 code you won’t be able to do that on an Apple silicon Mac running macOS 28 or later

We’ve known this is coming for pretty much exactly 6 years

That’s plenty of time to come up with a new plan for any use case, whether that’s recompiling code or resisting the future and moving to a different x86 os

Of course moving to x86 made Apple more viable for enterprise, but it’s over now, like it or not

ultimately everything is going to move from cisc to risc. Apple is just ahead of the curbe. Everyone would do themselves a favour by planning for this

As far as audio plugins go, your studio rig isn’t going to just stop working, no need to purchase a new pc, just use whatever machine you are using

 

[visualseed]

I'm gonna skip over the rest of your post but this I can't let pass. There is no universe I've ever worked in in which a library that was compiled for windows x64 will work without a recompile on an intel mac. The file formats are not compatible, regardless of the similarity of the CPUs.

A pure math library does not make system calls. It does not draw windows, and it does not need to talk to the macOS kernel or the Windows subsystem. It takes inputs in registers, crunches numbers on the CPU, and returns a result. Because it is pure x64 machine code, you can completely bypass the OS loader.

Using FFI (originally DL) in Ruby or ctypes in Python, you simply allocate a block of memory using mmap, explicitly flag that memory page as executable to bypass W^X/DEP protections, load the raw x64 opcodes into it, cast it as a function pointer, and tell the CPU to execute it. Then you read your results back from memory. The processor does not care what operating system is running or what the original file extension was. x64 machine code is x64 machine code.

The only cross-platform variable is the ABI (Application Binary Interface). Windows and macOS pass arguments using different hardware registers. As long as your wrapper explicitly maps the inputs to the Microsoft x64 calling convention before jumping to the execution pointer, it works flawlessly. It just requires a flat, unwrapped x64 assembly build with little-endian byte ordering. Neat, tidy, and incredibly fast.

I believe Clang can handle generating flat binaries today, but 23 years ago that was not a viable option, so it was written in pure assembly. This is still the preferred methodology for many FinTech vendors and HFT firms to quickly hot-swap trading algorithms in memory and access high-speed parallel processing with AVX-512 natively on the CPU. It is not exactly the same use case, but it relies on the exact same toolchain and hardware-level execution.

The sloppy way to do this today is to take a library compiled as a Windows .dll and call it via Wine Console on the Mac or Linux. I avoid that because of the unnecessary overhead and dependencies. More importantly, it strips away my direct control over memory allocation, which is needed when processing massive datasets.

 

[Charlie Bonesx]

A pure math library does not make system calls. It does not draw windows, and it does not need to talk to the macOS kernel or the Windows subsystem. It takes inputs in registers, crunches numbers on the CPU, and returns a result. Because it is pure x64 machine code, you can completely bypass the OS loader.

Using FFI (originally DL) in Ruby or ctypes in Python, you simply allocate a block of memory using mmap, explicitly flag that memory page as executable to bypass W^X/DEP protections, load the raw x64 opcodes into it, cast it as a function pointer, and tell the CPU to execute it. Then you read your results back from memory. The processor does not care what operating system is running or what the original file extension was. x64 machine code is x64 machine code.

The only cross-platform variable is the ABI (Application Binary Interface). Windows and macOS pass arguments using different hardware registers. As long as your wrapper explicitly maps the inputs to the Microsoft x64 calling convention before jumping to the execution pointer, it works flawlessly. It just requires a flat, unwrapped x64 assembly build with little-endian byte ordering. Neat, tidy, and incredibly fast.

I believe Clang can handle generating flat binaries today, but 23 years ago that was not a viable option, so it was written in pure assembly. This is still the preferred methodology for many FinTech vendors and HFT firms to quickly hot-swap trading algorithms in memory and access high-speed parallel processing with AVX-512 natively on the CPU. It is not exactly the same use case, but it relies on the exact same toolchain and hardware-level execution.

The sloppy way to do this today is to take a library compiled as a Windows .dll and call it via Wine Console on the Mac or Linux. I avoid that because of the unnecessary overhead and dependencies. More importantly, it strips away my direct control over memory allocation, which is needed when processing massive datasets.

System calls are still happening. mmap and mprotect are kernel calls, so this bypasses the loader specifically

The W^X framing also throws things off a bit. Marking a page executable via mprotect isn't bypassing the protection, it's using the mechanism exactly as intended. On a hardened Apple Silicon process it will actually get blocked without the JIT entitlement, so the OS still effects what’s happening

Shadow space, stack alignment, how large structs get returned and which registers need to be preserved across calls also matter. If the shadow space is wrong you can get silent memory corruption with no obvious cause. Calling that "the only variable" undersells it considerably

The AVX-512 point is an Intel thing. AMD Zen 2 doesn't have it, Zen 3 support is partial, and Apple Silicon doesn't touch it at all. So "runs natively on the CPU" depends heavily on which CPU is being targeted.

The HFT comparison is a bit off. Those firms are doing this for nanosecond-level latency with kernel bypass networking and CPU pinning, and the in-memory hot-swap piece is almost incidental to why they would care about the toolchain.

 

[Kashifnawaz85]

Apple way of planned obsolescence.

 

[gorbag42]

Someday someone will create an OS that builds upon itself instead of abandoning itself.

I understand z/OS will still run os/360 code.

 

[visualseed]

System calls are still happening. mmap and mprotect are kernel calls, so this bypasses the loader specifically

The W^X framing also throws things off a bit. Marking a page executable via mprotect isn't bypassing the protection, it's using the mechanism exactly as intended. On a hardened Apple Silicon process it will actually get blocked without the JIT entitlement, so the OS still effects what’s happening

Shadow space, stack alignment, how large structs get returned and which registers need to be preserved across calls also matter. If the shadow space is wrong you can get silent memory corruption with no obvious cause. Calling that "the only variable" undersells it considerably

The AVX-512 point is an Intel thing. AMD Zen 2 doesn't have it, Zen 3 support is partial, and Apple Silicon doesn't touch it at all. So "runs natively on the CPU" depends heavily on which CPU is being targeted.

The HFT comparison is a bit off. Those firms are doing this for nanosecond-level latency with kernel bypass networking and CPU pinning, and the in-memory hot-swap piece is almost incidental to why they would care about the toolchain.

I am obviously also running the Python wrapper as an x86 process under Rosetta to maintain the execution environment, and my machine code is SSE, so everything is kosher. While Rosetta translates full x86 binaries ahead of time, its JIT compiler steps in to do the heavy lifting for dynamically mapped memory. It seamlessly catches the injected x86 opcodes at runtime and translates them to ARM on the fly. MacOS and Rosetta do such an exceptional job translating Intel instructions that it genuinely amazes me how hard you can beat on it before you get any indication at all that you are not on a real Intel CPU.

 

[briloronmacrumo]

Hope Intuit's Turbo Tax will be updated to run native Apple Silicon. Currently it relies on Rosetta 2

 

[dwaite]

I have heard this idea elsewhere, that post-apocalypse a user can manually install Rosetta 2 and just keep on keepin' on with Intel apps. Is this idea supported by any statements from Apple, or is this just hoping against hope?

It is just hope. There is no indication that there will be anything for that Rosetta 2 installer to hook into at the system level in macOS 28, or for that matter that future Apple silicon will have the same custom instructions and processing modes needed for current Rosetta 2 to work.

I believe they did talk this year about intentions to keep the Game Porting Toolkit continuing to work, including modified Rosetta 2 support, during the WWDC videos last week. I haven't watched yet though.

 

[dwaite]

The version of Debian Linux before the current one is the last main distribution with 32 bit support. The old hardware is now firmly in the "retro computing" category.

Even if it isn't "business interests and priorities", eventually even for open source there's nobody willing to put in the time to keep the old hardware builds patched and running, or to make sure there's infrastructure for things like CI to run against.

 

[dwaite]

Why would I develop any game for Mac when Apple can just nullify all of my work/cost every few years? (OSX, PPC, 32-bit, Intel) Apple assumes all software are developed forever. That’s not how the game industry works.

Are you saying you want to keep selling a game past when you are willing to provide customer support?

 

[whelmedjedi]

You don't need a 500GB SSD to install a VM.

Multiple people have told you what you did wrong, why it was wrong, and more than one viable solution. And yet you keep digging in as if you're not the one who shot yourself in your own foot.

I hate to tell you this.. but you're terrible at your job. A software developer should know better. Sit back, take a break, think it over a little, then really apply yourself and I'm sure it will get better.

In the mean time. Revert to macOS 26, download UTM (it's free) and install macOS 27 beta on it. You can do it. I have faith in you.

Edited to add: in your signature you even say you have a Macbook with 512GB SSD. So what the heck is the problem here? I can only conclude that you are trolling us all at this point.

are you having problems understanding me? i already told i have solved the problem using xcode cloud. then you took my first message and quoted. you should take a break and sit back. have a coffee. then hopefully dont waste my time more.

 

[coolfactor]

WINE might have a similar fate...

Yup, I install WINE via Homebrew and have been getting this "deprecation" warning for months now. But it says that support is ending THIS September. I hope they fix that, as Apple seems to have extended the deadline by a full year.

I use WINE to run a basic Windows app, so this isn't just about outdated Mac apps. Some of us are using actual Intel apps where there is no native Mac equivalent. What a shame they are dropping support entirely.

 

[coolfactor]

Why would I develop any game for Mac when Apple can just nullify all of my work/cost every few years? (OSX, PPC, 32-bit, Intel) Apple assumes all software are developed forever. That’s not how the game industry works.

Doesn't Xcode give you the option to rebuild your app for the latest platform with a few clicks?

 

[jent]

Im an app developer and I’m basically unable to upload new update for my app to app store connect after new macos 27 update. It doesnt accept app binary from xcode 27 beta and if I use xcode 26 to compile, it still doesnt allow because my os version natively blocks xcode 26. I run it from terminal to compile but app store connect still somehow understands that im on incompatible os version. Only option seems to be xcode cloud which i dont want to share my code on github even if its private repo. So what to do? Am i supposed to wait until september to distribute new version of my app? Lol apple.

If you email the Apple Developer support team, what do they suggest? Genuine question, not snark.

 

[andreagrandi]

There is no such "Intel-Based apps" in General -> About 🤷🏻‍♂️ (and I'm using Tahoe 26.5)