Testing a watchOS 2 app directly on the watch11 Oct 2015
This is a fairly long story with a lot of false trails, so if you just want the best way of testing on the watch I’d skip to the end
The app never seems to start on the watch
In my last post I mentioned that although the app worked fine in the Watch simulator, it was “slow” on the watch - in other words it never seemed to load at all.
I first assumed the problem was that the app initialization was taking too long, so I tried a few things including:
- Adding in-memory caching to the data model class to (maybe) improve subsequent reading of user settings post initialization
- Changing the data model to be held in the App/Watch delegate class so it’s only initialized once per app
- Moving the watch session connection code to run on a background thread so it didn’t block the UI thread loading the initial view controller
All of these changes made a difference in the load time on the simulator, but still no joy running on the watch :(
Pushing a TestFlight app to the Watch
I finally realised I must be missing something, so after doing a bit of research I found out that only signed versions of a Watch app will run on the actual device.
This made a lot of sense, so I followed the further advice of pushing an archived version of the code to the App Store, and then installing it on my phone (then watch) via a TestFlight install.
Now this actually worked, but it took me ages to actually get an acceptable archive working.
The problem was I was trying to reuse the code in both iOS and watchOS using a code library, and I just couldn’t get the archiving to work and sign the various bits of code correctly.
This is crazy complicated (for me at least) and to be honest whenever I’ve used a dynamic library other that through pods I’ve always had issues. Not sure if it’s me or it really is a complicated problem, but it seems the worst part of iOS development compared to most other languages and platforms.
In the end I gave up with the library approach on the watch, and just added the shared code files to the Watch Extension target directly which did the trick.
Solution: Add watch to provisoning profiles
Although the “TestFlight” solution worked, clearly it’s non-optimal as there’s a long iteration time to test any changes on the actual watch.
Some more research found this excellent post by Jared Sinclair on how to solve this problem by adding you watch to your provisoning profiles.
I won’t repeat Jared’s post here, and it’s sort of “obvious once you think about it” (which clearly I didn’t!), but I guess I did learn a lot along the various false trails - which is the purpose of the exercise :)
- Add a glance view
- Add watch complications
- Ship it!
N.B. All code can be seen on GitHub