In a previous article, we described the new sense of freedom the LTE-enabled Apple Watch brought users, along with new issues developers need to be aware of. Access to LTE networks now makes it possible to leave your iPhone at home, which some users will appreciate. But it also creates situations developers need to wrangle with. Specifically when it comes to debugging a disconnected LTE Apple Watch.
Debugging is always a dicey issue, whether you’re bug-hunting on an Atari 2600 (yes, that was my first, I took on 6502 assembler one summer, for some crazy reason) an IBM PC, an iOS device, or an Apple Watch running solely on LTE. Those of us who have been developing for a while have enjoyed the evolution of tools to the point where we can, literally, “point and debug” using things such as Chrome inspector, and other modern debug tools.
An Apple Watch running on LTE is a different situation. To debug apps on an iOS device, you can simply connect your device to your Mac, and use XCode to debug code on the Apple Watch. If your watch is paired with your iPhone you can also see logs from that. But the point of disconnected development and debugging is to be able to do it without being paired to an iPhone.
Local Device Logging
One of the easiest debugging methods (in many languages) is to simply log things to a console or an output stream. But since we’re on a disconnected device, it’s hard to view those logs easily using XCode (or another log viewer). What I’ve found works well is storing these messages in an object in memory, such as a MutableDictionary. If the app crashes, then of course you’ll lose these logs. Occasionally storing the dictionary as a file, or on every update, will solve that problem.
But logging the message is only half the story. After a bit of trial and error, I found the easiest approach to convey the necessary information was to add a screen in the Apple Watch App to view all the logged messages, along with a button to clear them. When something odd happens, I can go to my “logging” screen and review the messages to get some idea what the issue is.
Often, this gets you partly the way there. General purpose logging is great to help you quickly determine the broad scope of the problem, but more detailed logs are usually necessary to determine the precise cause of a bug. A few iterations of adding more logs, duplicating the issue, and reexamining the logs again, will usually reveal the answer.
Alert, Danger Alert
One way to make debug information available directly on an Apple Watch is via a simple alert. Very simple and hard to miss. This type of feedback is good for verifying major milestones in your app, such as receiving a new GPS update, a background timer firing, etc. The danger in using too many alerts is that even as a developer, I get annoyed at having to dismiss more than one or two alerts at a time, even though I appreciate the insight into what’s working with my app.
Another interesting way to store error/debugging logs is to make an API call with the necessary information. Even if you have an Apple Watch strapped to your wrist, testing the app, sometimes it’s nice to open a web browser and view logging information on a big monitor, instead of on a tiny watch screen. This also makes it possible to debug the same app with a pilot group, who may be using the app literally anywhere.
With the appropriate logging info, such as device id, diagnostic information, etc. it would be possible to extract the relevant logs based on the specific problem being investigated.
Today’s logging is tomorrow’s analytics
Frequently, logging is viewed as throwaway code—and it is, if it’s not done in a smart way. But done well, general-purpose logging will serve the purpose of displaying the activity in an Apple Watch App, and will shed light on problem solving.
Keeping the eye on the prize, it’s a small step from general-purpose logging to insight-revealing analytics. By adding debug logs at appropriate places—such as the initialization routine for each screen, the event handler on button taps, when the app goes into the background, etc.
This leaves a trail of events to debug issues, but this same trail can be used to examine app behavior to determine how an app is being used. Of course, every debug statement can’t be turned into an analytics event, but it’s a great way to leverage the work put into pure debug mechanisms as a way to monitor app use.
Many will ask, “So what’s the best way to debug an LTE app?” Like practically every other development situation, the answer is, “It depends on the parameters of your specific situation.” If you have a few key events to verify, an alert probably isn’t a bad way to go.
If you have remote users and you want to produce lots of debug information, but you don’t want to intrude on your Pilot users experience, some kind of network logging would work. Or maybe you’re developing against a local watch and you don’t mind going to another screen. IN this case, local logging to a different screen would work best.
Debugging is one of the harder processes to perform well. The most appropriate solution depends on the problem. Remember: every app has bugs and issues. So if you’re having difficulty debugging any mobile device or application, please don’t hesitate to reach out to us. The professionals at Propelics will take the time to completely understand your issue and apply a precise, accurate fix (and not a band-aid), resulting in superior apps for your organization.
Mobile Architect at Propelics