Today was going to be about so much else, but instead I found myself mêléeing with Apple’s build system.
I have a script I’ve been using very successfully for some years that automates the build process for my CLI apps. It builds a universal binary containing both ARM64 and x86-64 code, wraps it into a macOS installer package and submits the result to Apple’s notarisation service. One command in Terminal and it’s all done, or occasionally you get an error message.
Continue readingWith time on my hands and having noted that rather a lot of iOS and macOS engineering jobs now emphasise SwiftUI skills, I thought it was high time that this old AppKit hand spent some time learning how to implement Swift’s ‘new’ declarative UI construction framework.
You might very well wonder why it has taken me so long. SwiftUI has been around for five and a half years – it debuted at Apple’s Worldwide Developers’ Conference in 2019. Why have I not tackled it before?
Continue readingMy open source images-to-PDF utility, pdfmaker, makes use of Apple’s PDFKit. While this partnership works as it should, just one aspect bothered me: PDFKit warnings and errors don’t bubble up to the calling code, but are piped via STDERR. The upshot: anyone running pdfmaker may see messages that it hasn’t issued. pdfmaker is a CLI tool, but I can’t just redirect the output to /dev/null — you’d lose everything, not just PDFKit’s grumbles. Instead I had to figure out how to sink PDFKit’s output even though it wasn’t coming via pdfmaker. Here’s how I did the pipework.
MNU is a tool I use every time I work on my computer. It’s a menu bar utility that allows me to trigger command line scripts and tools with a couple of mouse clicks. Despite its utility to me, I haven’t given it any love for some time, so I recently remedied that with a spring clean of the code. I also added a new feature: custom keyboard shortcuts.
I connect to my Mac many USB devices that communicate over a serial (UART) bus to send debug information to the host or to receive data and code. You know, Raspberry Pi Picos, Adafruit Feathers, FTDI cables — that kind of thing. Often I have more than one connected. Is there an easy way to see what’s connected without listing /dev every time and to remember connected devices’ paths?
It’s June once more, and time for Apple’s Worldwide Developers’ Conference (WWDC). This is a chance to learn about new functionality and, yes, discover initiatives announced at previous WWDCs that you completely missed the first time around. A case in point: Apple’s revamp of how apps are notarised at the command line, which was revealed at WWDC 21 but I only encountered this week.
Over the last few years I’ve released a number of command line utilities for macOS. I’ve always included online help within them, triggered with the --help switch, but I recently wondered how I might provide Unix Manual pages too. It would allow users to call up help with the CLI command man as well as a command switch. Belts and braces, perhaps, but I’m a completist and, more to the point, didn’t know how it was done and wanted to learn.
All three of my PreviewApps — PreviewMarkdown, PreviewCode and PreviewYaml — got big updates this week. Headline features: significantly improved font, style and colour selection, across-the-range stability improvements, and faster PreviewCode theme preview presentation.
Version 1.3.0 of PreviewMarkdown has just been released. Its key new feature: you now have the option to view YAML front matter in Markdown file previews. This is really handy if, like me, you use a static site generator and use YAML to record content metadata at the top of your Markdown page files.
A couple of macOS releases or so ago, Apple introduced app extensions: self-contained modules that are bundled within apps to deliver functionality to the wider operating system. But how do apps and their extensions share information between themselves, in particular users’ preferences?
smittytone messes with micros 