Now that you know we have secret features for debugging and testing, let’s consider how to activate them when we need them. But first, let’s go over a few larger issues.

Should There Be Secret Features At All?

There’s always a bit of discussion around this issue. The hard-core devotees will argue no, you should never have secret features in production builds. You should instead have alternative builds only available to insiders with the secret features you want. There’s plenty of validity to this viewpoint, but others take a different approach.

Having secret features, for debugging and testing, in every build, production or not, affords a high degree of convenience. You can have more or less secure modes of activation, and even add authentication if you want. Having separate builds adds complexity, and quite often confusion about who is testing what. The trade-offs are up to you.

Finally, many app developers add A/B testing into apps, which is much in the same league as secret features. So generally, the purists lose this argument in many places.

Alternatives for Activation

There are many possibilities for activating secret menus. The first one I ever came across was “triple tap on the copyright notice” — perhaps a gesture you would not expect the average user to try.

Another approach is to have a helper app that you install on a device where you wish to test — the helper app does nothing but register to respond to a lengthy custom URL scheme. The apps with secret features can then see if such an app is installed on device, and activate the features only if it is installed.

There are many other possibilities, which are outlined by Mr. Andrew King in a nice article. He recommends installing a custom profile on a device which apps can look for prior to activating secret features.

How to Enable Custom Debugging in Release Builds - Andrew King

Mr. King also lists a few more ways to possibly unlock secret features, none of which are quite the way we ended up doing it.

Tap the Rows to Unlock

While multiple tap gestures on some UI item provides the simplest approach, it can be easily discovered, perhaps even accidentally, by average users.

What we want is a longer code, perhaps a sequence of digits, that will unlock the features we wish to have concealed from regular users, but readily available to us.

An eight-digit code should be long enough to deter anyone from brute force solutions, as long as we don’t make it “12345678" — let’s choose a better one “17762020.”

To enter the code, we monitor a table view, in this case our App Info details, and watch to see if a corresponding set of rows is tapped. In our case we tap

• Bitcode Enabled?
• Default Compiler
• Default Compiler
• Configuration
• Build Date?
• Architecture
• Build Date?
• Architectures

Since these rows otherwise do nothing unless tapped, the app simply does nothing at all until it recognizes the desired sequence. When it does recognize the required sequence, it silently activates the secret features.

You might ask where the secret code should be kept? For the most convenience, you store it in the app build. In a property list, in a class somewhere, whatever is convenient. If you are very paranoid, you can obfuscate it as best you can.

If you are even more paranoid, you can consider having records in CloudKit (or some other server) where you will check that the device is using an Apple ID that you have authorized to reach the secret features.

Don’t do anything crazy

As you will see in future stories, none of the secret features we enable in our apps with this code compromise security or potentially enable fraud. Don’t put anything that could do so in your apps.

One more thing

It’s convenient to have the same code that activates secret features also deactivate them.

Next up we’ll dive into the Developer menu features and see what we find there.

Intermission 3 was originally published in iOS Examples Without Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unlike the Secret History of Procopius, our Secret Menus are not going to be an attack on the Emperor Justinian, his entourage or anyone else. They will be revealed instead as a series of tools and displays that will help you greatly improve and maintain the quality of your apps.

In the course of developing or revising an app, there are two sections of extended features to be enabled:

Developer

The Developer section contains commands that let you change the state or behavior the app for testing purposes.

For example, you might wish to quickly delete all In-App Purchases (IAP), so you can keep testing behavior without having to continually uninstall and re-install the app.

Setting the locale of the app is another very handy command when you are working on an app that is localized for more than one country. It is much more convenient to do that immediately while the app is running, than to stop and restart.

Diagnostics

The Diagnostics section contains commands that let you examine the current (and past) state of the app as it is running.

As one example, you might want to look in the app’s bundle to see exactly what is being placed therein. Or look into the sandboxed file system of the app, to make sure that the app is actually saving what you think it is saving.

Further, if your app is architected to support this, you might be able to introspection on various objects in the app, so you can see their current states, and examine their past behavior.

All of this functionality does not replace console logging or close examination within the Xcode environment — but it gives you considerable power in examining the behavior of apps outside of Xcode.

A Preview of Developer and Diagnostics

Without further ado, let’s take a look at the Developer and Diagnostics sections

We’ll discuss each of the rows in these sections in a forthcoming article, but first, we’ll again digress and discuss:

Intermission 3 — Activate the Secret Menus.

Settings 108 was originally published in iOS Examples Without Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

The last row in the Info, Privacy & Settings section is Your Device. While you might think this would be the end of our discussion of Settings, it’s not. There’s more to come: at the end of this story we’ll open an unexpected door.

Tapping on the Your Device row in the Info, Privacy & Support section displays a standard UITableView with a number of rows displaying information about the device in hand.

When it’s a real device, as seen here, you get a real-time view into the top level state of your device.

When it’s a simulated device, you still get the information, but some of it is a little strange as it reflects the Mac on which the simulated device is running.

This information can be helpful if you get bug or crash reports involving specific devices or versions of iOS.

Most of the information shown in Your Device is captured using Apple’s NSProcessInfo class, but some requires the UNIX functions sysctl, sysctlByName, and getenv. Detecting the correct model of simulator is done using the SIMULATOR_MODEL_IDENTIFIER environment variable.

As we noted above, you might think that would be the end of our discussion of Settings. Except.

Next time: Section 108 — The Secret Menus.

Settings 107D was originally published in iOS Examples Without Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is another easy one. If you have a support e-mail address, in our case support@359north.com, you’ve got everything you need.

Tapping on the Send Us Feedback row in the Info, Privacy & Support section displays Apple’s standard view for sending an e-mail.

You can pre-populate the email with the destination, and some informatino about the app, the user device and version of iOS, along with locale information for the user. This can be especially helpful in shortening the amount of time to needed to investigate complaints or suggestions, as they can often be specific to devices or versions of iOS.

Apple’s MFMailComposeViewController makes setting this up in the LUX framework a breeze. So you get the functionality “for free” in any app you build using your own private framework.

Next time: Section 107D — Your Device.

Settings 107C was originally published in iOS Examples Without Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is an easy one. Once Apple started requiring a privacy policy accessed via URL for all apps, you had to do all the necessary content work.

Tapping on the Privacy Policy row in the Info, Privacy & Support section displays a webview with the proper URL.

A simple approach would be to just push a view controller containing a WKWebView, and set the URL.

For a little more dynamism, we slide up a custom view controller, using a subclass of UIPresentationController to control the animation and size, and darken the background.

This is the same custom view controller we use to present web pages in the Credits section of About This App.

Next time: Section 107C — Send Us Feedback.

Settings 107B was originally published in iOS Examples Without Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

Keeping track of what you are doing is important. The larger the team, the more important it becomes. There are two identifiers for a specific build of an app, we’ll call them the version and the build number.

We’ve used various approaches to updating these numbers over the lifetime of an app, but have settled on a single approach that’s worked well across many apps and organizations.

1. Manually update the version, say from 1.0 to 1.1, when you start work on a new release for the App Store.
2. Automatically update the build number, setting it equal to the number of Git commits since the inception of the project.

This approach has a lot of benefits, but read to the end to see a situation where it is perhaps less than optimal.

In the example here, using our terminology, Saving Daylight is at version 1.0, build number 245, while the LUX framework is at version 1.3 and build number 232. (The app build number has the Git branch name appended, as it is a debug build, not a release build.)

Apple Terminology

Apple itself is not consistent in how it refers to these identifiers. On the App Store, it uses only the first identifier, 1.0, and labels it “Version.” In Xcode’s organizer window it uses both, 1.0(245) and labels it “Version.” In App Store Connect, if you create a new version it wants the first identifier and calls it “Store Version Number.”

In Xcode you set these two identifiers in the General panel of a Target. Or you can set them in the Info panel, or by editing the Info.plist file directly.

Inside the Info.plist file there are two keys that you can set:

• Bundle version string (short)
• Bundle version

corresponding to our version and build identifiers. The Info.plist keys as see in Xcode are modified from their actual values in the property list file:

• CFBundleShortVersionString
• CFBundleVersion

• CFBundleShortVersionString
• CFBundleVersion

In days of yore, developers simply updated those Info.plist keys as needed. That approach does not scale well with larger teams, and creates some work that can be avoided.

Source Control

Apple’s support of source control systems has evolved over time, from Perforce/CVS/Subversion to now only supporting Git directly. We’ll discuss Git here, but you can probably adapt this approach to other systems.

If you are using a source control system, it’s natural to think that counting commits from the inception of the project would be a nice, automated way to have a monotonically increasing build number.

Getting the commit count is easy enough to do, and Apple provides a command-line tool, PlistBuddy, that makes it possible to edit values inside property lists. You can add a run script to your project

It seems simple, but there’s a catch: changing a value in Info.plist is seen by Git as a change, so your project will be seen to have uncommitted changes when you build it.

There’s a clever trick to get around this problem. Your run script does not modify the Info.plist in the source code, instead it modifies the Info.plist in the Built Product, which is not under source control. It simply runs after the compile and linking build phases.

We got the basic idea for what we do from Jared Sinclair, with most of the programming details, located here:

Jared Sinclair

Once you realize that you can change CFBundleVersion “after the fact”, you realize that you can also insert or change other things in Info.plist. That’s how we capture a lot more build information, which can be very valuable as you try to coordinate multiple developers and testers.

About That Small Problem

Using commit counts to version app builds works well when unrelated apps are managed in different repositories. But if that’s not the case, watch out!

Some years ago we worked in a very large and active environment where almost everything was stored in a single Subversion repository. So if you did an incremental commit, your version number jumped from 134,245 to 135,988. Needless to say, numbers that large are hard to scan in the first place, and because all the projects are mixed together, you don’t get any sense of “rate of progress” like you do when an app is hosted in its own repository. Size matters.

Next up: Settings 107B — Privacy Policy.

Settings 107B

Intermission 2 was originally published in iOS Examples Without Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

From the Info, Privacy & Support section of Settings, we’ll now look into About This App — a collection of information useful for problem solving, and perhaps satisfying the curiosity of a few users and other developers.

Tapping About This App displays a new view with two or more sections. The name of the app, in this case MirrorDay, is featured as a large navigation title.

Credits

Upon initial display, the view has the Credits section opened — we want to make sure that the people who have helped us along the way are featured first and prominently.

Perhaps differing from Credits sections in other apps, which are rarely prominently featured, we also provide links to websites associated with the people and companies we are crediting.

For example, in this view we are showing the NSBlog website at mikeash.com, which provided years of illumination while we were honing our iOS (and macOS) skills.

There’s also an “Open in Safari” button, so you can take full advantage of viewing the sites in Safari, sharing links to articles, etc.

The list of credits is embedded in the LUX framework that is included in most of our apps. That means that providing the Credits information takes little or no work, and updating the list in the LUX framework means that all our apps, when new builds are released, feature the latest list.

The App Build Information

The first section of the view features the build information for the app, again in this case MirrorDay.

You can see in the example that we are looking at a build running on an iOS Simulator. A number of the rows give us clues, including:

• Architectures
• Bitcode Enabled?
• Effective Platform Name
• SDK Name

While we are running the app in a Simulator, this information is of minor interest.

But once we are in an environment featuring testers, multiple developers, managers, etc. being able to be very specific about what build we are using is of critical importance.

In an environment where builds can possibly come from multiple machines (individual developers, CI systems like Jenkins, or various build services in the cloud), it turns out to be quite important in some instances to know exactly where an individual build was created. Although larger shops may allow no exceptions to a policy of uploading builds to the App Store from their CI system, smaller developers may sometimes go around that policy for any number of reasons.

Framework Build Information

Just as app information is useful in knowing exactly what one has at hand, the exact same information about library builds is also very helpful.

In the example here, you can see the build information for the LUX framework.

Note the differences here, indicating we’ve included a Release build of LUX in the simulated app.

Running in the Simulator, the information shown is a little misleading.

To successfully use frameworks in iOS apps, one has to build for multiple architectures, and then combine them into one framework.

In this case, we’re showing the information for the iOS version of the framework, not the Simulator version. This is probably what we want anyway, because when the app is uploaded to the App Store, we will strip out the unneeded x86_64 architecture. Indeed, if we don’t strip that architecture out, our upload will fail with a possibly misleading message.

How To Get Build Information

So where does all this information come from. A lot of it comes from Xcode environment variables, but one key piece of information, the build versions shown in the section header, comes from one very clever trick which we’ll describe in the next article, another Intermission.

Settings 107A was originally published in iOS Examples Without Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

After the three major sections of Options, Permissions, and Purchases, we’re down to the rest of the story. Our last section could be called “Et Cetera”, and probably should be called “Support +” to fit alphabetically, but for the moment we’ll stick with what we’ve got. Our defense for not going alphabetical is that four items is less than the magic cognitive number 7, so users should be able to easily grasp what’s here even without a true ordering.

So what have we got in our ultimate section?

About This App

Tap this row to display technical information about the app, the included LUX framework, and credits with links to articles and projects which were used in building our frameworks and apps.

Privacy Policy

Tap this row to display a web view displaying the privacy policy on our website. The chance of anyone wanting to read your privacy policy is pretty low, but you should nevertheless make it accessible to those noble few who might actually look.

Send Us Feedback

Tap this row to pull up a draft email addressed to our support e-mail address. Pre-formatted, it contains basic app information that will help us provide the support you need.

Your Device

Finally, tap this row to see the device information that can be collected by any app running on your device. We provide this information as a convenience, and it can be handy in debugging problems that are particular to an individual device.

In the next story, Settings 107A, we’ll discuss the details of the About This App section.

Settings 107 was originally published in iOS Examples Without Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

Like Permissions, almost all the work associated with displaying, purchasing, and restoring in-app purchases can be placed in a shared framework, in our case the LUX framework. Unlike Permissions, you don’t need to interact much with the app at all. From the app’s perspective the conversation looks something like this:

When the MirrorDay app starts up

App: Hey LUX, here's a list of all the product identifiers that can be purchased in this app.

LUX: (silently accepts and checks with Apple to get the name and price of each product.)

If the user taps Purchases in Settings

Settings 106 was originally published in iOS Examples Without Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

We all like free stuff. We’d all love to provide an excellent Settings experience while doing as little work as possible. Surprisingly enough, you can do that with Permissions!

Build it the lazy way.

One of the best parts of Apple’s iOS app environment is attention to user privacy — helped along by strictly requiring apps to receive explicit permission from users to allow access to Contacts, Calendars, Location, and other protected resources. Apps are required to provide a description of why they want access to each protected resource they wish to utilize — indexed by a specific key in the Info.plist file.

The more or less current list of possible keys for iOS looks like this:

NFCReaderUsageDescription
NSAppleMusicUsageDescription
NSBluetoothAlwaysUsageDescription
NSBluetoothPeripheralUsageDescription
NSCalendarsUsageDescription
NSCameraUsageDescription
NSContactsUsageDescription
NSFaceIDUsageDescription
NSHealthClinicalHealthRecordsShareUsageDescription
NSHealthShareUsageDescription
NSHealthUpdateUsageDescription
NSHomeKitUsageDescription
NSLocationAlwaysAndWhenInUseUsageDescription
NSLocationUsageDescription
NSLocationWhenInUseUsageDescription
NSMicrophoneUsageDescription
NSMotionUsageDescription
NSPhotoLibraryAddUsageDescription
NSPhotoLibraryUsageDescription
NSRemindersUsageDescription
NSSiriUsageDescription
NSSpeechRecognitionUsageDescription

Recall that we’re handling this in our framework, and you’ll realize that all we need to do to assemble our list of relevant permissions is to look in our apps Info.plist for any of these keys! That’s pretty lazy!

For our forthcoming Saving Daylight app, we show a list of permissions like this:

You see that we have granted permissions to access Contacts and Location. But there are two items in the list of Permissions that are not in the list of keys above: iCloud and Notifications. These two are a little different.

You’ll want to know if the user is signed in to iCloud for a number of reasons — one being that signed-in users can read from and write to Apple’s CloudKit, while users who are not signed in can only read.

Notifications are special in that Apple provides the text shown to the user when permission to allow them is requested. In both cases, there is no key to be found. So these two special cases are always inserted into the list of Permissions.

Avoid Two-step Permissions Requests

It was fashionable for a while amongst iOS developers to provide two-step permissions requests: a preliminary request asking if the user was willing to grant permission, followed by the “official” Apple request. In retrospect this was a clumsy solution and ignored the downstream ill effects of the user denying permission on the official request.

A better approach is just to ask for permission when the user attempts to perform an operation requiring that permission. If granted, everything is fine. If not, present a dialog explaining that permission is required and offering to take the user to the correct spot in Apple’s Settings app to rectify the situation.

One Stop Shop

The Permissions section as presented here is a “one-stop shop” for everything permission related. The app user can see the status of all permissions, and change them if necessary. Here’s an example of that in action:

That’s all for Permissions. Next up: Settings 106: How to display in-app purchases and check for previous purchases.

To start at the beginning of iOS Examples Without Code:

Prologue 0

Settings 105 was originally published in iOS Examples Without Code on Medium, where people are continuing the conversation by highlighting and responding to this story.