Tag Archives: xcode

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 →

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 →

How to Script macOS Command Line Tool Notarization and Packaging for Distribution

A few posts back, I talked about the script I use to package macOS apps that I distribute outside of the Mac App Store. That script is designed to simplify the complex process of signing and notarizing not only the app itself but also the installer package its ships within. This is all made necessary by the ever more rigorous, annoying but necessary security provisions Apple is applying to macOS.

Continue reading →