Once you have your app running on your device, you begin to gain an insight into exactly how your app will feel and behave for your users, an insight much deeper than that which is possible using the Watch Simulator app on a desktop computer or laptop.
Spend a significant amount of time getting familiar with both your own app(s) and those of other developers, big and small. You need to develop an intuitive feel for users' expectations while using the Apple Watch (although it is entirely up to you whether you choose to fulfil those expectations or delight the user with something new). You may well find that firmly held opinions about what should happen and how can change significantly after a period of hours, or weeks, wearing the watch and using it to engage with your app.
Are your app's implementations of common use cases different from other apps? If they are different, are they better? Are they really better?
Note
Don't get too hung up on following the pack. If you genuinely believe that you have found something better to offer your users, don't let the nay-sayers tell you any different. On the other hand, don't forget to listen to user feedback. When people don't use your app, it sends a clear message, one that you'd be wise to catch early.
The value of spending some quality time with your app should not be underestimated—this really is an essential stage of development. The app needs to be beyond a certain level of completion to be usable, so this period of testing will inevitably lead to revisiting design and implementation decisions you made some time ago.
Be ready to tweak.
Pay particular attention to those scenarios that you can't replicate during development at your desk or anywhere you may set down your laptop (I prefer the beach, personally). Test how your app reacts to your walking outside of a wifi zone; test what happens when the app loses contact with its iOS companion and check if the app reacts to your walking back into range as you intended it to.
How does your app feel after a few days of use (presumably not continuous!)? Is the UI performing to expectations? Are the individual elements easily reachable? Does everything feel solid and 'snappy' enough? Is there anything that you feel is unnecessary and could be removed to make room for other features?
Of course, sooner or later, you will have had enough of asking yourself these questions and pine after a second opinion.
If you've not come across the term before, a beta tester is someone who tests a version of the app that is intended for release. It is not uncommon that you make a few unexpected and (usually unwelcome) discoveries once someone else starts to use the results of all that hard work.
If you can, try to find someone that will test your app for you. This could be difficult at the moment, since the Apple Watch is a new platform and not many people own one. But it's really worth doing, if you can. At the very least, hand your watch to a trusted friend or colleague and observe how they interact with your app.
Try to get a clear picture of the following points:
- Does the tester understand what the app is supposed to do?
- Does she know how to use the app?
- Is the navigation clear and can the user easily navigate back to the app's main screen?
- Do all of the features work as you expected?
- Do all of the features work as the tester expected?
And, whatever you do, don't take any forthcoming criticism personally. Tough though it is to hear that you haven't quite got it right, remember that this is your opportunity to fix things before your app reaches the broader public, the vast majority of whom will not take the time to give you any feedback at all, whether good or bad.
Large software projects will frequently allocate a quarter of the development time to beta testing and the accompanying fixes and tweaks, which is a good indication of how valuable this phase is.
Of course, you could test forever. It's also unlikely that you'll catch every single bug in your code. But at some point you will decide that it's time to release the app into the wild. Everything your app needs has been implemented and everything you have implemented seems to be working satisfactorily.
Note
The app doesn't need every feature you intend it to have in the long run, but you do need a coherent core feature set, the so-called minimum viable product (generally abbreviated in corporate circles to MVP, mostly because corporate circles love abbreviations). In addition to that core functionality, most projects will include a number of other features whose implementations were straightforward enough to include in the initial release.
If you're sure the app is ready, the testers agree the app is ready, and you've checked all you can check, you're into the final stretch; the preparation of your app for its submission to the App Store and the handover to Apple's review process.
Before moving onto submission, check the following points:
- The version and build numbers need to be the same on the target settings for the WatchKit App, the WatchKit Extension, and the iPhone's App. If you have written both apps from scratch, this won't be an issue, but if you are adding a WatchKit app to a previously released iPhone app, you'll need to bear this in mind.
- Remove, disable, or comment out all logging to the console.
- Any compiler warning messages should to be resolved. They won't prevent you from making a submission, but they are there for a reason, and now is a good time to make sure you are not making problems for yourself later on.