After much struggling and some good advice, I’ve finally managed to get an Apple Watch App/Extension running on an actual watch. Here’s some follow-up to my previous post on code signing woes.
How to Provision an Apple Watch
An Apple Watch has to be provisioned for development use in much the same way as an iPhone or iPad.
Pair your watch with your iPhone.
With both devices powered on and the watch nearby, connect your iPhone to your development Mac and launch Xcode.
Open the Devices window.
Copy the device identifier for the watch.
At the iOS Developer Center, add the watch to your development device list the same way you would add an iPhone or iPad.
Update any existing (relevant) provisioning profiles to include the new watch. Download them and double-click them to install them via Xcode. To be safe, consider deleting the older versions of the affected profiles from Xcode and from your phone prior to double-clicking the new profiles. See below for how to do this.
How to Install a Watch App/Extension on an Actual Damn Watch
When your watch app Xcode project is properly configured it will have a minimum of three targets:
- the host app
- the watch app
- the watch app extension
All three targets require the following:
- a unique app ID for that target
- a code signing identity (applies to all targets)
- a unique provisioning profile for that target.
If your app also has other extensions (like a Today widget, etc.), or if it uses a custom framework to share code between all targets — you may have many more targets. Other extensions require the same things as the watch app/extension above. A framework only requires a code signing identity.
Create app IDs and provisioning profiles at the iOS Developer Portal. Download and install the new profiles as described above.
Your app IDs will look something like this:
After having created and installed all the new profiles for all your required targets, specify the code signing identities and provisioning profiles using the same methods I recommended in my previous code signing post. Make sure that you have entered all the app IDs in their respective
Info.plist entries, and that the paths to the
Info.plists in the Xcode build settings for each target are correct.1
After all this is complete, consider relaunching Xcode, your iPhone, and your Apple Watch to eliminate bugs related to caching issues (this happens a lot with Xcode in particular).
If you’re running out of ideas on what could be going wrong, try the following:
Look at the console logs on your iPhone. This OS X app by Lemon Jar is the easiest way to do this. I was able to find a little bit of info about an installation verification error in this way.
Look at the build logs in Xcode. Search for
Sign(the word sign followed by a space) to see just the signing steps. Highlight a step to show the expansion button, and expand the log to see extra information. This is how you can verifiy which profile and signing identity were used for each target.
A Note About Entitlements
You are likely going to want to share application data between your host app and its extensions using a shared app group directory. This requires several things:
Enable the “App Group” entitlement for all of your app IDs (not just the host app, but all extensions, too) on the developer portal. I’m not sure, but I think you might need to regenerate provisioning profiles after adding this entitlement.
Update the Xcode “Capabilities” section for the host app and all extension targets to make sure that “App Groups” is enabled and the correct group name is checked.
By this point, Xcode should have automatically created
.entitlementsfiles for all your targets, and included them in the appropriate line in the
Code Signingsection of the build settings for each target. Take heed: do not specify an entitlement for a watch app, only for a watch extension.
Inspect your entitlements files to make sure they have the correct app group name(s). Also make sure that the paths to the entitlements files are correct in the build settings for each target. These can get out-of-sync with the actual path to the files on disk.
How to Delete Provisioning Profiles from Your Development Mac
Prior to getting started, I suggest doing some provisioning profile house cleaning. This process is so hard to discover that I’ve changed my mind about suggesting you just Google the answer. Here’s how to delete old profiles from your development Mac using Xcode 6:
Go to Preferences > Accounts. Select an Apple ID on the left, and double click the team name in the list of teams on the right (there may be only one team).
A modal sheet appears with a list of provisioning profiles installed on your Mac. Right click a profile and choose “Show in Finder.”
From the Finder, you can trash the profile as you would any other file. Bear in mind that the containing folder contains provisioning profiles from all of your developer accounts on your Mac, so take care not to trash the wrong profile.
Repeat as needed.
How to Delete Provisioning Profiles from Your iOS Device
It used to be possible to view and delete provisioning profiles directly on an iOS device via the Settings.app. I’m not sure which version of iOS changed this behavior, but now you’ll have to use Xcode in order to remove a profile.
Open the Devices window in Xcode.
Connect your iOS device and right click it in the devices list when it appears.
Choose “Show Provisioning Profiles”
Select a provisioning profile you want to delete, and then click the minus button.
Repeat one-at-a-damn-time as needed. Sigh. After a while your device may have many provisioning profiles, including numerous duplicates of the same profile as it gets updated with additional devices and certs, so this click-and-delete process can be tedious.
They must be manually updated if you reorganize the hierarchy of your project files on disk — something you might do when adding a bunch of new targets to your project. ↩