Solve two common issues that might catch you when developing an app for the Apple Watch.
Apple Watch is nearly there and I just can't wait to get mine.
I've been busy with some Apple Watch projects in the last few weeks and experienced some glitches with the pre-released Software Development Kit Apple provided already in late 2014. Now that Xcode 6.2 is available for the broad public (get it in the Mac App Store for free!), I'll explain how to solve two common issues that might catch you when developing an app for the Apple Watch.
Debugging the iOS app while the WatchKit Extension is running in the simulator
As you might already know, there's some neat API in
WKInterfaceController (somehow the WatchKit counterpart to
UIViewController) that allows your WatchKit Extension to launch the hosting iOS app in the background to execute some code and get the result back:
+ (BOOL)openParentApplication:(NSDictionary *)userInfo reply:(void (^)(NSDictionary *replyInfo, NSError *error))reply
Read more about this in the WatchKit Framework Reference.
Apple advises you to basically put any heavy-lifting code or network requests to your hosting iOS application (you probably also want this because the code you want to use is already there and functioning), so that's an awesome API helping you out with that. At some point you're probably experiencing an issue or crash that you cannot explain, and want to debug what's happening while the WatchKit Extension executes that request. But how to do so?
Just launch the iOS app on the simulator now. In the small Watch simulator window, you should have your WatchKit App running, and in the larger iOS simulator window your iOS app should be up and running.
The debugger will then be attached to both your WatchKit Extension and the iOS app:
Now when you set up a breakpoint in your iOS app's code, Xcode (or the debugger) will break there as usual and you'll be able to debug your code as you're used to. Xcode usually automatically switches the debugger scope once a breakpoint is reached in a specific target, so there is no need to manually switch the debugger's context.
Note that you have to manually attach the debugger as explained above each time you're re-launching your WatchKit App as this will kill the currently running processes in the simulator.
Codesign the WatchKit App and Extension
xcodebuild) will probably crash your codesigning party before it even started: You might encounter this little issue while packaging and signing your app with the command line tool
CodeSign error: code signing is required for product type 'WatchKit App' in SDK 'iOS 8.2'
There's luckily an easy way to fix this, however it requires that you have Xcode 6.1.1 installed (yes, the Xcode that does not know about WatchKit at all, download here):
Open your project with Xcode 6.1.1, and navigate to your WatchKit App target. Xcode will probably display a weird icon for this target as it does not know it is WatchKit-related. However, that's the reason why it offers us the option that misses in Xcode 6.2 yet: Setting up a codesigning identity with this target.
In the Build Settings tab of the targets preferences search for Code Signing Identity and set up the same codesigning identity that you use for the iOS app and WatchKit Extension, for all available build types (probably Release and Debug). Save your Xcode project and close Xcode 6.1.1.
When trying to build and package your app again with
xcodebuild, it should now successfully build and sign your iOS app, the WatchKit Extension and WatchKit App.
In case you ran into one of the issues explained above, I hope this article helped you solving them. Please let me know about any additions or corrections from your side. I can't wait to see your awesome Watch Apps!