MacKuba

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?

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.

For the last 3 WWDC’s I’ve been collecting ordered lists of all new features and APIs added in the new releases of Apple’s OSes, either announced in the keynote or one of the talks, or in release notes, or just discovered by some API diff spelunkers :) I’m pretty late with that this year, because I spent some time instead on a couple of longer posts about notifications and Dark Mode, but here it is, just in time for the final launch and the September event.

In general, there seems to be noticeably less changes this year, which is good in a way – it should be easier for us to learn the new things and update our apps. For a moment it even looked like the “macOS SDK” section could be longer than the “iOS SDK” this time with all the Dark Mode changes, but iOS got a boost from the notification APIs and finally finished 3 lines ahead of macOS :)

If you want to learn more about any given topic, the best way is probably either to look it up in the shiny new Apple Developer Documentation (redesigned last year), or watch the recorded WWDC talk videos – either on Apple’s site, or using the great unofficial WWDC Mac app.

Previous editions are available here:

• WWDC 2017
• WWDC 2016
• WWDC 2015

One of the things that caught my attention in the WWDC videos I watched last week were the improvements in the notification system, meant to on one hand give more control over notifications to the users and make them a bit less overwhelming, and on the other hand make them more useful by allowing them to be more interactive.

I’ve tried to sum up here all the changes related to notifications that I’ve found – there’s nothing here that you can’t find by yourself in the videos, but I figured it’s worth putting it all in one place in a concise form.

Most of the below applies to both iOS 12 and watchOS 5.

Apart from a whole bunch of new frameworks (see the whole list here), iOS 11 also makes some major changes to existing APIs. One of the affected areas is location tracking. If your app only uses location while the app is in the foreground, as most apps do, you might not have to change anything at all; however, if it’s one of those apps that continuously track user’s location throughout the day, you should probably book some time this summer for making some changes in how you do the tracking and testing possible usage scenarios.

This post is mostly based on the “What’s New in Location Technologies” talk from WWDC, so if this topic is relevant to you then you should definitely watch the whole talk.

It’s that time of the year again – if you’re like me, you’ve probably spent a lot of time in the last few weeks following everything that’s been announced at WWDC, digging into release notes, watching WWDC talks and playing with some cool new stuff. And as usually, the amount of new things to process is pretty overwhelming.

So like in the last two years, I’ve prepared a nicely organized list for you of all the things I could find from various sources: all the user-facing features in macOS/iOS/watchOS/tvOS, and all new frameworks, APIs and improvements in their respective SDKs and Apple’s developer tools.

To get more info about any specific thing, follow the links above the sections to Apple’s developer site and the “What’s New” documentation, download the release notes from developer.apple.com, and of course use the freshly redesigned unofficial WWDC Mac app to watch the talks that you’re interested in.

If you want to catch up on last year’s notes (e.g. to see what you can use if you drop iOS 9 support in your app), check out these posts:

• WWDC 2016
• WWDC 2015