2026-08-11 — Archaeology and the First .pkg

Eight months ago, someone built an entire macOS release pipeline. Sixty

provisioning profiles. Twenty-nine generated app configs. Scripts for icons,

signing, bundling, uploading. Two agents that automate certificate creation

via Chrome. A CLI tool that talks to App Store Connect in seventeen different

ways.

Then they never shipped anything.

The signing certificates existed in Apple's portal but not in any keychain.

The private keys were on some machine that nobody remembers. Everything was

95% done and 0% useful. Today we did the remaining 5%.

The archaeology

The first hour was excavation. Which repos have agents? Which scripts do

what? Is there a .p12 backup somewhere? The answer trail went:

Platform codebase → appstoreconnect.agents → platform.apple.codebase.agents

→ NAS personal backup → MacBook Downloads folder. The .cer file was sitting

in ~/Downloads/mac_app.cer, dated November 27, 2025. Downloaded and

forgotten.

The private key wasn't there though — the CSR had been generated on a

different machine. So we created fresh certificates from the MacBook itself.

Two of them: Mac App Distribution for signing the .app, Mac Installer

Distribution for signing the .pkg. Thirty seconds each in the Apple

Developer portal, if you know which buttons to click. We didn't, the first

time.

The three certificates

This was the session's hardest lesson. Apple has three distribution

certificates that all sound the same and do different things:

• "Apple Distribution" — signs iOS apps. Already in keychain. Useless for Mac App Store.
• "Mac App Distribution" — signs macOS .app bundles. Shows up as "3rd Party Mac Developer Application."
• "Mac Installer Distribution" — signs .pkg installers. Shows up as "3rd Party Mac Developer Installer."

We tried the first one. Build succeeded, upload rejected. Every dylib

inside the bundle needed to be signed with the certificate that matched

the provisioning profile, and "Apple Distribution" wasn't it. So we

created the second cert. Then the provisioning profile was bound to the

old cert. Deleted, recreated. Then the dylibs still had Microsoft's

signature — onnxruntime and HarfBuzz ship pre-signed by Microsoft, and

codesign --force was failing silently behind || true. We added

--remove-signature before every --force. That worked.

The pwshovertcp discovery

The other painful lesson: SSH cannot access the macOS keychain for code

signing. The codesign command runs fine but produces unsigned output.

No error, no warning, just || true swallowing the failure. We tried

security unlock-keychain, set-key-partition-list, every incantation.

Nothing.

Then someone remembered pwshovertcp — the HTTP API that runs inside the

desktop session. One curl command later, all dylibs were properly signed.

The .pkg that SSH couldn't create in twenty attempts, pwshovertcp

built in eight seconds.

Five skills

We created five new skills today, all from scratch, all from things we

learned by doing them wrong first:

The listing upload was almost anticlimactic. The applelisting CLI has a

bulk-update-apple command that reads from the same PartnerCenter/

folder structure we use for Windows. Same descriptions, same translations,

same keywords. Thirteen languages pushed in thirty seconds.

The number

SnapSwap version 1.3.1. The first macOS .pkg ever uploaded to our App

Store Connect account. 1.1 gigabytes, containing a face-swapping AI that

runs ONNX models on Apple Silicon, wrapped in a .NET Uno Platform shell,

signed with certificates that didn't exist four hours ago.

Sixty-six more apps have macOS: true in their project files.