MacKuba

Since my update to the iOS version of Banner Hunter was rejected by app review, the app’s been in a kind of Schrödinger state, both dead and alive. It’s still selling those few copies a week, and I’m updating the blocklist, but I’m afraid to make any updates to the Mac app now… So since then I started looking for some other ideas for new apps I could build instead.

One thing I started working on is a Chrome version of Banner Hunter. I wasn’t really planning to do it before, but since Apple pushed me now… I might as well give it a try. I have no idea if it’s possible to make any money on Google Store, since the vast majority of extensions are free, but we’ll see. The main part of the app is done, but I need to work on the non-technical parts like graphics and copy, and it will probably have to wait until late summer at least.

I’ve got another idea though which has kind of come up by itself, which is… to build an ad blocker for Safari.

(TLDR: here’s the landing page.)

I’ve been tracking the growth of the new coronavirus ever since it first appeared in China in the last week of January, and even more since it spread to Europe around mid February. Initially I’ve been looking mostly at the popular ArcGIS dashboard made by Johns Hopkins University that everyone is probably familiar with.

However, I really wanted to see some charts showing how the numbers grow in each country separately, since just seeing “8000 in Italy” doesn’t tell me much if I don’t remember how much it was yesterday. At that point it wasn’t possible to see that kind of information on the dashboard, and I couldn’t find any other source that showed that in an accessible way.

But then I saw a mention in the footer on the dashboard that the authors have shared all their data (including past numbers) in a GitHub repository in the form of CSV files. So of course I decided to do what always comes to my mind when I have a problem to solve… build a new project :)

And that’s how the Coronavirus charts site was born.

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.

I spent a large part of last week learning and playing with SwiftUI. So far it’s been pretty frustrating at times since I kind of feel like I forgot everything I knew, but I’m also very excited about where this will lead us. I’ve summed up my first impressions in the “Thoughts on SwiftUI” post last week.

At the moment most of the available examples show how to use SwiftUI in iOS apps, but I wanted to see how it would work on the Mac (in AppKit), since it’s kind of closer to my heart (hint: look at the domain name :).

And I had an idea: last year, when I was playing with the new Dark Mode in macOS Mojave I had a plan to build a simple app that would let you override the appearance in specific apps using the NSRequiresAquaSystemAppearance setting. I started working on it, but I got stuck while figuring out the complex NSTableView API which I had no experience with, and I gave up.

So, how about I give it another try now, but with SwiftUI? I don’t really need such app myself (I only use light mode), and I’m pretty sure I’ve seen other similar apps last year, but this seems like a perfect way to try out SwiftUI on the Mac - and to see if it will be easier to get the table view to work…

Update 15.08.2020: I’ve updated all code to work with the latest (stable) version of SwiftUI, adapting it to all the changes that were made to the API in last year’s later betas.

Like everyone, I was shocked by Apple’s surprise reveal of SwiftUI at WWDC last week. We’ve heard rumors of some kind of declarative, multi-platform framework coming sometime in the future, but I don’t think anyone expected we’d see it so soon. This seems like a huge change, a beginning of a completely new chapter for app developers on Apple platforms. I’ve watched most of the session videos about SwiftUI and I’m incredibly excited and eager to start using it in practice.

Here are some first impressions and thoughts about SwiftUI after reading about it and playing with it for a few days:

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

I’ve used several website analytics services over the years, including Statcounter, W3Counter, Clicky and Gauges (Google Analytics always seemed kind of too complicated and pro-focused for me). I don’t really need any complex functionality – just show me the number of visits in a given period, which pages were popular, what parts of the world people come from, what browsers/devices they use, and who links to me – so I was mostly satisfied with these products. The difference was mostly the friendliness and readability of the UI.

However, in the recent years, with the EU cookie law first and now GDPR, I started thinking about using something that allows me more control over the data and lets me avoid the dilemma of what kind of disclaimers I’m technically supposed to show on my site. Showing one of those idiotic “cookie banners” obviously isn’t an option since I’ve devoted so much time and energy fighting them, and I don’t think there’s a single person who actually wants to read them, but still, am I breaking some laws by not having one? I really don’t want to think about this.

I found Piwik (now Matomo), which is a self-hosted analytics service, a couple of years ago – but I didn’t have time to research it properly and set it up on my server until now. It eventually took much more time than I planned (and that I’d like to admit), partly because of my specific setup, partly just because of my own personal requirements and the perfectionist approach… So I wrote down all the steps just in case I need to come back to this again later, and I’m sharing it with the hope that it will save someone else some time.