I was running into the same thing. Here's the exact sequence of steps that got it working for me. Connect your phone to your Mac and open XCode Go to manage run destinations, and unpair the phone, but don't tap on "Trust this computer" or anything else Unplug the phone from the Mac Go to Settings -> Privacy and turn off Developer Mode Restart the phone Plug the phone back in to your Mac Go to Settings -> Private and turn on Developer Mode (which will trigger yet another restart) Xcode should see your device now, and it should also show your watch as a disconnected device once it's done preparing your phone for development. DO NOT CLICK ON YOUR WATCH IN RUN DESTINATIONS On your watch go to Settings -> Privacy and scroll to the bottom. The mysterious Developer Mode should show up now Tap on it, and then turn it on. This will trigger a restart of your watch Once your watch has restarted make sure to look at it so it triggers the "Are you sure you want to turn on developer mode?" question. Say yes NOW click on your watch in Xcode Run Destinations. This will trigger it to prepare the device and download the run symbols If that doesn't work for you, then I apologize, but it's what got me finally up and running with it after a full day of futzing around 9)

Thanks Quinn! We unfortunately have no control over the server implementation of this, and iOS is the singular platform unable to parse the .p12 files coming in. I think we're going to end up pulling in OpenSSL to be able to parse them - I do already have SwiftANS1 as well as the Swift Certificates libraries which are indeed cool - just not able to handle the .p12 files. I'll get a bug report posted and reply back here with the number once I do. It is unfortunate that something literally named after the container it is parsing can't get the data structures without the identity, but that's how it goes sometimes. Thanks, Cory