Parenting Advice for New Programmers

I’d like to share some parenting advice if you’ll humour me.

My Mam shared this with me the day my first son was born and I think it applies to new programmers as much as it does to new parents.

These are both fields of endeavour filled with experts, some actual experts but more often self-imagined. 1

You will find yourself receiving advice from these experts, a lot. Some of it you may have actually solicited, more often though someone will have wandered into your conversation or overheard your child cry from a nearby restaurant table.

The advice is simply this: say thank you, and move on.

You’re free to ignore the advice if it is irrelevant or you know it to be wrong. The expert might be well meaning, so assume they are. The expert might be actual, but they almost definitely aren’t.

My Mam made clear I could apply this to her future advice, and every now and then I do. And you should apply it to mine because though I usually do mean well, I’m rarely an actual expert.

  1. Those people that believe the way that happened to work out well for them in their one specific situation is the one right way to do it for everyone in every situation.

Detecting When Your App Gets Backgrounded using Combine

The introduction of the Combine Framework provides a new (reactive) way to respond to system events such as your app entering the background.

In this example I have a CALayer subclass running some CABasicAnimations that need to be paused when the app gets backgrounded and resumed when the app becomes active again. In the layer’s init we attach a subscriber to the default notification centre’s publisher for the particualr events that we’re interested in. When attaching the subscriber we provide a closure that will be executed every time a new event arrives.

let bgSubscriber = NotificationCenter.default
   .publisher(for: UIApplication.willResignActiveNotification)
   .sink {
      _ in


let foregroundSubscriber = NotificationCenter.default
   .publisher(for: UIApplication.didBecomeActiveNotification)
   .sink {
      _ in


Let’s dig in a little to what’s going on here because it may not be obvious if you’re not familiar with Combine or NotificationCenter.

NotificationCenter predates Combine as a mechanism for broadcasting information (notifications) to interested observers. Every app gets a default notification centre which is used to broadcast system events such as those in the example here. Without Combine you can register to observe notifications and provide a selector to define what function to call when a notification is received.

With the introduction of Combine however, NotificationCenter added the publisher(for:object:) method which returns a Publisher that will emit values when notifications are broadcast.

A Publisher is how Combine represents a sequence of values over time that can be subscribed to. By calling sink(receiveValue:) we create a subscriber that will receive every value from the publisher.

The true power and utility of Combine isn’t seen in this example, but even still I don’t think it’s overkill to use Combine to provide a modern Swifty replacement for old fashioned notification observers and selectors.

A Note on Memory Management

To complete this specific example there’s a little more work to do. In my app I create many of these custom CALayer instances and at various points they get removed and new ones created in their place. With the code above as it is we’re preventing the layers from being deallocated when they’re no longer being used (because we captured self in the closure passed in to the sink call). To fix this problem we can keep a reference to the subscribers

private var appEventSubscribers =  [AnyCancellable]()

   appEventSubscribers = [foregroundSubscriber, bgSubscriber]


so that we can cancel them when the layer gets removed from its parent.

override func removeFromSuperlayer() {
        appEventSubscribers.forEach {


iPad OS or: Names Are Important

When I attended WWDC for the first time in 2010 the iPad was still brand new and not yet available in Ireland. Many had dismissed it as just a big iPhone, others (me, at least) had hyped it as A BIG IPHONE.

It ran iPhone OS version 3.2.

As we queued up before the Monday morning keynote we were all expecting the next iPhone and the next version of iPhone OS and we speculated about what new features we’d see. There was one seemingly minor announcement though, that nobody was expecting: the next version of the operating system would be called iOS 4, dropping the ‘iPhone’ to accommodate iPad. It made sense at the time and initially my only reaction was delight at how they managed to do it mid presentation, with nobody slipping up and using the new name before the announcement and nobody using the old one afterwards. In the years that followed though, as the ‘just a big iPhone’ opinions persisted and many developers put forth minimal effort in making their iPhone apps work on iPad, I came to think that not creating a separate identity for the iPad’s operating system was a missed opportunity, one that they finally rectified this year by renaming iPad’s operating system to iPad OS.

Perhaps making it incredibly clear that iPhone developers could make iPad apps made the previous OS naming scheme worthwhile up to a point but I believe making it clearer that iPad has its own OS, with its own interface, its own set of interactions and idioms that are distinct from iPhone will be a bigger benefit to software on the platform. OS naming is now consistent across all of Apple’s mobile devices - they are all based off iOS but Apple Watch runs watch OS, Apple TV runs tv OS and iPad runs iPad OS. These operating systems are not distinct in terms of technology or how we develop for them or who can develop for them, the distinction rather is in how the user interacts with them. Hopefully (and I believe it will) for iPad, this will result in more differentiated iPad software that takes advantage of its unique and powerful features.