Enable extension-safe API

[macguru]

The framework could currently not be used in app extensions without generating a warning like this:

Linking against a dylib which is not safe for use in application extensions: …/ShortcutRecorder_-3ED30F3B125105E_PackageProduct.framework/ShortcutRecorder_-3ED30F3B125105E_PackageProduct

Since no non-extension-safe API is being used, enabling this flag clears the warning but requires no other changes.

Also enables the recommended QUOTED_INCLUDE_IN_FRAMEWORK_HEADER build setting, which also requires no other changes.

[macguru]

I also removed some dead code that Xcode warned about and fixed a return value for the same reason.

[Kentzo]

What parts of API were you able to verify to work inside an extension?

[macguru]

What parts of API were you able to verify to work inside an extension?

Linking the library to a framework instead of an app will also generate the warning. We were able to verify that an app can use the library just fine if it's not linking directly but inside a framework. The framework is using inside extensions that may use code to unarchive shortcuts from a persistent file, but we haven't tested that.

[Kentzo]

Do I understand correctly that you do no use any of the SR API inside your extension? I'm trying to understand the use case so I can play with it. Current thoughts are that an additional extension-safe target could be added to SR with a subset of the API (e.g. without UI-related code and resources).

[macguru]

"extension-safe API" refers to certain APIs that must not be called in extensions, most notably NSApplication and NSWorkspace. Since the framework isn't using any of these, it's safe to enable the APPLICATION_EXTENSION_API_ONLY flag without any side effects.

I don't see a reason to make a separate target. All the flag does is forbid certain APIs that are not used and communicates this to the linker.

[Kentzo]

Alright, let me review relevant documentation.

[ksuther]

We've been using a custom fork with this flag set for a number of years for similar reasons (we have an extension-safe framework that includes ShortcutRecorder, but the actual use of ShortcutRecorder is within regular app processes).