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 readingWorking with old tech can take you to unexpected places and expose the quirks of modern coding systems. Case in point: old computers’ supported character sets and their impact on getting workable text when you transfer data across to a recent OS.
I came across this with my Psion Series 3a. I’ve been using it as a note-taking device while researching archive texts on the history of semiconductors. When I was done, I transferred the notes (a single Psion Word file) to a Mac and converted it using my Word2Text utility.
But the computer said, “No”.
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.
I have cd "${PROJECT_DIR}" ; agvtool bump set as a script in a number of my macOS projects’ Xcode schemas’ Build phases. The second of the two commands auto-increments the project build number on completion of the build. It continues to do so, but with Xcode 15.3* there’s a side-effect: it deletes the project’s Swift packages.
imageprep, my command line tool for batch-processing picture files, had a big update a week or so back — and now it has another one. With the second update imminent, I didn’t announce the first, 6.1.0, which I released to coincide with my post on writing command line utilities in Swift. That done, it’s time to shout about imageprep 6.2.0.
I’ve spent a lot of time of late working on several macOS command line tools written in Swift. So I’ve gathered together the key points I’ve learned while creating and updating pdfmaker and imageprep: some best practices and ways to deliver many of the features common to programs the run at the command line.
smittytone messes with micros 