Isn't carbon api fully deprecated?

[iby]

I was trying to figure out how MASShortcut works and found that it uses InstallEventHandler call. I've read that Carbon API is now fully deprecated and doesn't support 64-bit systems. I assume this eventually will be an issue, Apple also cannot be thrilled about use of deprecated stuff. Can this potentially be a problem? Has anyone ever been warned about using it in App Store?

I also know there are Quartz Event Taps that seem to allow doing the same thing. I wonder why didn't you guys switch to that? Are there any issues with that or is it less reliable or has a limiting functionality?

[shpakovski]

Thank you for the heads up!

I've read that Carbon API is now fully deprecated and doesn't support 64-bit systems.

Could you please be more specific? The API is definitely not deprecated in headers. It would be nice to hear some official quote, but Google does not help 😃 Unofficially Carbon “deprecation” means no new APIs in the future, if I did not miss anything.

[iby]

For starters wikipedia says that:

In 2012, with the release of OS X 10.8 Mountain Lion, most Carbon APIs were considered deprecated. The APIs are still accessible to developers and all Carbon applications will run, but the APIs will no longer be updated.

Apple's Carbon official reference was completely removed last year: https://developer.apple.com/Carbon. Though there's still an official legacy pdf floating around with "retired" messages all over it.

I'm trying to figure out this myself, but I'm mostly interested why people don't use Quartz instead. It seems like it's the way forward, but with Apple's documentation it's hard to tell… Any reasons? :confused:

[zoul]

Until the APIs are officially marked as deprecated, there’s nothing wrong with using them. Even if they get deprecated, I think you can still submit apps using them to the App Store. Besides, I think the Carbon stuff is only used when executing shortcut actions, and that code is quite cleanly factored into separate classes, so it should be trivial to replace if needed.

I think I even tried to replace the Carbon stuff when I was rewriting the code, but I in the end I decided to stick with Carbon. I can’t remember the exact reason – probably the main catch is that having a system-wide event tap for keyboard events required some extra permissions to run?

To make long story short, I don’t think Carbon is a problem. As for the App Store, I have a production app that uses MASShortcut in the store with no signs of trouble.

[iby]

Makes sense. So, are you saying that using Carbon directly doesn't require access for assistive devices is enabled? I just read literally a few minutes ago that it does like CGEventTapCreate, but wasn't sure how legitimate the information was. That would be a big reason to use it over Quartz.

[zoul]

I have just found this note in the official docs:

Event taps receive key up and key down events if one of the following conditions is true: a) The current process is running as the root user. b) Access for assistive devices is enabled. In OS X v10.4, you can enable this feature using System Preferences, Universal Access panel, Keyboard view.

So yes, that’s a big plus for the (ugly) Carbon API.

[shpakovski]

Thank you Tomáš, very good to know!

[iby]

Awesome. Thanks a lot for clarifying those things!

[zoul]

Happy to help!

[iby]

So, I've given that a good try, and here's what I've figured, in case anyone wonders. Apparently, access for assistive devices is not required only for EventHotKeyPressed event kind when using InstallEventHandler. Other events, like EventRawKeyDown or EventRawKeyUp, will not work. Frankly, even with access enabled (AXIsProcessTrustedWithOptions(…) returns true) other keyboard events still didn't work, which is a little strange. Maybe something in the way I compiled the app prevented that.

This made me thinking security wtf if I can just assign hotkeys for the entire ASCII and ASCII + Shift. Turns out the event get's blocked after being caught and nothings gets typed in inputs. Smart.