MacKuba

< Previously on WatchKit Adventure…

Two weeks ago I posted the first part of a tutorial about how to build an Apple Watch app UI using WatchKit, using a WKInterfaceController and a storyboard. We’ve built the main screen for the SmogWatch app, showing a big colored circle with the PM10 value inside and a chart showing data from the last few hours.

Here’s the second part: today we’re going to add a second screen that lets the user choose which station they want to load the data from. So far I’ve used a hardcoded ID of the station that’s closest to me, but there are 8 stations within Krakow and the system includes a total of 20 in the region, so it would be nice to be able to choose a different one.

(I initially wanted to also include a selection of the measured pollutant – from things like sulphur oxides, nitrogen oxides, benzene etc. – and I’ve actually mostly implemented it, but that turned out to be way more complex than I thought, so I dropped this idea.)

The starting point of the code (where the previous part ends) is available here.

< Previously on WatchKit Adventure…

This is the third part of my series about building a WatchKit app that shows current air pollution level on the watch face (it started here). In this episode, we’re going to build the app’s main UI. I will be building on top of some data handling & networking code written in the previous episode about complications, so if you haven’t seen that one, you might want to at least skim through it to get some idea about what this is about. Browse through the WatchKit category to see the whole list.

We’re venturing into a somewhat uncharted territory now… The WWDC talks about WatchKit are an amazing source of information and they’re great to get started (I definitely recommend watching them, especially the earlier ones, from 2015 & 2016), but once you actually start building things and run into a problem, there’s surprisingly little help available. Even StackOverflow isn’t of much use. There aren’t many books out there either that are up to date – I got one from raywenderlich.com, but it doesn’t really answer the hard questions, and it wasn’t updated since watchOS 4; Paul Hudson has another, and that’s pretty much it.

I’ve tried to figure out some things myself, but some questions are left unanswered. If you know how to solve anything better than I did, please let me know in the comments.

< Previously on WatchKit Adventure…

This post is the second (or technically third) part of my series about building a WatchKit app that shows current air pollution level on the watch face. If you haven’t seen the previous parts, you might want to at least take a look at the intro.

Last time we’ve talked mostly about the general architecture of a WatchKit app. So logically it would now make the most sense to start with the main part of a watch app, the main app UI. After all, this is the only part of the app that’s required – both notifications and complications are optional if you don’t need them. This is what people normally think of when they talk about “an app”.

However… the whole thing started with me wanting to see the level of air pollution right there on the watch face, as quickly as possible. One of the three main rules of watchOS design is that apps should be glanceable, which means that you should be able to glance at the watch and see the information you need in as short time as possible, ideally within a couple of seconds at most – and a complication lets you see this information much much faster than the main app UI accessible from the app launcher.

It was also mentioned during at least one presentation that unlike on iOS, here the main UI does not need to be the most commonly used part of your app, if notifications or a complication make more sense for your use case. It can very well be something that users only fall back to sometimes when they need to see more detailed information or perform some actions.

So, why don’t we skip the view controllers for now and just build a complication?

Update 03.07.2019: watchOS 6 has changed a lot of things that I’ve written about here, so I went through the post again and updated all parts that got out of date.

< Previously on WatchKit Adventure…

For some reason, after watching WWDC talks mentioning watchOS in the last few years, I had this image in my mind that almost every version changed everything in how apps are built. I remembered something about native and non-native apps, two different types of app schemes in Xcode, and some diagrams of pieces moving from one box to another, on more than one occasion. This all sounded confusing, and I think that’s one reason why I was discouraged from starting, because I imagined it would make it hard for me to catch up with all of that.

As it turned out, this wasn’t really true. Well, not until watchOS 6 at least 😉

Ever since I saw the first Apple Watch announced on stage, I wanted to learn to write apps for it. I bought my first Watch half a year later, when they finally appeared in Europe, with that thought in mind. You can probably guess how that went…

I now have on my wrist my second Apple Watch (Series 1), bought two years ago after I smashed the screen in the first one. And to this day I haven’t written a single line of code for watchOS… This is actually one of many things that have been on my ToDo lists for literally years, that I often think about, but never actually find time to do. Procrastination is a terrible thing.