Apple Silicon Native Support For CarbonAPI

Hi all,

I'm working on migrating a legacy codebase to run natively on Apple Silicon macOS. The project builds and runs fine on Rosetta, but anytime I try to build it for Apple Silicon I get build errors from referencing CarbonAPI.

Is it possible to resolve these issues and get CarbonAPI to build natively for Apple Silicon, or will I have to rewrite the offending pieces of code?

Thanks!

Accepted Reply

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).

Replies

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).