macOS Posts

Since it’s been a good six years since I did one of these, here’s what I am using in the year 2022 as far as tech and tech-adjacent things.

Here’s a quick article about how to make a multiboot USB stick under macOS. These are useful in a lot of situations - such as for doing system installs or system rescues - because you can boot a wide variety of live OSs from a single stick. There are a lot of guides out there for doing this on Linux, and a lot of software for automating it on Windows, but not a lot of guides for doing it on macOS. Fortunately, it is pretty straightforward as the instructions will be broadly similar to doing it on Linux.

So one of the downsides to corporate life can be dealing with the deluge of email. While Slack is the new hotness for communicating inside companies, when dealing with outside people or organizations email is still the lingua franca of communication. But the downside to that is that you sometimes have to deal with repetitive emails. One in particular I have noticed over the last few years being more and more common is people reaching out to me wanting to get content on DealNews, or in some other way work with our marketing or business development teams. It is starting to get so common that I get it several times a month, and the reply is always the same: I don’t have editorial control over what content appears on the website, please reach out to these web addresses. But typing this out every time is annoying. There should be a way to automate this. After all, anything worth doing twice is worth automating.

So I have this older Dell laser printer, a B1160w. It was released back in 2012, but it is a totally fine home printer for when I occasionally need to print something and it still works great after all these years, so I see no compelling reason to buy a new one. But there’s a problem: macOS support. Namely, no drivers have been released for macOS since 2017. Starting with Catalina, Apple started requiring code signing for executables, and the official Dell driver has an executable in it that refuses to execute because it isn’t signed. And despite my best efforts, short of turning off Gatekeeper entirely, I was not able to get it to work. But the printer itself is fine; there is absolutely no reason to create additional electronic waste purely for software reasons. But thanks to open-source software, we have another options: CUPS.

I have an old iMac that has been sitting unused upstairs for awhile, that I decided to finally get rid of. Before putting it on Craigslist, like any good computer owner, I wiped the drives and went to reinstall the most recent version of OS X/macOS that this old machine would support. In this case, this was El Capitan. But when I went to install, I kept getting an error about the OS not being able to install. Popping the log window open, I found an entry called CSSMERR_TP_CERT_EXPIRED. This would seem to be a prime suspect.

If you have done and OS X/macOS development, especially any that predated the Mac App Store, you are probably aware of Sparkle. Even if you haven’t done any development, you have probably used Sparkle because it was basically the de facto method of providing update functionality in Mac Apps, and even to this day is still widely used on many apps distributed outside the official App Store. Updates are distributed to applications by means of an “appcast”, an extension of the RSS specification containing information about updates. RSS itself is based on XML, which means you can build them just like you would build any other published document. The problem comes when you start having a lot of updates in an appcast. Maintaining a large file can become difficult. But fortunately, using Jekyll collections, we can generate a single appcast using multiple files that are much easier to maintain. And, as an added bonus, we can use that same data to generate a download and changelog page from the same data.

It usually doesn’t take beginning macOS/iOS developers long to discover NotificationCenter and see it as the solution to every single problem of passing data around to different controllers. And NotificationCenter is great, but it has some downsides. Notably, it is very easy to introduce retain cycles (and memory leaks) unless you are very careful to track and free the listener when the object is released. This has bitten me on several occasions. In general, excessive use of NotificationCenter ends up creating a difficult to maintain app where it is not entirely clear what is responding to what and where.

Object oriented programming is great, but sometimes things don’t fit neatly into a superclass/subclass hierarchy. You may have a piece of code that would be needed in several contexts, but for technical reasons beyond your control you cannot merge them into a single hierarchy. Some languages have the concept of multiple inheritence, where a subclass can specifically inherit from several parents. But this has it’s own set of problems. Many other languages, however, solve this through the use of traits or mixins. These allow us to have a set of methods that are basically copied into the object at compile time. This way they can be used anywhere they are needed. Swift doesn’t have the concept of mixins or traits per se. But, starting with Swift 3, you can get very equivalent functionality using protocol default implementations.

Somewhat related to my previous post about responder chains, sometimes it is useful to be able to debug what all is in the responder chain at any given time. As a good rule of thumb, all ancestor views of a view are in that view’s responder chain, as well as (usually) the related controllers.

The responder chain is one of those parts of macOS and iOS development that may seem a little strange if you have not done any GUI programming before. Briefly, a responder chain is a hierarichy of objects that can respond to events. So, for example, a click or a tap might be passed up the responder chain until something responds to the action. But, the responder chain is more than just UI events. We can pass our own custom events up the responder chain as well!