I’ve always had great admiration for those who undertake keyhole surgery. To be able to perform sometimes major operations through such a small incision is a high skill indeed. However, it’s not a strategy which should be emulated in software development tools like Xcode.

You’ll no doubt have noticed, even if you aren’t intending to upgrade early, that Mojave brings new privacy protection. One of the most significant ways in which that affects apps and their developers is that those wanting to be able to access protected data or features have to declare their intent by providing usage information or purpose strings. Apps built using the latest support for Mojave must do that, or the privacy system will lock them out.

These usage information strings are then displayed in the prompts with which we will soon become very familiar, when Mojave seeks the user’s consent to give an app access to protected data.

The usage information supplied by the app is shown in smaller text in the consent dialog, in this case explaining much more comprehensibly just why the user is being prompted to give their consent, and what that allows.

Apple made it clear in presentations at WWDC 2018 how important it is that the usage information given to the user is explicit and helpful: “But we can make that decision easier by including purpose text, which makes it clear why the app is requesting access and what the consequences of declining that access would be.” So the strings supplied could be quite long, in cases maybe even two or three sentences.

macOS provides several different types of privacy purpose string, including

• NSCalendarsUsageDescription
• NSContactsUsageDescription
• NSPhotoLibraryUsageDescription
• NSRemindersUsageDescription
• NSSystemAdministrationUsageDescription
• NSLocationUsageDescription
• NSCameraUsageDescription
• NSMicrophoneUsageDescription
• NSAppleEventsUsageDescription

whose names indicate which type of data or system they concern. These are stored in the app’s Info.plist file, and because that’s included within the scope of its code signature, they can’t be changed by the user.

Over the last three months, Apple’s Xcode development environment has blossomed into version 10, with full support for Mojave, and the first release version is now available in the App Store. What support does it provide for these potentially long and vital strings? Almost none.

Instead of Xcode offering a properly laid-out view with good editing facilities, adding a privacy purpose string is an awkward mess, an unanticipated addition to the general list of properties for the Info.plist file.

First you have to select another existing property, and click on the tiny + tool to add a new property. This presents a combo box listing dozens of different keys. You next have to type in the start of Privacy, as these properties are listed under descriptive names rather than their actual key, and select the correct one from the narrowed list.

The string editor is Xcode’s keyhole surgery challenge: the tiny space provided for editing that string shows little more than six words at a time: This allows Bailiff to be installed… This is hardly a fit way to be editing two or three sentences explaining “why the app is requesting access and what the consequences of declining that access would be”.

Compare this with the far more friendly and extensive support provided for hardening apps and setting their entitlements, for example, which is just a collection of on-off switches.

Maybe sometime in the next year or so, Xcode’s tools will catch up with the changes brought in Mojave. Please?