Indie Notes

macOS Mojave gets new APIs around AppleEvent sandboxing – but AEpocalypse still looms

2018-08-30T00:00:00Z

AppleEvent sandboxing – which was announced in the WWDC 2018 session "Your Apps and the Future of macOS Security" – affects every app that sends AppleEvents to other apps.

Back in June, I wrote that the new Apple Event sandboxing in macOS Mojave lacks essential APIs and highlighted problems with the implementation.

Since then, Apple has made a couple of changes to AppleEvent sandboxing.

Usage Descriptions for AppleEvents

Usage descriptions provide context around an app's request for a particular permission. Typically, it is shown as part of authorization prompts that ask for permission to access sensitive areas like photos, camera, contacts or calenders.

Since macOS Mojave beta 6, a usage description for AppleEvents can (and often must) now be provided for the NSAppleEventsUsageDescription key in an app's Info.plist. Daniel Jalkut has an excellent blog post showing you how.

Caveats

If you build your app with the 10.14 SDK, the NSAppleEventsUsageDescription key is required. If it is not provided, trying to send an AppleEvent to another, running app will always return error errAEEventNotPermitted (-1743). The key is only optional when using older SDKs.
If you use AppleEvents in a helper app that's contained in your app's bundle, macOS may expect and use the value for the NSAppleEventsUsageDescription key in the app's Info.plist, not the helper app's Info.plist.
Apps can only provide one usage description. It is not possible to provide different usage descriptions for every target app. I still hope we'll get that capability at some point in the future.

Determining and prompting for user consent

Two new APIs now enable apps to time when the user is asked for consent and to determine the current authorization status.

AEDeterminePermissionToAutomateTarget

macOS Mojave beta 7 introduced AEDeterminePermissionToAutomateTarget, a new API that allows apps to determine whether they're authorized to send an AppleEvent to another app:

OSStatus AEDeterminePermissionToAutomateTarget( const AEAddressDesc* target, AEEventClass theAEEventClass, AEEventID theAEEventID, Boolean askUserIfNeeded );

The new function expects a reference to the target app to be provided as AEAddressDesc.

Permissions can be determined for a specific AEEventClass/AEEventID combination. Alternatively, passing typeWildCard for both checks if every AppleEvent can be sent to the target app. This distinction is important since certain AppleEvents don't require authorization from the user.

Finally, apps can choose to just check their current authorization status - or prompt the user to obtain permission as needed.

Here's a simple example that determines if the calling app currently has permission to send AppleEvents to iTunes - and prompts if not:

OSStatus status; NSAppleEventDescriptor *targetAppEventDescriptor; targetAppEventDescriptor = [NSAppleEventDescriptor descriptorWithBundleIdentifier:@"com.apple.iTunes"]; status = AEDeterminePermissionToAutomateTarget(targetAppEventDescriptor.aeDesc, typeWildCard, typeWildCard, true);

Possible return values of AEDeterminePermissionToAutomateTarget include:

errAEEventNotPermitted (-1743): the user has declined permission.
errAEEventWouldRequireUserConsent (-1744): user consent is required for this, but the user has not yet been prompted for it. You need to pass false for askUserIfNeeded to get this.
noErr (0): the app is authorized to send AppleEvents to the target app.
procNotFound (-600): the specified target app is not currently running.

kAEDoNotPromptForUserConsent

Also new in macOS Mojave beta 7 is kAEDoNotPromptForUserConsent, a flag that can be added to the AESendMode that's passed to AESend().

If the AppleEvent sent that way would require user consent, the user is not prompted for consent. Instead AESend() will return errAEEventWouldRequireUserConsent.

Caveats

target apps need to run: to determine the current status or request authorization to send AppleEvents to another app, that app still needs to be running. Unfortunately, this limitation stands in the way of good and consistent user experiences:
- apps can't adapt their UI: if an app wants to adapt its UI depending on whether it's authorized to send AppleEvents to a target app, it can't determine its current status unless that target app is running.
  
  A UI, however, that only dynamically adapts sometimes (= while the target app is running) is inconsistent and confusing.
- apps can't preauthorize: apps that want to provide a good user experience around authorizations as part of onboarding would greatly benefit from the ability to prompt for authorization without having to launch the targeted app. It just isn't a good user experience having to.
  
  Unfortunately, for apps like mine that target a large number of apps and are meant to be useable without a keyboard, mouse or trackpad attached to the Mac, there are no realistic alternatives to preauthorization during onboarding. Right now that means launching each targeted app and then prompting the user for consent.
  
  Authorization "on-the-go" - prompting for authorization when target apps are used with them for the first time - is not an option here.
- caching results is not a solution: users can grant or revoke their authorization to control another app in System Preferences at any time, so that any previously cached return values from kAEDoNotPromptForUserConsent no longer reflect the status quo, leading to inconsistencies in apps relying on them.
prompts can't be repeated: macOS will show only one prompt per target app. If users decline an authorization in error, or change their minds later, the only way to do so is in a remote corner of System Preferences. The best possible user experience then looks somewhat like this:

Bringing up the prompt only once per target app definitely makes sense when the prompt is triggered implicitly, by way of sending an AppleEvent. Otherwise, apps unaware of AppleEvent sandboxing that keep sending AppleEvents to a target app could bring up the prompt very frequently.

However, when using AEDeterminePermissionToAutomateTarget to explicitely request the prompt, it should be possible to show the prompt more than once to avoid an unnecessarily bad user experience. If abuse of the ability to repeatedly show the prompt is a concern, a "Don't show this again" checkbox could be added to it to deal with that.

current status can't be determined without (risking to) prompt: As of 10.14 beta 9, you need to pass true for askUserIfNeeded to get errAEEventNotPermitted, which can bring up the prompt.

Passing false, errAEEventWouldRequireUserConsent is returned even if the user was previously prompted and declined permission.

In consequence, even for running applications, AEDeterminePermissionToAutomateTarget can't be used to silently determine the current status. To be usable for that, it would need to return errAEEventNotPermitted in case consent is required and the user has already been prompted about it and denied. This feels like a bug. Paulo Andrade has filed a radar about it.
calls can be blocking: if AEDeterminePermissionToAutomateTarget prompts the user for authorization, it blocks the calling thread until the user has made a choice. If this is an issue in your app, consider moving the call to a different thread: AEDeterminePermissionToAutomateTarget is thread-safe.
usage description required: if AEDeterminePermissionToAutomateTarget always returns errAEEventNotPermitted (-1743) even if you target apps for which no prompt has been shown so far, your Info.plist (or the Info.plist of the app containing the app) likely lacks a usage description for AppleEvents (see above for more on this).
documentation is hard to find: at the time of writing, no documentation - or even a hint at the existence of the new API - exists in Apple's new documentation. Detailed documentation can, however, be found in the AppleEvents.h header file.

Configuration Profiles

Apple recently updated their Configuration Profile Reference, which now includes a Privacy Preferences Policy Control Payload.

Next to AppleEvents, it also allows providing an array of Identity Dictionaries for each of these Services: AddressBook, Calendar, Reminders, Photos, Camera, Microphone, Accessibility, PostEvent, SystemPolicyAllFiles, SystemPolicySysAdminFiles. That should cover pretty much all of the new sandboxing features in Mojave.

For AppleEvents, detailed information like the code requirements of the sender and the target app is required in the Identity Dictionary. Here's an example excerpt of a payload that would allow Remote Buddy to send AppleEvents to iTunes:

<key>PayloadType</key> <string>com.apple.TCC.configuration-profile-policy</string> <key>Services</key> <dict> <key>AppleEvents</key> <array> <dict> <key>Identifier</key> <string>com.iospirit.remotebuddy</string> <key>IdentifierType</key> <string>bundleID</string> <key>CodeRequirement</key> <string>anchor apple generic and identifier "com.iospirit.remotebuddy" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = UH96K9N25C)</string> <key>AEReceiverIdentifier</key> <string>com.apple.iTunes</string> <key>AEReceiverIdentifierType</key> <string>bundleID</string> <key>AEReceiverCodeRequirement</key> <string>identifier "com.apple.iTunes" and anchor apple</string> <key>Allowed</key> <true/> </dict> </array> </dict>

With no way to whitelist apps and no way to ask the user for authorization without the targeted apps running, building a configuration profile for users and saving them a ton of clicks and frustration is definitely a tempting idea. I've also had it.

However, profiles with this payload fail to install as they "must originate from a user approved MDM server":

Updated authorization prompts

When AppleEvent authorization prompts first appeared in beta 2, the title just read:

"Some.app" would like to control the application "Other.app".

In the current beta, the title is now a lot longer:

"Some.app" wants access to control "Other.app". Allowing control will provide access to documents and data in "Other.app", and to perform actions within that app.

The additional sentence provides valuable context to inform the decision of people who aren't as familiar with macOS security, but it makes the title way too long.

Below is an image that shows this and other issues I found with the current authorization prompt, as well as suggestions on how it could be improved.

I've filed a bug on this (Radar, Open Radar).

Resetting the privacy database

Apple provides tccutil - a utility to manage the privacy database. To reset AppleEvent authorizations for all apps, use:

tccutil reset AppleEvents

Going by the man page, it should also be possible to reset the AppleEvent authorizations for a single app by appending its bundle identifier like this:

tccutil reset AppleEvents com.iospirit.remotebuddy

However, that command currently fails with an error, stating there is no such bundle identifier.

What's still missing?

Apple's willingness to act on the issues of the original AppleEvent sandboxing implementation in a matter of weeks deserves respect and my heartfelt thanks goes out to everyone at Apple who made that possible.

The new APIs solve the most pressing issues.

For many apps, however, it remains impossible to provide a user experience on par with that of previous macOS versions. Still missing for that:

the ability for users to whitelist apps to exempt them from AppleEvent sandboxing - much like what "Full Disk Access" does for file system access. This is especially important for apps that target many apps - or an open-ended list of apps. Also, users of legacy software that's not updated for macOS Mojave may find themselves in need of a whitelisting option.
an improved version of AEDeterminePermissionToAutomateTarget that can
- determine the current authorization status and prompt for authorization without requiring the target app to run
- show the authorization prompt for a target app more than once

AEpocalypse still looms

AppleEvents are a powerful and important IPC mechanism, differentiator and defining feature of the Mac. They're at the heart of AppleScript, Mac automation, utilities, accessibility tools and pro workflows.

The introduction of sandboxing will have a lasting impact on how AppleEvents work and how they can be used by apps. It has the potential to change the character of the technology as well as the Mac platform as a whole.

Summary of the current status

As of beta 9 - possibly the last beta before Mojave is likely released to the public in roughly a month - here's where things stand:

AppleEvent sandboxing still lacks essentials like whitelisting or pre-authorization to target apps that are not currently running (see above)
other than for a short segment in WWDC 2018 session 702, there's no documentation, guide, release note, tech note or transition guide about AppleEvent sandboxing.
building an app with the macOS 10.14 SDK can break its use of AppleEvents: AppleEvent and AppleScript APIs will return errAEEventNotPermitted - until a NSAppleEventsUsageDescription – which isn't mentioned or documented anywhere in Apple's documentation or headers – is added to the correct Info.plist.
the new APIs, added in beta 7, are a relatively recent addition that many developers will find useful. They are, however, not obvious to find - and documentation for them is only available in the headers, but not Apple's developer documentation.

Practical impact

Control over the timing of authorization prompts is now possible, but still constrained.

No support for whitelisting apps means users of utilities that target many apps will not be able to escape a Vista-esque "bombardment" with authorization prompts that keep interrupting their work. It's not hard to see that affected apps will get one-star reviews, loose users and sales - through no fault of their own.

No support for whitelisting apps also means there's no fallback for legacy apps that - for any reason - don't work well, or at all, with AppleEvent sandboxing.

The lack of documentation around AppleEvent sandboxing means developers either aren't aware of the changes - or can't know in time how they can prepare their apps for them.

Apple's options from here

AppleEvent sandboxing, as of Mojave beta 9, is not in a good shape. The addition of new APIs in beta 7 telegraphed that Apple is still working on it. But it's unclear what changes are still in the pipeline - and whether Apple can make enough progress before Mojave's public release.

I hope Apple can at least squeeze in support for whitelisting before public release as it's really a catch-all for issues with the new mechanism.

I feel, though, that the most responsible way for Apple to handle this situation would follow the playbooks for Group FaceTime and 32 Bit deprecation: postpone the feature until it has matured - and make it available to developers behind a feature toggle until then.

Ultimately, I'd like Apple to reconsider its approach when making changes like these to the foundation of macOS: introduce it at WWDC, but put it behind a feature toggle. Leverage the developer community. Enter into a dialogue to learn about unintended effects of the change, missing or bad APIs. Iterate. Make changes where needed. Provide comprehensive documentation well in advance. Then, at WWDC the year after, remove the feature toggle and make the change permanent.

Giving foundational changes like these a full year to mature – and developers to adapt their apps to them – would lead to all-around better results, less stress, anxiety and frustration for developers, a higher degree of stability and a better experience for users.

I'd like to thank Andreas Hegenberg, Daniel Alm and Jens Miltner for sharing their discoveries and insights with me. This blog post would be far less comprehensive without them.

Updates

How to open System Preferences' Automation section

Sep 2, 2018

Using the x-apple.systempreferences URL scheme, it's possible to open System Preferences right at "Security & Privacy > Privacy > Automation" by opening this URL:

x-apple.systempreferences:com.apple.preference.security?Privacy_Automation

In code:

[[NSWorkspace sharedWorkspace] openURL:[NSURL URLWithString:@"x-apple.systempreferences:com.apple.preference.security?Privacy_Automation"]];

Thanks to Paulo Andrade and Shane Stanley for independently sharing this hint with me.

AEDeterminePermissionToAutomateTarget can't be used to "silently" determine authorization status – not even for running apps

Sep 2, 2018

As of 10.14 beta 9, you need to pass true for askUserIfNeeded to get errAEEventNotPermitted, which can bring up the prompt.

Passing false, errAEEventWouldRequireUserConsent is returned even if the user was previously prompted and declined permission.

In consequence, even for running applications, AEDeterminePermissionToAutomateTarget can't be used to silently determine the current status. To be usable for that, it would need to return errAEEventNotPermitted in case consent is required and the user has already been prompted about it and denied. This feels like a bug. Paulo Andrade has filed a radar about it.

Thanks to Paulo Andrade for pointing this out to me.

Apple Event sandboxing in macOS Mojave lacks essential APIs

2018-06-28T00:00:00Z

In the WWDC 2018 session "Your Apps and the Future of macOS Security", Apple announced big changes to macOS security.

One of them - and possibly the one with the biggest impact: apps can no longer send Apple Events to other apps without user authorization.

Apple argues that Apple Events (which AppleScript uses under the hood) can be used to get access to otherwise protected user data in other apps, so the user should be prompted for authorization.

I concur. However, the current implementation turns out to be problematic for many legitimate, privacy-respecting apps in (at least) the automation, accessibility, device management, utility and remote control categories.

The current implementation

The first time Sender.app sends an Apple Event to Recipient.app:

the Sender.app thread sending the Apple Event is blocked
Recipient.app is launched, if it's not already running
the user is prompted for authorization

The user can then choose between these two options:

Don't Allow: the thread resumes execution. The error code errAEEventNotPermitted (-1743) is returned to Sender.app for this and other Apple Events sent to Recipient.app in the future.
OK: the thread resumes execution. This - and future Apple Events from Sender.app to Recipient.app - are delivered without prompting the user again.

Noteworthy:

Recipient.app is launched every time an Apple Event is sent in its direction - even if the user has chosen "Don't allow" before and the Apple Event isn't delivered.
the user is only ever prompted once for every sender / recipient pair.

Problem 1: authorization status is not available to apps

As of macOS Mojave beta 2, apps can't get their current Apple Event authorization status. In consequence:

Apps can't time authorization

Without information on its current authorization status, an app can't time when the user is asked for authorization.

If the app knew that authorization has not yet been requested, it could, f.ex. bring up onboarding UI right after launch.

Without that information, the app can't guard against the authorization prompt popping up at inappropriate or non-obvious times.
Apps can't adapt their UI consistently

Apps that offer additional features if authorized can't consistenly adapt their user interface without knowing their authorization status.

Even if an app saved the previous result of sending an Apple Event to another app (and thereby the user's choice): how could it know about changes the user makes in System Preferences after that?
Apps can't alert users to the lack of authorization

Apps relying on the ability to control another app might want to provide inline information about the current authorization status. For example in their settings - or as part of built-in diagnostics.

Right now, that information can't be retrieved without launching the target app and the risk of triggering an authorization prompt out of context.
Apps can't avoid getting stuck indefinitely if there's no one to answer the authorization prompt

Without knowing their current authorization status, apps can't guard against triggering an authorization prompt that blocks their sending thread indefinitely (this is bad).

This can be particularly problematic for device management (if a script never finishes) and apps that provide users with accessibility or remote access to their Mac (if blocking the calling thread means to effectively lock out the user).

We've had an API to check for an app's accessibility status since macOS 10.9 Mavericks.

macOS Mojave adds an API for apps to get their current Camera and Microphone authorization status for pretty much the same reasons: timing, adapting UI, good user experience.

Possible solution: add a similar API for Apple Events.

Problem 2: apps can't request approval without launching the target app

As of beta 2, apps can only prompt for authorization indirectly - by way of sending an Apple Event to the target app. This has several implications:

The target app gets launched

Sending an Apple Event makes macOS automatically launch the target app. This makes it impossible to prompt the user for approval for apps without launching them.

Imagine what this makes the onboarding process look like for remote control apps like mine that target 100+ apps:
1. every app the user wants to control would need to be launched at least once
2. the authorization prompt needs to be read and answered for every app
3. the target app needs to be quit
Launch, approve, quit - up to 100+ times. I don't see many new users willing to sit through this just to try out the app.
There's no way to re-request authorization

Think of a feature that involves controlling another app through Apple Events, for which the user has previously declined authorization. Possibly in error, or because it was requested in a different context - and the user didn't see the point.

Whatever the reason, the user now wants to use the feature and clicks its button.

The app gets to work, but sending the Apple Event to the target app fails with errAEEventNotPermitted. The app brings up an alert informing the user that the feature is not available because the app hasn't been authorized.

How cool would it be for the user if he could now just click the "Authorize" button in the alert - and quickly go through the authorization prompt again? Compared to easy to miss instructions on which checkbox needs to be checked in System Preferences - and how to get to it.

Possible solution: add an API to request authorization that is repeatable and doesn't require launching the app (similar to what was added to AVFoundation to request authorization for accessing camera and microphone - or what has been available for accessibility since macOS 10.9 Mavericks).

Problem 3: No "allow all" option to whitelist apps

What about apps that control a large number of other applications - or whose list of target apps is open-ended?

As of Beta 2, there's no adequate support for them. In order to get them fully working on macOS Mojave, users would need to get prompted for and authorize every targeted app individually.

But even if an app could/would do that as part of an on-boarding step, users would have to be prompted again for every targeted app that's installed thereafter.

Apple currently uses a private entitlement (kTCCServiceAppleEvents) to exempt Script Editor and Automator from Apple Event sandboxing, so users of these Apple apps will never see an authorization prompt.

Making this entitlement available to developers would of course defeat the whole purpose of Apple Event sandboxing. So that's not an option.

Users, however, should be able to pre-approve apps they trust, so these can freely send Apple Events to any other app - without bringing up prompts.

For access to protected user files, macOS Mojave already provides this capability. Seemingly at least in part to avoid bringing up multiple approval prompts. From session 702:

Apps that traverse the user's home folder could trigger multiple approval prompts, not just for Photos, Contacts, Calendars and so on. [..] So users can pre-approve such apps by adding them to the new "Application Data" category in the System Preferences Security & Privacy pane.

Possible solution: provide a similiar option in the Security & Privacy pane, for pre-approving apps to send Apple Events without limitations.

Problem 4: No support for usage descriptions

When prompting for access to Photos, Contacts, Calendars, etc., macOS Mojave allows apps to add purpose text to that prompt. From session 702:

When the user is prompted to authorize access to their personal data, it is important to communicate the purpose of that access.

Imagine that you've just installed an app that you've never used before. And the very first time you launch it, you saw this prompt [without purpose text]. That's a tough decision.

We can make that decision easier by including purpose text.

As of macOS Mojave Beta 2, Apple Event approval prompts don't support purpose text.

Apple is spot on that communicating purpose is important - and helps users with tough decisions. So this is something that really should be supported when prompting for Apple Events as well.

Possible solution: add a NSAppleEventsUsageDescription key to Info.plist

Possible solutions

After talking about the rough edges and missing parts in the current implementation, here are my ideas for addressing them:

API to query the current status

Inspired by this AVFoundation API, this is what the API providing authorization status for sending Apple Events could look like:

typedef NS_ENUM(NSUInteger, NSAppleEventAuthorizationStatus) { // User has not yet been prompted for permission. NSAppleEventAuthorizationStatusNotDetermined, // User has explicitely denied permission. NSAppleEventAuthorizationStatusDenied, // User has explicitely granted permission. NSAppleEventAuthorizationStatusAuthorized }; @interface NSAppleEventDescriptor (AuthorizationStatus) + (NSAppleEventAuthorizationStatus)authorizationStatusForTarget:(nullable NSAppleEventDescriptor *)eventDesc; @end

Using an NSAppleEventDescriptor object as argument, this API could provide the authorization status for apps targeted by URL, bundle identifier or process ID (pid).

Passing a nil value could request information on whether the app has been whitelisted to send Apple Events to any app without prompting.

API to request authorization from the user

Inspired by this AVFoundation API, this is what the API to request prompting the user for authorization (without launching the target app) could look like:

typedef NS_OPTIONS(NSUInteger, NSAppleEventAuthorizationRequestOptions) { // No options NSAppleEventAuthorizationRequestOptionsNone, // Prompt the user - even if the user was already prompted in the past NSAppleEventAuthorizationRequestOptionsForcePrompt }; @interface NSAppleEventDescriptor (AuthorizationRequest) + (void)requestAccessForTarget:(nullable NSAppleEventDescriptor *)eventDesc options:(NSAppleEventAuthorizationRequestOptions)options completionHandler:(void (^)(BOOL granted))handler; @end

Using an NSAppleEventDescriptor as argument, this API could bring up authorization prompts for apps identified by URL, bundle identifier or process ID (pid).

If the target app described by the Apple Event Descriptor is not yet running, prompting for approval should not lead to launching this app.

Passing a nil value for eventDesc could be a trigger to add the app to the "Automation" list (if it's not already in it) and bring up System Preferences with the Security & Privacy pane open on the "Automation" category. This would be very useful for sending people to the right place to make changes.

The options parameter could provide a way to pass additional options like prompting the user again, even if the user has previously been prompted for authorization.

Finally, by using a completion handler, the user could be prompted for authorization without blocking the calling thread.

System Preferences option to allow apps to control all other apps

Thinking about how an "allow all" or "whitelist" option could be integrated, I've come up with two ideas:

Left: adding a checkbox "Allow automating all apps" below each app.

If the user selects it, it becomes the only checkbox shown for that app. The app is then pre-authorized to send Apple Events to any app.

If the user unchecks it, the user is back to controlling authorization on a per-target basis.

Right: adding a popup next to the app with two options "Ask" and "Allow all".

"Ask" is selected by default and brings up a prompt for every target app.

"Allow all" can be selected by the user to pre-authorize an app to send Apple Events to any other app. If that option is selected, the individual per-app checkboxes are no longer shown for the app.

Allow apps to opt-out of automatic prompts

Some apps could benefit of an option to opt out of automatic approval prompts from the OS altogether. This could possibly be expressed via a new Info.plist key (values: automatic, never):

<key>NSAppleEventAuthorizationMode</key> <string>never</string>

Apps that have opted out:

would get back errAEEventNotPermitted until the user has authorized the app to send Apple Events to the target app.
would be responsible themselves for requesting authorization.

Add support for Usage Description strings

In order to have meaningful and relevant purpose text for every prompt, it should be possible to provide per-app usage descriptions in addition to a default/fallback usage description:

NSAppleEventsUsageDescription in Info.plist to specify a default/fallback string:
<key>NSAppleEventsUsageDescription</key> <string>Remote Buddy needs to send Apple Events to control this application.</string>
NSAppleEventsUsageDescriptionStringsFile in Info.plist to point to a strings file that maps bundle identifiers to app-specific usage descriptions:
<key>NSAppleEventsUsageDescriptionStringsFile</key> <string>AppleEventUsageDescriptions</string>

And then, in AppleEventUsageDescriptions.strings:

"com.apple.iTunes" = "Remote Buddy needs permission to display details on the currently playing song.";

I need your help

I am deeply worried that the implementation of Apple Event sandboxing in Beta 2 could make it into the final release of macOS Mojave unchanged.

As it is, it offers too little to developers who want to provide a good user experience. And not enough for utility apps and pro users who are in need of an option to exempt apps from Apple Event sandboxing.

Right now there's a broad and diverse range of useful and beloved apps that take advantage of the Mac's support for automation. They make things "just work", help make the Mac even more accessible, increase productivity and make lifes easier and richer.

For many, these apps are a reason to keep buying Macs - and a part of the Mac's heritage and DNA.

Apple Events are the core technology making these apps possible. It is therefore essential to get right any changes to how Apple Events work. So that these apps can continue to exist and thrive.

If you're using or making any of these apps, please help raise awareness at Apple on the importance of solving the problems presented here - by duping my radar (OpenRadar, Radar) and sharing this blog post.

Thanks! ❤️

Update 2018-07-03

Unlike stated above, sending an Apple event directly to an app (i.e. using NSAppleEventDescriptor) will not automatically launch the app. Instead procNotFound (-600) will be returned if the targeted app is not running.

However, addressing a target app via AppleScript (like f.ex. tell application "VLC" to play) will launch the target app if it is not running. This is true even if the app executing the AppleScript isn't authorized to send Apple events to the target app. That the target app is launched in that case is a convenience afforded by AppleScript, however - and not a result of AppleScript's use of Apple events.

That said, as of beta 2 of macOS Mojave, the target app still needs to be running for the sending app to get errAEEventNotPermitted in return, or the authorization prompt to pop up. So, as far as the effects in practice are concerned, the above still stands. It is, however, the sending app that needs to take care of launching the target app. "Raw" Apple events will not take care of this for the sending app.

I apologize for the error.

Update 2018-08-30

I wrote a follow-up: macOS Mojave gets new APIs around AppleEvent sandboxing – but AEpocalypse still looms

Bug #41570203 (OpenRadar, Radar)

Title: The new Apple Event sandbox in macOS 10.14 Mojave lacks essential APIs Product: macOS + SDK / Foundation Classification: Bug | Bug Type: Serious Bug | Reproducability: Always Description: The Apple Event Sandbox implementation as of macOS 10.14 Mojave beta 2 (18A314h) lacks essential APIs that apps would need to adapt to and provide a good user experience around the change. -- I identified these issues with the current implementation: 1) timing: apps don't have sufficient control over when the user is prompted for authorization 2) adapting UI: apps have no guaranteed non-interactive/-blocking way to know if they're authorized to send AEs to another app to adapt their UIs 3) apps can't avoid getting stuck indefinitely if there's no one to answer the auth prompt (problem for remote/MDM/accessibility apps) 4) authorization requires launching the target app. Makes on-boarding for tools targeting many apps a UX nightmare. 5) even if trusting an app targeting a large (or even open-ended) list of other apps, users can't whitelist it to avoid constantly running into auth prompts. 6) authorization can't be re-requested. F.ex. in response to a click on an "Authorize" button in an alert stating that the app lacks a permission. 7) lack of context: users lack usage descriptions to inform their decision. -- What's missing: 1) an API to get the current authorization status without launching the target app, similiar to +[AVCaptureDevice authorizationStatusForMediaType:] or AXIsProcessTrustedWithOptions(). API idea: + (NSAppleEventAuthStatus)authorizationStatusForTarget:(nullable NSAppleEventDescriptor *)eventDesc; "eventDesc" identifies the target app. Passing nil returns the app's whitelist status (see pt. 3). The return value represents the current status: - not determined (user not prompted yet) - denied - authorized 2) an API to prompt without launching the target app, similar to +[AVCaptureDevice requestAccessForMediaType:completionHandler:] or AXIsProcessTrustedWithOptions(). It should be possible to bring up the prompt even if it has been brought up before. API idea: + (void)requestAccessForTarget:(nullable NSAppleEventDescriptor *)eventDesc options:(NSAppleEventAuthOptions)options completionHandler:(void (^)(BOOL granted))handler; "eventDesc" identifies the target app. Passing nil opens System Prefs showing "Automation". "options" allow to show the prompt even if it was shown before. "handler" is called with the result. 3) an option in System Prefs to "whitelist" apps, which can then send AEs to any other app (similar to what the new "Application Data" category achieves for file access). UI ideas: https://bit.ly/2yPoeaW 4) support default and app-specific usage descriptions in prompts. 5) a way for apps to opt out of automatic prompts (as triggered by sending an AE) altogether. Apps that opted out should be returned errAEEventNotPermitted, until the apps brought up the auth prompt (via the API from pt. 2) and won the user's approval. -- Due to length constraints, I couldn't include more examples and details on the suggested APIs in this radar. For these, please see my post on this topic: https://bit.ly/2KeNNaP

Using letsencrypt with nginx to obtain, install and automatically renew SSL/TLS certificates

2016-04-17T00:00:00Z

After not having been able to log into StartSSL’s interface for two days and the expiry of an important SSL/TLS certificate looming, I looked into letsencrypt again and found an easy way to make it work with nginx for all my domains. Here’s what I did:

Prepare nginx

To verify that you’re actually running the server behind www.example.com, letsencrypt needs the ability to put a file on your web server, so that the Letsencrypt CA can subsequently download it and establish your identity. These files all need to be reachable below http://www.example.com/.well-known/acme-challenge/[cryptographic-filename]

Instead of creating a bunch of new directories for this, I’m creating just one and then route traffic below /.well-known to that directory for all domains that I want to request a SSL/TLS certificate for:

mkdir /etc/nginx/letsencrypt/webroot

I then create an include file for my nginx configurations at /etc/nginx/includes/letsencrypt.include with this contents:

location /.well-known { default_type "/text/plain"; root /etc/nginx/letsencrypt/webroot; }

Now, I can simply add

include includes/letsencrypt.include;

to the configuration of the servers I want to request a letsencrypt-certificate for:

server { listen 80; server_name www.example.com, example.com; include includes/letsencrypt.include; # Your server specific configuration here }

Finally, I tell nginx to reload the configuration:

/etc/init.d/nginx reload

Install letsencrypt

This is pretty straightforward. Change to the directory you want to install letsencrypt in, then clone the git repository and change into the directory:

git clone https://github.com/letsencrypt/letsencrypt cd letsencrypt

Now I can start requesting certificates using:

./letsencrypt-auto certonly -a webroot --webroot-path=/etc/nginx/letsencrypt/webroot --rsa-key-size=4096 --agree-tos -d www.example.com -d example.com

If everything works, you’ll now find private key, certificate and certificate chains in /etc/letsencrypt/live/www.example.com/.

Adding the certificate to your configuration

To use the letsencrypt certificate, point ssl_certificate, ssl_trusted_certificate and ssl_certificate_key to the respective files.

Here’s a sample configuration for example.com with safe ciphers and OCSP stapling:

server { listen 443 ssl http2; server_name www.example.com, example.com; ssl on; ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/letsencrypt/live/www.example.com/chain.pem; ssl_dhparam /etc/nginx/ssl/dhparam.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-S$ ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_tickets on; ssl_session_timeout 10m; # Your server specific configuration here }

Renew certificates in time

This is my favorite part about letsencrypt. Issued certificates expire 90 days after issuance, but the great folks at letsencrypt have made checking certificates for expiration and renewing them in time trivially simple:

./letsencrypt-auto renew

That’s all! No adding expiry reminders to the calendar, no issues with unavailable or slow web interfaces, no time wasted waiting for emails with verification codes. Finally! If you want to run this via cron, don’t forget to pair it with

/etc/init.d/nginx reload

so that nginx can pick up updated certificates.

Alternatives

If you can't or don't want to install software on your server, you can also obtain a letsencrypt certificate through this 3rd party web interface.

7 things I learnt creating an App Preview video for Apple TV

2016-04-05T00:00:00Z

Between the initial release of Remote Buddy Display in November 2015 and the first update, Apple has added App Previews to the tvOS App Store: short videos, between 15 and 30 seconds in length, that allow potential new users to see an app in action before installing it.

While I’m pretty happy with how the introductory video for Remote Buddy Display turned out, it’s more than twice as long as the maximum permitted length for an App Preview video.

So I accepted the challenge of the format and its constraints and jumped in. Here are a few things I learnt and thought about while creating the video:

1. App Previews on Apple TV are a big deal

First, literally, App Previews on tvOS are shown on what is probably the biggest screen in the home.

Second, the way App Previews are integrated into the tvOS App Store differs greatly from the iOS App Store. If you add an App Preview to an iOS app, it’s poster frame dominates what people see of your app in search and on the app’s page in the App Store.

Search result on the iOS App Store

On tvOS, App Previews are a much less risky proposition: the app’s icon continues to be shown in search — and the video does not occupy the place of the first screen shot.

Instead, the poster frame of the App Preview now fills the right half of the page (blank otherwise) and a dedicated “Preview” button invites users to play the App Preview right away.

Third, the emphasis on paid content is stronger on the tvOS App Store: according to Apple data from early 2016, only 50% of tvOS apps can be downloaded for free (vs. 82% on iOS). That’s a good thing for indie developers, but I’d still expect users to hesitate before spending their dollars on an app they can’t try beforehand. A captivating App Preview, then, may be just what’s needed to convince them.

iOS and tvOS App Store Catalogs by Business Model. Source: Apple TV Tech Talks

2. Deciding on a storyboard & soundtrack early on helps immensely

When I do a new video for one of my apps, one of the first and most important things I do is to brainstorm what I want to show, bring these ideas into a logical order and — if possible — find a continuous stream of actions I can show.

From this, I write a storyboard that contains all text titles, speech and scene contents in written form.

Finally, I look for a soundtrack that fits the pace of the story I’m about to tell in my video.

I found that writing a storyboard and deciding on a soundtrack early on really helps to keep production time to the minimum while making sure that the video I record fits the pace and special features of the background music.

3. Focus or die

At first, the 30 second limitation of App Previews gave me the horror. Now I appreciate it, because it rewards all the right things and discourages everything that might shy away new users.

It forces me to focus. Focus on the best parts and meaningful interactions that best represent my app’s purpose.

I simply don’t have the air time to show endless navigation through menu hierarchies. I need to get to the point. And fast. That’s a good thing.

4. Don’t layer text on top of video

In the past, I have often layered text on top of video to annotate and explain what is being shown. This can work well if what is shown takes long enough for the viewer to have a chance to both read the text and re-focus on and follow the action.

In a 30 second video, however… forget it: the moment a viewer has completed reading the text, the action that’s been annotated has ended, too.

So in the name of not letting anything happen concurrently in this video, I ended up alternating full screen text titles with video recorded from the Apple TV.

The end result is just so much better.

5. Final Cut Pro X can animate Photoshop layers

When it comes to titling a video, my usual process is to create them with Keynote and export them as QuickTime file, which I then feed in Final Cut Pro X.

This time, however, since I didn’t think I’d need any text transitions, I quickly threw some titles together in Photoshop and dropped the PSD files directly on Final Cut Pro X.

Much to my surprise I found that Final Cut Pro X would turn every layer in the PSD file into a track of its own and allow me to apply transformations and transitions on them — just like with any other object.

When I wanted one text transition later on, I could just create it right in Final Cut Pro X and skip Keynote entirely this time.

6. Keep the use of transitions and effects to a minimum

There is no shortage of wild, impressive transitions and effects in Final Cut Pro X and Keynote. Yet I have kept my use of transitions in the App Preview to a bare minimum (variations of simple cross fades, really).

First, transitions eat time — and time is a particularly scarce resource in an App Preview video.

Second, transitions and effects, if overused, can at best just be distracting — and at worst be damaging: after all, a beautiful frame around a bad photo doesn’t improve the photo. Instead it amplifies how bad the photo is.

Or, put more positively™: if you have a great app, let is shine and speak for itself. Avoid ridiculing it through the overuse of transitions and effects.

7. The App Store adds a one-second transition at the beginning

Visiting Remote Buddy Display’s App Store page after the update went live, I noticed that the App Store had overlaid the first second with a transition: audio fades in slowly and the video fades in from black.

As a result, the first full screen text title at the beginning of the video is only briefly visible, giving the video an abrupt start. It’s not a complete deal breaker, but I wish I had known of this beforehand.

For the next update, I’ll account for this by inserting a second of silence and black at the beginning of the video.

Final thoughts

This is the first App Preview video I’ve made, and it will be interesting to see how and if it will affect the bottom line.

However the result may look like, I’m already glad I made the video, because the process taught me some important lessons about making (hopefully) more impactful product videos.

Here’s the result of roughly a day of work: Remote Buddy Display: control your Mac with Apple TV and Siri Remote (App Preview video) (YouTube)

How to use the OS X 10.9 SDK with Xcode 7.3

2016-03-22T00:00:00Z

When Apple shipped Xcode 7, it decided to ship it only with the OS X 10.11 SDK. Unfortunately, this has since put developers of USB kernel extensions between a rock and a hard place.

OS X 10.11 ships with a new USB stack and also took care of backward compatibility for both the kernel and user space APIs:

OS X v10.11 Changes
This article describes changes to USB in OS X v10.11.

The USB stack is completely redesigned to increase stability and performance compared to Mac OS 10.10. Applications and third-party drivers for vendor-specific USB devices built with 10.10 SDK require no modification.
Applications that use IOUSBLib APIs should continue to work with no modification. IOKit drivers that use IOUSBDevice and IOUSBInterface APIs should continue to load and be functional with no regressions.
If you are developing a new IOKit driver that uses IOKIT USB APIs, please refer to the OS X v10.11 SDK for new API and classes such as IOUSBHostDevice and IOUSBHostInterface. New applications developed using the OS X v10.11 SDK should continue to use the IOUSBLib APIs.

Different classes of USB devices should not exhibit any regression in functionality compared to the OS X v10.10 release.

(Source: Apple, Google Cache, Tweet)

In essence, that means you can still write a USB kernel extension targeting older OS X releases and it will continue to just work™ under OS X 10.11, too.

The OS X 10.11 SDK, however, lacks the needed header files for the old USB stack. And that’s why the OS X 10.9 SDK is still needed if you want to build these.

Up until Xcode 7.2.1, this was as easy as copying the folder MacOSX10.9.sdk folder from Xcode 6.4 over into the Xcode 7.x application bundle.

Not so in Xcode 7.3 – apparently because its MacOSX.platform contains a new key, specifically telling Xcode to ignore any SDKs prior to OS X 10.11.

Here’s what I had to do to get Xcode 7.3 to work with the OS X 10.9 SDK:

Quit Xcode 7.3.
Copy
[Xcode6.4].app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
to
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
Open
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist
and remove these two lines:
<key>MinimumSDKVersion</key>
<string>10.11</string>

Symbolicating OS X panic logs

2015-10-05T00:00:00Z

I was in need of symbolicating an OS X kernel panic.log and consulting Apple's TN2063 (Understanding and Debugging Kernel Panics) to do that, when I realized that Apple had last updated this document in 2008: kextload would complain about paramters it no longer knows about, gdb no longer ships with Xcode and the Kernel Debug Kits for more recent OS X releases neither include the referenced tools nor is their layout compatible with what that TechNote expects.

In other words: if you want to symbolicate a recent kernel panic log, that TechNote - which used to be a great resource for that purpose - is no longer of any help; you're on your own.

So, after some research, I'd like to share with you how I managed to symbolicate an OS X 10.11 panic log by hand using lldb and the kernel debug kit for 10.11:

If you haven't already done so, download the kernel debug kit for the OS X release the panic occured on from https://developer.apple.com/downloads/ and install it. That will add a kernel debug kit for that OS X release to /Library/Developer/KDKs/.
Open Terminal.app and start an interactive lldb session with the kernel image of the KDK you just installed (all in one line):
$ lldb /Library/Developer/KDKs/KDK_10.11_15A284.kdk/System/Library/Kernels/kernel
LLDB will inform you that 'kernel' contains a debug script and provides instructions to add these to the current session. Add them to the session.
(lldb) target create "/Library/Developer/KDKs/KDK_10.11_15A284.kdk/System/Library/Kernels/kernel" warning: 'kernel' contains a debug script. To run this script in this debug session: command script import "/Library/Developer/KDKs/KDK_10.11_15A284.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/DWARF/../Python/kernel.py" To run all discovered debug scripts in this session: settings set target.load-script-from-symbol-file true Current executable set to '/Library/Developer/KDKs/KDK_10.11_15A284.kdk/System/Library/Kernels/kernel' (x86_64). (lldb) settings set target.load-script-from-symbol-file true
The kexts included in the backtrace are listed under "Kernel Extensions in backtrace" along with their addresses. Let's add them next, using this as a template:
(lldb) addkext -F [PathTo.Kext]/Contents/MacOS/[KextExecutable] [KextLoadAddress]
The [KextLoadAddress] is the start address that is included after the @ sign. Example:
(lldb) addkext -F /Library/Extensions/My.kext/Contents/MacOS/My 0xffffff7f80d51000
We can now look up the symbol for any address by feeding the return address (on the right side of the colon) into
(lldb) image lookup -a [ReturnAddress]
Example:
(lldb) image lookup -a 0xffffff7f80d536f5

I'm pretty sure there are better ways to use lldb to symbolicate a panic.log, but it's the only I could find for now. If you know about a more efficient way, please don't hesitate to post it in the comments.

Updates

Accounting for KASLR

Feb 27, 2019

Rudy Richter on Twitter pointed out to me that my blog post does not account for KASLR and that, in that regard, this mail on Apple's darwin-kernel list can be really helpful.

Calculating sunrise and sunset times without Core Location

2015-03-31T00:00:00Z

I looked for a way to support day and night modes in an upcoming iOS app I’m working on. It is an integral part of the user experience, so ideally, it should “just work” - without requiring any steps on the part of the user.

Core Location

Core Location would prompt and require users to share their precise location (whereas an approximation would do). It also would need access to GPS and/or the Internet. That’s too many moving parts for it to “just work”.

GeoIP

I could put together a web service that tries to geo-locate users by their IP. However, I would not feel comfortable doing so without asking users for their consent first. It would also require an internet connection. In the end, it would be a lot like Core Location - just not as good. Which kind of makes this option ridiculous.

NSTimeZone

This may seem silly at first since places on the northern and southern hemisphere can share the same time zone, yet have very different sunrise and sunset times.

Time zones on iOS, however, usually take the form of “Continent/City” (f.ex. “Europe/Berlin”) and not “GMT+1”. Plus, with default settings, iOS automatically selects and updates the correct time zone based on your actual location. Bingo!

Unfortunately, while NSTimeZone provides the name of a timezone, it does not offer any location information.

So I wrote a category to fill this gap. Based on data from the IANA Time Zone Database, NSTimeZone+ISCLLocation provides CLLocation and ISO 3166 country codes for location-based time zones under iOS and OS X.

Here’s how it works:

In my upcoming app, I'm using the returned location with CLLocation-SunriseSunset to calculate sunrise and sunset times. In cases where a location is not available, I use Core Location as a backup solution.

You can find the NSTimeZone+CLLocation repository on GitHub.

Enjoy!

Resolving symbols in a sample log from Activity Monitor

2014-08-15T00:00:00Z

Often bugs don't crash an application right away but merely lead to it becoming unresponsive or "hanging".

When I'm approached with such issues in my software, the first thing I ask for is a sample log obtained through Activity Monitor.

Because the public builds of my software don't contain any debug symbols, I only see ??? and a code offset for those spots that reference my code.

There are tools and services out there to symbolicate crash reports, but I'm not aware of anything such for sample logs, which have a different format.

So here's what I do to resolve symbols in sample logs that I receive.

Let's start with a sample log:

Sampling process 3812 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling Remote Buddy (pid 3812) every 1 millisecond Process: Remote Buddy [3812] Path: /Applications/Remote Buddy.app/Contents/MacOS/Remote Buddy Load Address: 0x1000 Identifier: com.iospirit.RemoteBuddy Version: 1.25 (1.25) Code Type: X86 [..] Call graph: 2568 Thread_3519212 DispatchQueue_1: com.apple.main-thread (serial) + 2568 ??? (in Remote Buddy) load address 0x1000 + 0x1315 [0x2315] + 2568 ??? (in Remote Buddy) load address 0x1000 + 0x13ee [0x23ee] + 2568 ??? (in Remote Buddy) load address 0x1000 + 0x1548 [0x2548] [..] Binary Images: 0x1000 - 0x1edfe7 +com.iospirit.RemoteBuddy (1.25 - 1.25) <B7BE5172-CEBA-3128-3805-4F81A1FCCA21> /Applications/Remote Buddy.app/Contents/MacOS/Remote Buddy

To resolve the symbols, I need the dSYM that was created alongside the build this sample was taken from. Each dSYM and app share a unique UUID. Here, it's B7BE5172-CEBA-3128-3805-4F81A1FCCA21.

To verify that you're using the correct dSYM, you can print the UUID of your dSYM using dwarfdump --uuid on the DWARF file in your dSYM:

xcrun dwarfdump --uuid "Remote Buddy.app.dSYM/Contents/Resources/DWARF/Remote Buddy"

If your dSYMs were indexed by Spotlight, you can also search for the UUID in Spotlight to find the dSYM corresponding to the sample log you received.

Using the Code Type, the Load Address and the code offsets in the Call graph, I can now take to the Terminal to resolve the numbers into symbols.

For a Code Type of x86, the Architecture is i386, for a Code Type of X86-64, the architecture is x86_64.

To open an interactive prompt, I type

atos -arch [Architecture] -o [DWARF file] -l [Load Address]

atos -arch i386 -o "Remote Buddy.app.dSYM/Contents/Resources/DWARF/Remote Buddy" -l 0x1000

in this example. I can then enter code offsets to resolve them into symbols:

felix $ atos -arch i386 -o "Remote Buddy.app.dSYM/Contents/Resources/DWARF/Remote Buddy" -l 0x1000 got symbolicator for Remote Buddy.app.dSYM/Contents/Resources/DWARF/Remote Buddy, base address 1000 0x2315 start (in Remote Buddy) + 41 0x23ee _start (in Remote Buddy) + 216 0x2548 main (in Remote Buddy) (main.m:79)

Press Ctrl+C to exit the interactive prompt.

And that's it!

How to build on 10.8 and earlier, then sign for and submit to the Mac App Store on 10.9

2014-08-06T00:00:00Z

Two days ago, Apple updated its Technote 2206 with a new paragraph on changes in OS X 10.9.5 and Yosemite DP5:

Beginning with OS X version 10.9.5, there will be changes in how OS X recognizes signed apps. Version 1 signatures created with OS X versions prior to Mavericks will no longer be recognized by Gatekeeper and are considered obsolete.

Apple further emphasizes:

Important: For your apps to run on updated versions of OS X they must be signed on OS X version 10.9 or later and thus have a version 2 signature.

Apple also suggests what you can do if you build on older versions of OS X and distribute outside the Mac App Store:

If your team is using an older version of OS X to build your code, re-sign your app using OS X version 10.9 or later using the codesign tool to create version 2 signatures. Apps signed with version 2 signatures will work on older versions of OS X.

Pretty straightforward. Now what about apps on the Mac App Store?

If your app is on the Mac App Store, submit your re-signed app as an update.

Does that mean that Mac App Store apps submitted with a v1 signature will stop working on 10.9.5 and later?

I quickly ran some tests:

@danielpunkass Just tested with a MAS application built and submitted on OS X 10.6.8: installed & launched w/o problems. Non-MAS/GK: failed.
— Felix Schwarz (@felix_schwarz) August 4, 2014

While this works now, it's not clear to me whether apps submitted with a v1 code signature will continue to be available on the Mac App Store and continue to work fine with OS X 10.9.5 and later.

I prefer to be safe, not sorry, so I stick to what the Technote says (or seems to say), which is to submit an update with a v2 code signature.

From the Technote, it's not really obvious how to do this for apps that have to be built on OS X 10.8 and earlier. Apple makes it clear that trying to use a copy of Mavericks' version of codesign on your build machine won't solve this:

The actual code signing machinery is part of the operating system, not the codesign tool. It will not work to copy the codesign tool from Mavericks to an older OS X version.

Currently I have to build parts of Remote Buddy in Xcode 3 running on OS X 10.6.8.

Up to this date, this has never been a problem since I could still submit updates to the special Mac App Store version right from within Xcode 3.

The only way to obtain a v2 signature is by code signing under 10.9, but since Xcode 3 doesn't run on anything newer than 10.6.8, I'll have to separate the build process from the signing, packaging and submission process.

Here's what I'm doing now:

Build Remote Buddy Express on OS X 10.6.8 as usual.
Copy the built app to a Mac running OS X 10.9.
Run a script (SignAndPackageForMAS.sh, more on that later) that signs the app and packages it as a signed pkg file ready for submission to the Mac App Store.
Use Application Loader (Xcode > Open Developer Tool > Application Loader) to submit the package (pkg) file to the Mac App Store.

A copy of SignAndPackageForMAS.sh that you can adjust to your needs can be found at the end of this post or directly in this gist. For most apps, you should only have to change the names of your signing identities and paths in the Configuration section to match your own setup.

What the script does is to search for Cocoa bundle and frameworks inside your application and sign these before signing the application itself. It then uses productbuild to create a signed package ready for submission to the Mac App Store.

If your app contains other types of binaries, be sure to sign these before signing the app bundle itself, starting with the binaries located at the deepest filesystem level, working up your way to the highest filesystem level.

Update: Thanks to feedback from Daniel Jalkut (@danielpunkass), I moved the codesign options to its own variable and added some information on --preserve-metadata.