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.

In the last few weeks I’ve been trying to catch up on SwiftUI – watching WWDC videos, reading tutorials. Not the new stuff that was announced 2 months ago though – but the things that people have been using for the past year.

Last June, like everyone else I immediately started playing with SwiftUI like a kid with a new box of Legos. In the first month I managed to build a sample Mac app for switching dark mode in apps. However, after that I got busy with some other things, and never really got back to SwiftUI until recently, so by the time the “version 2” was announced at the online-only WWDC, I’ve already forgotten most of it. So in order to not get this all mixed up, I decided to first remember everything about the existing version, before I look at the new stuff.

Back then, when I was watching all the videos and doing the tutorial, I was taking a lot of notes about all the components, modifiers and APIs you can use, every single detail I noticed on a slide. However, I was surprised to see how many of those things I wrote down don’t work anymore. After the first version that most people have played with and that the videos are based on, there were apparently a lot of changes in subsequent betas (especially in betas 3 to 5). Classes and modifiers changing names, initializers taking different parameters, some things redesigned completely.

I’m the kind of person who cares a lot about their digital privacy. It makes me very uncomfortable when I see ads on Facebook for something I opened on another site a moment ago, and I generally don’t like it when companies are learning more about me than they should, even if the effects of that tracking aren’t as obvious.

That’s why for example I’ve been trying to move away from Google services as much as possible (I use ProtonMail as my main email and Apple’s iWork for documents), I also started using Tresorit and iCloud1) for file sync instead of Dropbox. That’s also one of the reasons why I’ve always used some kind of ad & tracker blocker in my browsers – previously Ghostery, now I also use Brave and I’ve been experimenting with making my own ad blocker.

So it always makes me happy when Apple introduces another change to their OSes that limits the kinds of data that Mac and iOS apps can use without our permission. I especially liked:

• when iOS 11 introduced the “While Using” option for location access that was non-optional for apps
• the “Allow Once” option for location access in iOS 13
• permissions to things like camera, microphone or screen recording on the Mac

When I watch conference talks, I like to take notes – either on an iPhone or iPad when I’m in the conference room, or on the Mac when I’m watching online like in case of WWDC (I’ve never seen it in person). It makes it easier for me to remember the most important content from the presentation, and especially in case of WWDC notes I often come back to them to find some specific piece of information – WWDC talks are a very important part of documentation of how to use Apple’s APIs, sometimes (sadly) the only piece of documentation about the specific class or method that’s available.

I have a fairly large archive of those notes (around 20 from each year on average), usually just stored as one long note in the Notes.app, and I’ve been thinking for a while that it could make sense to somehow share them with the world. I have no idea how useful they will be for others, since I write them primarily for myself, they’re much more condensed than blog posts and basically written as just a “diff” from what I knew before, but I guess I won’t know until I try.

One problem I had with sharing the notes is that they’re written as completely plain text, something like this:

I was going through some saved links and open tabs from June recently while finishing the WWDC collection post. I found a lot of interesting quotes about SwiftUI, Catalyst and the future of Apple platform development, and I decided to steal the idea from @mjtsai and put them together in one place. It might be interesting to look at this 5 or 10 years from now…

As I’m writing these words, it’s the last day of November and the temperature has just dropped to close to 0°C here in Poland. But let’s move back to a better time for a moment, to the first days of June – the long days of warm sunny weather, inviting you to spend some time outside… and the huge pile of new stuff that Apple had just dropped on us on the WWDC keynote day, inviting you to try to frantically read and watch everything at once, and don’t leave the computer until you’ve read it all.

For the past 4 years I’ve been trying to cope with this crazy period by collecting notes from the WWDC talks, release notes, saving tweets, links to blog posts and so on, and organizing it all in a single ordered blog post. Writing things down this way is how I learn best, it helps me put together all loose pieces of information into a single picture, and gives me the peace of mind that I haven’t missed or forgotten anything important.

I usually finish this by July, but this year was different – first I got really hooked on SwiftUI and spent some time doing some experiments with it, and then I was busy working on and releasing my iOS content blocker app and doing some travelling. It didn’t help that the sheer amount of new APIs added this year was simply overwhelming.

So I finally got back to this in November, and I’m posting the list here on the half-anniversary of the 2019 keynote (yes, it’s really been 6 months already!) – hopefully it will still be of use to you.

< 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?