MacKuba

Update 01.03.2023: Updated Mastodon address - my previous instance has rather unexpectedly been shut down and I had to make a new account. I’ve decided to set up my own server to make sure it won’t happen again.

This is just a small update about Twitter and Mastodon, since things have been… very unstable and chaotic in the last few weeks, as you’ve surely noticed if you log in to these even occassionally.

Twitter has been my internet home for over 13 years now. I started using it when my colleagues from Lunar Logic showed it to me, and especially in the recent years it’s been my main source of information and news. It’s where I went to keep track of what was happening in the Apple/Swift world, find useful tips about UIKit, SwiftUI or Xcode, follow the news, rumors and dramas on the Crypto Twitter, and find out every day what important thing was happening in the world, including following the Covid pandemic and the Russian invasion of Ukraine this year.

Back in October 2014 I wrote a post about different styles of NSButtons.

That was in the era of OS X Yosemite and Xcode 6. I started researching what each kind of button available in Interface Builder was for, because I couldn’t figure that out from Xcode and the built-in documentation – I dug a bit into the Human Interface Guidelines, some older documentation archives and into Apple apps themselves. I collected everything into a long post that went through all the button styles and described what I could find about each one.

It seems that a lot of people also had the same problem, because the post turned out to be extremely popular. It’s around #3 in total page views on this blog, and 7 years and 7 major macOS versions later it still usually comes out #2 in monthly or yearly stats and still gets a couple hundred visits a month. Even with greatly improved documentation in Xcode and much expanded content in the modern HIG, there’s clearly demand for this kind of information collected in one place.

Back in spring I built a website that lets you browse charts of coronavirus cases for each country separately, or to compare any chosen countries or regions together on one chart. I spent about a month of time working on it, but I mostly stopped around early May, since I ran out of feature ideas and the pandemic situation was getting better (at least in Europe). The traffic that was huge at the beginning (over 10k visits daily at first) gradually fell to something around 1-1.5k over a few months, and I was only checking the page myself now and then. So it seemed like it wouldn’t be needed for much longer…

“Oh, my sweet summer child”, I kinda want to tell the June me 😬

So now that autumn is here and winter is coming, I suddenly found new motivation to work on the charts site again. But instead of adding a bunch of new features right away, I figured that maybe some refactoring would make sense first. I initially built this page as a sort of hackathon-style prototype (“let’s see if I can build this in a day”), but it grew much more complex since then, to reach around 2k lines of plain JavaScript – all in one file and on one level.

I started thinking about how I can make this easier to manage, and somehow I got the idea to try TypeScript.

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