Category Archives: Mac

PreviewCode 2 brings a new UI and source code line numbers

PreviewCode provides at-a-glance highlighted source code previews of more than 60 programming and scripting languages, and development configuration file formats. It makes use of macOS’ QuickLook mechanism: select a file and hit the spacebar to get an immediate preview of the file’s contents. It’s a handy way to view a file without opening it in an application.

PreviewCode 2 main window

PreviewCode also generates Finder thumbnail icons for all of those file types if you prefer something other than generic icons.

Continue reading →

Primal Scheme: when Xcode settings vie with each other for supremacy

In interesting follow-up to last week’s post about the Xcode build system. This week, while updating another of my macOS CLI utilities, I found my new build script was breaking. Why? It was attempting to create a macOS universal binary out of what I thought were two separate ARM64 and x86_64 builds but were in fact both… er… universal binaries.

About xcode

This occurred with pdfmaker. The script was changed based on my experience building utitool and dlist. What might account for the difference? Comparing the architecture-related entries in the Xcode Build Settings for pdfmaker and dlist showed no differences at all. Both utilities’ project files are to Xcode 16.0 specification too.

Continue reading →

Swift Fighting Man: How to duke it out with the Xcode build process and Win!

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 reading →

Unearthing macOS’ Uniform Type Identifiers

The Uniform Type Identifier — UTI for short — is an interesting means to map files to the type of data they contain. macOS uses UTIs to work out what kinds of file an application can open to view or edit. My Preview… apps rely on UTIs to indicate their interest in certain file types. The system uses that information to pass files to my application extensions when a user previews a file using QuickLook. Generally, they’re hidden from users.

utitool 1.2.0 in action

There’s a flaw in the system, however. A UTI might indicate the content a file might be expected to contain, but how does the system connect a file to a UTI? By using its file extension. But while UTIs are unique, file extensions are not, and this is where the trouble begins.

Continue reading →

How I went kicking and screaming from AppKit to SwiftUI… and why I plan to stay there

With 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 reading →

Retro text encodings and cross-platform compilings

Working 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 reading →

udev, I dev: unique identifiers and aliases for USB serial ports on Linux and macOS

An interesting comment on my previous post suggests using udev rules to give connected USB-to-serial adaptors their own, unique names. It works by setting udev rules to apply a symbolic link to specific devices when they are connected.

The approach, outlined in this blog post, works at the command line. This got me thinking: can I do the same in code?

Continue reading →

How to find the right Pi Pico board or retro tech connected to your Mac or Raspberry Pi

Recent work connecting old mobile devices — the Psion Series 3a and the Amstrad NC100 — to my Mac caused me to run into an issue with the script I use to determine the Unix device path of the USB-to-serial adaptor I use to talk to these gadgets. Long story short: I ended up converting a Z Shell function into a Swift CLI tool — and adding Linux support into the bargain.

Adafruit’s RP2040 board connects to the host via an integrated USB-to-serial adaptor (Image © 2021, Tony Smith)
Adafruit’s RP2040 board connects to the host via an integrated USB-to-serial adaptor
Continue reading →

How to intercept STDOUT and STDERR output in Swift CLI code

My 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.

Steel pope (c) 2024, Tony Smith. All rights reserved.
Continue reading →

Xcode 15.3 zaps Swift packages: here’s how you fix it

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.

Xcode and Swift icons
Icons owned by Apple
Continue reading →