Deployment of WatchKit Apps

The iOS Simulator is a fantastic piece of software—just ask anyone who’s ever tried to use an Android emulator. It is, however, a simulator, not an emulator, so you’ll want to test your app on a real watch sooner rather than later. Just as you’d do for any other iOS app, you’ll need to properly code-sign your app to deploy it to the watch. Code signing is the bane of many iOS developers’ existence, even experienced ones, so don’t worry if it doesn’t work for you on your first try—or tenth. Let’s look at the code-signing process as it relates to getting an Apple Watch app to run on a real Apple Watch.

Before it can run on any device, an app needs to have a valid provisioning profile. In short, the provisioning profile defines three things: which app the profile is for, who is allowed to digitally sign the app with a private key and certificate, and on which devices the final product can run. WatchKit adds a fair amount of complexity to the process. Your WatchKit extension and your WatchKit app must be code-signed. Luckily, if you set up everything through Xcode and are using an individual developer account rather than a large team or enterprise account, it should “just work,” though there are some gotchas.

Navigate to the project settings in Xcode and look at the General tab for WatchKit Extension Target; you’ll see that the bundle identifier has the suffix .watchkitapp.watchkitextension. If your provisioning profile is not a wildcard profile, it won’t be able to sign that, so you’ll need to create a separate app ID in the developer portal and issue a new provisioning profile and then repeat the process for the WatchKit app target. (If you’ve never created a provisioning profile or done code signing for an iOS app, it may be helpful to read the Code Signing documentation.^[4]) If you’ve created any other app extensions, you’ll be familiar with this process. Make sure that any devices you want to use are on all of the provisioning profiles in your app. If that sounds like a headache, it may be best to use a wildcard until you’re ready to submit.

When you’re all set with your app and ready to submit to the App Store, you’ll go about it the exact same way. Whether you’re making separate provisioning profiles or using a wildcard, your distribution profile is used to sign everything, package it up, and send it to the store. You can expect a more thorough review than you may have experienced before, since Apple will have to review both your iPhone app and your watch app. There’s no separate submission for WatchKit apps—they are, after all, simply packaged into your iPhone app—so a rejection of one means a rejection of the other. You’ll definitely want to test the heck out of your apps and be ready to respond to rejections quickly.