The Most Important Things to Understand About Certificates & Provisioning Profiles

“Finally, the provisioning profile is for testing only, right? The distribution cert is what allows me to get the app released?”

Certificates and Provisioning Profiles have been a perennial source of developer confusion and frustration. A lack of easy-to-understand documentation from Apple on this topic adds to the problem. But it is still very important to learn about these topics as an iOS developer.

“I know this is a lot of questions but I feel overwhelmed and don’t know where to start, I’m currently trying to read through the documentation but there’s so much I don’t understand. Any help would be greatly appreciated.”

All developers will eventually run into needing to use and understand these, it is a requirement. You will save yourself a lot of frustration and make sure you don’t delay submitting your app by understanding the purposes for certificates and provisioning profiles.

“This is frustrating as it is holding my app’s launch back”

One of the worst things about these issues is that if they appear, it is almost guaranteed to happen at a stressful time: submitting your app to the store, trying to meet that important launch deadline, or delivering a crucial bug fix to your customers. This is the time when issues with your certificates or provisioning profiles might appear.

So save your future self from all that stress and worry by getting an understanding of these now, and you can thank yourself later 😇

Notes: This article will focus on regular Apple Developer Program accounts. The Enterprise Program is a different story. The focus will also be on apps for iOS (and therefore watchOS). Apps for tvOS are very similar. Apps for macOS have some important distinctions, but much of the understanding still applies.

Certificates

Certificates provide many assurances for the app builds you create. There are two that are important to point out here:

  1. Certificates assure that your app was built by you or a team member. It is therefore important to protect the Signing Identity (private key) for your Certificates.
  2. Certificates are used to guard against the code of your app being changed after you build it. This is known as code signing. If the executable code of your app is modified after code signing, the signature will no longer be valid, and iOS devices will know not to run the code.

iOS App Development Certificate

Also known as the “Developer” or “Development” certificate.

This certificate is used to sign code in order to run it on the testing device connected directly to your Mac. Each developer on a team will get their own certificate. If that developer has multiple Macs you can share the same Developer certificate between those computers.

Because you will use this daily in your testing, it will immediately be brought to your attention if anything is wrong. Developer certificates expire one year after creation. When it expires, it doesn’t have any impact on your apps in the store or your ability to submit apps to iTunes Connect. You will need to create a new one to continue testing on your development devices, but it is fairly straightforward to do so. Xcode now even includes a one-click button to do it for you you.

App Store and Ad Hoc Production Certificate

Most commonly known as the “Distribution” certificate.

This certificate is used in a couple situations: for testing your app builds in an Ad Hoc manner; and for submitting builds to iTunes Connect for both testing on TestFlight and submitting for review to be approved for sale on the App Store. (More info on both Ad Hoc and submitting to iTunes Connect below.) Just like a Developer Certificate, a Distribution Certificate will expire one year after it is created. It is a good idea to stay on top of your Distribution Certificate before it expires. You will get a scary-sounding email from Apple 30 days before that happens, but don’t worry. More information on that here: http://bradfol.com/2017/01/ios-distribution-certificate-is-expiring-what-do-i-do/

Distribution Certificates are shared by the entire team. Most of the time you will have a single Distribution Certificate that is used for all apps and all developers that have permission to submit builds to iTunes Connect.

Provisioning Profiles

Provisioning profiles store a configuration of settings that allow your app to launch in certain circumstances. Depending on which stage of app creation you are in, different provisioning profiles will be needed.

In most cases Xcode now has the ability to create or update provisioning profiles for you. It is still important to understand what is happening. When Xcode does perform an action on your profiles, I would recommend that you log into the Certificates, IDs, & Profiles tool in the Developer Account website and take a look at the result. That tool will allow you to see and inspect all profiles created by Xcode (in addition to the ones created manually).

iOS App Development Provisioning Profile

This essential provisioning profile is used for the day-to-day development process of build and running your app on a device connected to your Mac.

Use this provisioning profile to specify which development devices you will be using to sign and run development builds of your app. This is used when you are running a development build while connected directly to your Mac. Xcode will maintain a debug connection to the app, proving live logs and further inspection tools of your running app.

The provisioning profile must match three things to be correct: the Developer Certificate that matches what is on your Mac, the App ID for the app you are trying to build, and the devices you want to run that app on. Note that for two of those requirements (certificates and devices), this type of Provisioning Profile allows for multiple selections. For example, you could have a single Development provisioning profile that specifies the Development Certificate for two developers, as well as all the iOS testing devices that the team uses. If any of those three areas of requirement change, a new provisioning profile will need to be generated. The most common example is wanting to test the app on a new development iOS device. If you get a new device you want to test, you will need to edit the provisioning profile and include that new device. The newly generated profile effectively replaces the previous one. In many cases, Xcode can automatically manage the process of generating new profiles for you. It is performing these same steps for you, and the same requirements apply.

App Store Distribution Provisioning Profile

This is a very important Provisioning Profile. It is used each time you upload a build to iTunes Connect. That includes uploading for both the purposes of testing using TestFlight, and submitting to App Store review.

There are two requirements that go into this provisioning profile: the App ID, and the Distribution Certificate. When Xcode uploads your app build to iTunes Connect, it includes a copy of this provisioning profile. The iTunes Connect system then checks that the App ID and code signing of your app build match what is specified in this provisioning profile. Additionally, that certificate must be a Production (a.k.a. “Distribution”) certificate, not a Development Certificate, and match what is specified in the provisioning profile.

Ad Hoc Distribution Provisioning Profile

The purpose of this Provision Profile was to allow developers to send their app out to a group of testers to receive feedback on the app before it is made available publicly on the App Store. However, this method of testing pre-release app builds has seen reduced importance over the last few years, due to the integration of TestFlight into iTunes Connect. TestFlight meets these testing needs for most developers, and takes much less time to manage than Ad Hoc Distribution.

As the name might suggest, “Ad Hoc Distribution” allows your app to be distributed in an ad hoc manner. To be more specific, the app build can be distributed to only the list of devices included in this Provisioning Profile, and only for the App ID specified in the profile. The build must be code signed using your Distribution certificate, also matched to this provisioning profile. Anyone with experience doing this type of app testing knows how much headache and difficulty it caused. Again, for most developers, it is now a better idea to use TestFlight. But this option still exists if you need it.

I just received an email that my iOS Distribution Certificate is expiring. What do I do?

First of all, don’t panic. If your app is already for sale on the App Store, this email has no impact on that. Your app will remain up for sale even if your Distribution Certificate expires. It’s going to be OK.

It’s a scary email, but it won’t cause anything to break with your existing apps on the App Store.

What is the iOS Distribution Certificate for?

The purpose of the iOS Distribution Certificate is actually pretty narrow, it is just used for submitting a build of your app to Apple’s iTunes Connect system so that it can be reviewed and processed for sale on the App Store. The time it is needed is just for the submission and review of an app build by Apple. Once Apple approves the app, and it is made available for sale on the App Store, it doesn’t matter if your iOS Distribution Certificate has expired.

What do I need to do?

So while the email sounds extremely urgent, it only really impacts your ability to submit new builds of your app. Obviously this is important, but it does not change what is already on the App Store.

What needs to be done is to create a new iOS Distribution Certificate on the computer that you use to submit app builds. There are two options to create it: using Xcode, or using the Member Center web tool.

Xcode now has an automated way to do this that handles all the details for you.

  1. Open Xcode preferences, select the Accounts tab.
  2. In the left column, choose the Apple ID for the account that you would like to create an iOS Distribution certificate.
  3. In the right column, select the team for the account. (If your legal entity is a company instead of an individual, there might be more than one option. Choose the one with the “Agent” role.)
  4. Click the “View Details…” button.
  5. Under Signing Identities, there will be list of certificates you can create for that account and role.
  6. Click the “Create” button next to “iOS Distribution”.

If the Create button is grayed out, go back to steps 2 and 3 to make sure you have selected the appropriate account and role for the expired certificate.

If you prefer to do it manually, use the Member Center and follow the steps to create a Production App Store and Ad Hoc certificate.

  1. Go to the Apple Developer certificate management site: https://developer.apple.com/account/ios/certificate/ (You can also use this site to view and manage existing certificates.)
  2. Click the plus button on the top left.
  3. Under the Production section, choose “App Store and Ad Hoc”.
  4. Follow the instructions to use the Keychain Access app on your Mac to create a Certificate Signing Request and upload it to the site.

How can I debounce a method call in Swift 3?

Debouncing calls is great for situations where a repeating user action can cause network requests to happen. The problem is that the user’s actions can generate many requests in a short period of time, which can be slow to respond on a cellular network.

This also applies to other types of wireless communication, such as BLE.

Here is an implementation of a Debouncer class in Swift 3. Github Gist link

import Foundation

class Debouncer {

    // Callback to be debounced
    // Perform the work you would like to be debounced in this callback.
    var callback: (() -> Void)?

    private let interval: TimeInterval // Time interval of the debounce window

    init(interval: TimeInterval) {
        self.interval = interval
    }

    private var timer: Timer?

    // Indicate that the callback should be called. Begins the debounce window.
    func call() {
        // Invalidate existing timer if there is one
        timer?.invalidate()
        // Begin a new timer from now
        timer = Timer.scheduledTimer(timeInterval: interval, target: self, selector: #selector(handleTimer), userInfo: nil, repeats: false)
    }

    @objc private func handleTimer(_ timer: Timer) {
        if callback == nil {
            NSLog("Debouncer timer fired, but callback was nil")
        } else {
            NSLog("Debouncer timer fired")
        }
        callback?()
        callback = nil
    }

}

The Debounce class is straight forward to use:

// Create a Debouncer with a half-second time interval
let debouncer = Debouncer(interval: 0.5)

debouncer.callback = {
    // Send the debounced network request here
    print("Send network request")
}

func textDidChangeDelegateMethod() {
    // When the user performs a repeating action, such as entering text, invoke the `call` method
    debouncer.call()
}

PS: Interestingly, the term debounce comes from electrical engineering. “Bouncing is the tendency of any two metal contacts in an electronic device to generate multiple signals as the contacts close or open.” (http://whatis.techtarget.com/definition/debouncing) So a de-bouncing circuit cleans up this bouncing between the signals, by providing a single signal.

How to calculate tax in Swift

When performing any type of financial calculation, it is best not to use floating point numbers. Performing arithmetic in base 10 will allow you to avoid unexpected errors in how floats represent some decimals. Fortunately, Apple provides the NSDecimalNumber class to handle calculations using base 10 arithmetic.

Tax calculation example:

let price: Int = 15 // $15
let priceDecimalNumber = NSDecimalNumber(integer: price)

let taxPercentage = NSDecimalNumber(string: "0.09") // 9%

let tax = priceDecimalNumber.decimalNumberByMultiplyingBy(taxPercentage)
let taxDouble = tax.doubleValue // Retrieve the double value

More information about floating point arithmetic:
http://floating-point-gui.de/basic/