To answer this we have to be very clear about terminology. Let’s start with some history:
-
macOS 10.5 (yes, 10.5, so circa 2007) introduced support for 64-bit apps.
-
macOS 10.15 is the last release to support 32-bit apps
-
The first Apple silicon machines shipped with macOS 11.
This timeline is important because some Carbon APIs are 32-bit only.
Carbon is an over-arching term for a large suite of APIs that were supported on traditional MacOS and Mac OS X [1]. Carbon APIs range from low-level stuff, like memory and file management, to high-level stuff, like windows and menus. In macOS 10.5 Apple decided not to support Carbon UI primitives — windows, menus, controls, and so on — for 64-bit apps.
This was quite a subtle decision. Numerous Carbon APIs are supported in 64-bit apps. For example, you can still using Carbon’s File Manager API to work with files [2]. What you can’t do is display a UI using Carbon APIs.
Moreover, this isn’t as simple as saying “such and such frameworks aren’t available”. The canonical Carbon UI framework is HIToolbox, and that’s split down the middle. Low-level bits of HIToolbox are available to 64-bit apps, things like the Carbon Event Manager, but high-level bits, like Window Manager, Menu Manager, and Control Manager, are not.
When it comes to Apple silicon, it only runs macOS 11 or later, which only support 64-bit apps, which means that no Carbon UI apps can work. That’s true regardless of whether you use Rosetta or not. However, lower-level Carbon APIs work just fine on Apple silicon. Indeed, there are still some tasks that are only achievable using Carbon APIs [3].
Coming back to your app, you wrote:
The project builds and runs fine on Rosetta, but anytime I try to
build it for Apple silicon I get build errors from referencing
Carbon API.
To offer more input on that I need to know which Carbon API is causing problems. Many of these older APIs have their own deprecation and removal story that’s independent of HIToolbox.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Since then this has been renamed to OS X and then to macOS.
[2] But please stop doing that!
[3] For example, if you’re building a custom text input control and you want to honour the state of secure input, your only option is IsSecureEventInputEnabled
(r. 89142297).