WatchKit apps are basically extensions that live on the iPhone but present interface on the Apple Watch.
That means the code for the WatchKit app also has to live in the iPhone app, and that can add an extra dimension to code signing — the process whereby the developer attaches their credentials to the app, a requirement for App Store distribution. What if any difference does this make for developers? Our own Nick Arnott, writing for his day job at POSSIBLE Mobile:
The problem here is that your WatchKit App and the parent app that it belongs to have been signed with different code signing identities after updating to Xcode 6.3. This validation step was occurring in Xcode 6.2, but build settings for the WatchKit App weren’t exposed in Xcode 6.2’s UI. Seemingly, the WatchKit app just inherited the build settings (including the code sign identity and provisioning profile) of the corresponding extension target. In Xcode 6.3, the WatchKit app target has its own build settings, and the newly-exposed build settings’ provisioning profile and code sign identity default to potentially problematic values (for us the provisioning profile went to Automatic, which changed the code sign identity to one that was unhelpful, resulting in a WatchKit app that was signed with a completely different identity than the parent app).
Way over my head, but if you’re developing for Apple Watch, go read it.