DEV Community: Jackson

A green CI log and an empty TestFlight tab can both be telling the truth

Jackson — Tue, 15 Sep 2026 02:04:27 +0000

Here's a failure mode with no error message at all: your pipeline finishes, every step is green, and TestFlight just... doesn't show a new build. Nothing crashed. Nothing timed out. Nothing logged a failure. You just refresh the page and there's nothing there.

The reason is that App Store Connect's build processing happens in a completely separate, asynchronous system from whatever uploaded the binary. Your CI job's job ends the moment the upload call returns. Apple's own queue picks the binary up after that, and if it rejects it — a missing entitlement, a bad Info.plist value, whatever — that rejection happens entirely outside anything your pipeline was ever watching.

This is the one case on my list where the actual fix isn't a script change, it's an admission: you don't have visibility by default, so you have to go add it. A step that polls App Store Connect's own build-status API after upload and asserts on the result is maybe ten lines of code, and it turns "silently missing, investigate later" into "failed at 2:14pm, here's why."

I think about this every time I'm tempted to trust a tool's own exit code as the end of the story. The exit code tells you the command you ran finished. It says nothing about what happened to your output after it left your hands.

The three keychain errors that were all the same missing command

Jackson — Tue, 15 Sep 2026 02:03:44 +0000

I lost the better part of a day to headless code signing, and the whole time I thought I was fighting three unrelated bugs.

First, the build just hung — forever — at "[CP] Embed Pods Frameworks." No error, no timeout, just silence until the CI job itself timed out an hour later. Turns out codesign was trying to pop an interactive "Allow keychain access?" dialog. There's no screen on a CI runner to click Allow on, so the process just waits for a click that will never come.

Once I fixed that, I got "No certificate for team X" — even though I'd just imported the certificate two steps earlier, successfully, no errors. The cert was sitting right there in a temporary keychain. The problem was that nothing had told codesign and xcodebuild to actually look in that keychain — importing a cert and adding its keychain to the search list are two different steps, and I'd only done the first one.

Fixed that too, and hit a third error: SecItemCopyMatching: The specified item could not be found in the keychain, thrown by security set-key-partition-list. The key import had worked. This command runs one step later, and it couldn't find the key to apply its ACL — because the password I'd passed to -k didn't character-for-character match the password I'd used to unlock the keychain two lines above it in the same script. A typo in a variable name, effectively.

Three different error messages, three different points in the script, and the root cause every time was the same category of mistake: something about the keychain wasn't fully "there" from the next command's point of view, even though it looked fine from mine. The fix for all three ended up being three lines, in this order, right after import:

security list-keychains -d user -s /tmp/my.keychain login.keychain
security set-keychain-settings -lut 3600 /tmp/my.keychain
# (then, only after that): security set-key-partition-list -S apple-tool:,apple: -k "$SAME_PASSWORD" /tmp/my.keychain

If you're scripting headless signing for the first time, do all three up front. It'll save you the day I lost finding them one at a time.

TIL: a green checkmark in CI doesn't mean what you think it means

Jackson — Thu, 10 Sep 2026 01:28:49 +0000

I spent an afternoon convinced our signing setup was broken because TestFlight never showed a new build. CI was green. Archive step: success. Export step: success. Upload step: success. Three green checkmarks and nothing on the other end.

Turns out xcodebuild and altool/xcrun notarytool can report a successful upload while Apple's backend rejects the binary asynchronously, after your CI job has already exited. The failure happens in App Store Connect's own processing queue, which your pipeline never checks and never will unless you add a step that polls for it.

The fix is almost insultingly small: query App Store Connect's build status after upload instead of trusting the upload command's own exit code. But the real lesson generalizes past Apple's toolchain. A green checkmark only tells you the command you ran returned 0. It says nothing about whether the thing downstream that actually receives your output agreed to accept it. I've since started asking, for any pipeline step, "what's actually confirming success here, the tool I called or the system it called on my behalf?" Usually it's the former, and usually that's the gap.

Anyone else have a CI success that turned out to be lying to a downstream system rather than to you directly?

Fix ITMS-90035: "Invalid Signature. A sealed resource is missing or invalid"

Jackson — Sun, 06 Sep 2026 20:29:43 +0000

Upload finishes, then the rejection email arrives:

ERROR ITMS-90035: "Invalid Signature. A sealed resource is
missing or invalid. The file at path [MyApp.app/Frameworks/
SomeSDK.framework/SomeSDK] is not properly signed."

The headline sends people off to check their distribution certificate, regenerate a provisioning profile, and upload the same broken binary again. Your app signature is usually fine. Something inside the app bundle is not. The bracketed path names it exactly, and that path is the only part of the message worth reading first.

What "sealed resource" means

When you sign a bundle, codesign records a hash of everything inside it. That set of hashes is the seal. At upload, Apple recomputes it. If any file inside the bundle is missing, added, altered, or itself an unsigned piece of code, the recomputed seal no longer matches and the whole thing is rejected. So the error fires for two different situations that need opposite fixes: something inside was never signed, or something inside changed after signing.

Check the path it named

Unzip the exact .ipa you uploaded and look at the offending item directly:

unzip -q MyApp.ipa -d out
codesign -dv --verbose=4 out/Payload/MyApp.app/Frameworks/SomeSDK.framework

code object is not signed at all means nothing signed it. An Authority line naming a different team or a development certificate means it was signed, with the wrong identity.

Then verify the whole bundle the way Apple does:

codesign --verify --deep --strict --verbose=2 out/Payload/MyApp.app

Run this on the archive before you upload, not after the rejection. It catches the same problem in a few seconds instead of an hour.

Cause 1: a framework nothing is signing

A third-party framework or .dylib that gets copied into the bundle by a Copy Files build phase never gets signed, because copying is not embedding. Frameworks have to be listed under Embed & Sign in the target's General tab. If a framework is set to Do Not Embed and a script drops it in anyway, the app signs cleanly and the framework inside it does not.

The same applies to anything nested deeper. A binary framework that ships its own bundled dylibs can leave those unsigned even when the outer framework is embedded correctly, which is why the path in the error is sometimes several levels down.

Cause 2: something touched the bundle after signing

This is the CI version, and it is almost always ordering. Signing happens during xcodebuild -exportArchive. Any step that writes into the .app after that point breaks the seal, even if the change looks harmless. Copying in a config file, swapping an icon, patching an Info.plist value, rewriting a build number, all of it.

The fix is order, not re-signing. Make the modification before the export step, so the signature is computed over the final contents. If a pipeline genuinely has to alter the app afterwards, it has to re-sign afterwards too, and that is a worse pipeline.

Cause 3: files that should not be in there

Stray files inside the bundle can invalidate the seal on their own. Extended attributes and resource forks picked up from macOS are the common ones, along with .DS_Store files that get swept in by an overly broad copy phase. Clear them before archiving:

xattr -cr path/to/MyApp.app

Also check that no build phase is copying an entire source directory into the bundle. If a copy phase uses a wildcard, it will happily include things you never meant to ship.

Why "just re-sign with --deep" is bad advice

It shows up in every thread about this error, and it does sometimes make the upload go through. Apple's own guidance is against it. --deep re-signs everything inside the bundle with your identity, including code that was signed by someone else for a reason, and it papers over a build configuration that is still wrong. The next SDK update brings the error straight back. Fix the embed setting or the phase order instead.

Fix "You uploaded an APK or Android App Bundle that was signed in debug mode"

Jackson — Sun, 06 Sep 2026 20:27:25 +0000

The build succeeds. You drag the file into Play Console and get:

You uploaded an APK or Android App Bundle that was signed in
debug mode. You need to sign your APK or Android App Bundle
in release mode.

The confusing part is that you did run a release build. Gradle does not fail when a release build has no signing config. It signs with the debug key instead. Nothing in the build output flags it, so the first thing that notices is Play Console.

Confirm it in ten seconds

Do not guess at this. Read the signature off the artifact you actually uploaded:

keytool -printcert -jarfile app-release.aab

Look at the Owner line. A debug-signed build says exactly this, on every machine in the world:

Owner: CN=Android Debug, O=Android, C=US

If you see that, the diagnosis is done. If you see your own name or organisation instead, the upload was signed with a real key and your problem is a different one, usually the wrong key rather than a debug key.

Why a release build uses the debug key

Gradle picks the debug signing config for any build type that has no signing config of its own. That is a convenience for local debug builds and a trap for release builds. The three usual versions of it:

No release signing config exists. The signingConfigs block was never added, or a release config was added but never attached to the release build type. Defining it is not enough. The buildTypes.release block has to reference it.

The keystore file is not on the runner. This is the CI-specific one. The config is correct, the .jks is gitignored (correctly), and it was never written to the machine doing the build. Locally it works, in CI it silently produces a debug-signed bundle.

You built the wrong task. assembleDebug and bundleDebug produce debug artifacts by definition. Check that the task in your pipeline is bundleRelease, and that you are uploading the file from build/outputs/bundle/release/, not the debug folder next to it.

The fix

Keep the passwords out of build.gradle. Put them in a properties file that is gitignored, and read it:

def keystorePropertiesFile = rootProject.file("keystore.properties")
def keystoreProperties = new Properties()
keystoreProperties.load(new FileInputStream(keystorePropertiesFile))

android {
  signingConfigs {
    release {
      storeFile file(keystoreProperties['storeFile'])
      storePassword keystoreProperties['storePassword']
      keyAlias keystoreProperties['keyAlias']
      keyPassword keystoreProperties['keyPassword']
    }
  }
  buildTypes {
    release {
      signingConfig signingConfigs.release
    }
  }
}

In CI, base64 the keystore into a secret and write it back out before the Gradle step runs:

- run: echo "${{ secrets.ANDROID_KEYSTORE_BASE64 }}" | base64 -d > android/app/release.jks

Make it fail loudly next time

The real problem here is the silence. A release build that quietly signs itself with a throwaway key is worse than one that stops. Add the guard:

if (!keystorePropertiesFile.exists()) {
  throw new GradleException("No keystore.properties. Release build would be debug-signed.")
}

Ten seconds of setup, and the failure moves from Play Console back into the build log where it belongs.

One thing this is not

Play App Signing does not remove the requirement. Google re-signs your app with the app signing key it holds, but you still sign the upload artifact yourself with your upload key, and that key can never be the debug key. The debug certificate is self-signed, generated automatically, and insecure by design. Play also requires an upload key valid past 22 October 2033, which the debug certificate will not satisfy in any case.

Debugging "Exporting for App Store Distribution failed"

Jackson — Sun, 30 Aug 2026 03:06:49 +0000

If you've hit this exact banner, you already know it tells you almost nothing. "Exporting for App Store Distribution failed. Please download the logs artifact for more information" is the real wording from a live Apple Developer Forums thread, and that second sentence is the important one: the banner is a wrapper, not a diagnosis. Underneath it, Xcode is really just reporting that xcodebuild -exportArchive exited with a non-zero status, most commonly exit code 70. What actually caused that exit code is a completely different question every time, and it's sitting in the export logs, not in the banner text.

What this error actually is

Xcode Cloud shows this exact banner, and Xcode's own Distribute App flow in Organizer shows a version of the same thing, whenever the archive-to-.ipa export step fails for any underlying reason. It's the export equivalent of a generic "something went wrong" — genuinely useful only as a signal to go open the logs, not as a description of the problem itself.

Real causes, pulled from real threads

These aren't guesses. Each of these is a genuinely diagnosed case from Apple's own Developer Forums or fastlane's public issue tracker, not a paraphrase of "common wisdom."

No valid distribution certificate. The export fails with "No signing certificate 'iOS Distribution' found" when the cert Xcode expects is missing, expired, or revoked. In one Xcode Cloud case, the fix was revoking the Xcode-Cloud-managed "Distribution Managed" certificate to force it to regenerate a valid one.

Transient Apple backend failures. Sometimes the underlying error really is "Communication with Apple failed" (a 502) or a backend authentication-context bug, with nothing wrong in your project at all. There's no project-side fix for these — they resolve when Apple's own systems recover, or need an actual support ticket.

An entitlement that doesn't match the provisioning profile. One real case traced back to a typo in an entitlement key, which made the profile fail Apple's qualification check on export even though everything looked fine in Xcode's UI.

A shadowed system tool in your build environment. Homebrew's rsync can shadow macOS's own rsync in PATH, breaking the file copy step during export with the same generic exit-70 failure — a build-environment bug that has nothing to do with signing at all.

An Xcode version regression. Xcode 26.2 shipped an invalid App Store Connect API parameter for projects with a watchOS target, which broke automatic signing during export. Apple confirmed it as a real bug; the workaround was reverting to Xcode 26.1 until it's fixed.

What changed recently

Two dated platform changes are worth knowing about, even though neither has a confirmed direct link to this specific error banner — they're real, recent changes to the surrounding signing and distribution landscape:

Privacy manifests, enforced since May 1, 2024. Newly added third-party SDKs on Apple's commonly-used-SDK list now require a privacy manifest. This is a separate, earlier gate than the export step, but it's part of the same broader "your binary has to check out before Apple will accept it" surface that's expanded in the last two years.

Xcode 26.2's export regression, August 2026. The watchOS-target signing bug above is dated and Apple-acknowledged (filed as FB21322904 and FB21627607) — worth checking if you're on that exact Xcode version and your project has a watch target.

What actually helps

The single most useful habit here is treating the banner as a prompt to go looking, not as the answer itself.

Open the actual export logs, not the summary banner. Xcode Cloud's logs artifact and Xcode Organizer's own distribution logs both contain the real underlying error. The banner text is identical across every one of the causes above — the logs are where they stop looking identical.

Verify your certificate and profile directly in the portals. Don't trust what Xcode's local cache shows. Check the actual expiration and status of your distribution certificate and provisioning profile in Apple Developer and App Store Connect, since a locally-cached profile can look fine in Xcode while being invalid server-side.

Check every extension target has its own App ID and profile. Widgets, share extensions, and Safari Web Extensions each need their own explicit App ID and provisioning profile — a mismatch or missing profile on just the extension target, while the main app target is fine, is a real and recurring cause of export failures.

Clean derived data and re-download profiles before assuming it's a code problem. A stale local cache of a since-revoked or since-renewed certificate or profile causes failures that have nothing to do with your actual project configuration.

If nothing project-side is wrong, consider that it might just be Apple's backend. Some of these failures are genuinely transient server-side issues. If the logs point at a communication or authentication error rather than a signing mismatch, retrying later is a legitimate first move, not giving up.

The pattern underneath all of this: the banner text is the same no matter which of these five things actually happened. Every real fix starts with going past it into the logs, not with guessing based on the banner alone.

I built a free tool for this

I built Signing Doctor (free) specifically because this class of error is so generic on its face and so specific underneath. Paste in your actual error output and it helps you figure out which of the real underlying causes you're actually looking at, rather than guessing from the banner text alone. It's part of the same project as Macless, which handles the signing and CI side of shipping an iOS app to TestFlight without a Mac.

The most common reasons Apple rejects your app

Jackson — Sun, 30 Aug 2026 00:00:09 +0000

Getting a rejection email from App Review feels personal. It usually isn't. Apple runs the same review process against every submission, and most rejections trace back to a small number of guidelines that come up again and again. Knowing which ones, and what they actually mean, turns a vague rejection into a fixable checklist.

How often this actually happens

Apple's own 2024 App Store Transparency Report puts real numbers on this. Out of 7.77 million app submissions reviewed that year, 1.93 million were rejected, roughly 25%. Of those, 295,109 were fixed and approved on resubmission. Separately, 82,509 already-live apps were removed after the fact, most commonly for guideline or design violations (42,252), followed by fraud (38,315).

Apple hasn't published a breakdown of rejections by specific guideline number, so treat any listicle claiming "62% of rejections are X" as unsourced. What Apple has said, in its own commentary alongside the report, is that the most common drivers, in order, are performance and bugs, legal issues, design problems, business-model (payment) violations, and safety risks. That ordering lines up with the specific guidelines below.

The guidelines that actually catch people

These are pulled directly from Apple's current App Store Review Guidelines, not paraphrased from a third party.

Guideline 2.1, App Completeness. Covers crashes, obvious bugs, placeholder content, broken demo accounts, and non-functional in-app purchases. If a reviewer can't get past your login screen or your app crashes on launch, this is the line it gets cited under. It's the single most avoidable category, because it's the one you can actually test yourself before submitting.

Guideline 4.2, Minimum Functionality. Your app has to be more than "a repackaged website." Apple wants "lasting entertainment value or adequate utility." A thin wrapper around a web view, with no native functionality added, gets flagged here. A sub-clause, 4.2.6, specifically targets apps built from commercialized app-generator templates unless the actual content provider is the one submitting.

Guideline 4.3, Spam. 4.3(a) bans duplicate submissions under different Bundle IDs, the classic example being the same app re-skinned per city. 4.3(b) targets near-clones in saturated categories (flashlights, simple timers, wallpaper apps, fortune-telling apps) unless yours is "meaningfully different" from what's already in the store.

Guideline 5.1.1, Data Collection and Storage. Requires a working privacy policy link, explicit consent before collecting any data (including "anonymous" analytics), no forcing or tricking users into granting permissions they don't need, and account deletion if your app lets people create an account in the first place.

Guideline 3.1.1, In-App Purchase. Any unlock of digital features or content inside your app has to go through Apple's own In-App Purchase system. License keys, QR codes, or crypto-based workarounds to unlock paid features get rejected here, and loot-box mechanics specifically require published odds.

What changed recently

Two real, dated changes worth knowing about if you haven't submitted in a while:

Privacy manifests, enforced since May 1, 2024. Newly added third-party SDKs on Apple's commonly-used-SDK list now require a privacy manifest and, in many cases, a valid signature. An app missing one for a flagged SDK gets rejected before a human reviewer even looks at it. Apple has signaled this requirement will keep expanding to cover more of the binary, not less.

Guideline 1.2 now explicitly covers random or anonymous chat, as of February 2026. If your app includes any kind of stranger-matching chat feature, Apple's guidelines were revised to state plainly that this falls under User-Generated Content rules, meaning you need real moderation in place, not just a report button as an afterthought.

What actually helps

None of this is exotic. Most of it is just discipline about what you check before you hit submit.

Read the actual rejection line, not just the guideline number. App Review's message usually tells you specifically what triggered it, a missing purpose string, a specific screen that crashed, a mismatched screenshot. The guideline number is the category, not the diagnosis.

Give reviewers a working demo account. If your app requires login, App Review needs a real account that actually works, with real data behind it, not a stub. A broken demo account is one of the most common and entirely self-inflicted 2.1 rejections.

Don't build a payment workaround. If a feature unlocks with money, it has to go through Apple's In-App Purchase system. This is 3.1.1 and Apple checks for it specifically, including license keys and external payment links for digital content.

Check your privacy manifest before you add a new SDK, not after a rejection. If you're pulling in a new third-party dependency, check whether it's on Apple's commonly-used-SDK list and whether it ships a manifest. Finding this out from a rejection costs you a review cycle you didn't need to spend.

The pattern underneath all five categories: Apple is checking whether your app does what it claims, respects the data it touches, and pays through the channel it's supposed to. Most rejections are one of those three things, stated in guideline language instead of plain English.

I built a free tool for this

I built Rejection Doctor (free) after seeing how often the same handful of guidelines come up. Paste in your actual rejection message and it matches it against 57 real rejection categories, tells you what's actually going on, and can draft an appeal letter if you think the rejection was a mistake. It's part of the same project as Macless, which handles the signing and CI side of shipping an iOS app without a Mac.

The iOS certificate problem nobody has actually solved

Jackson — Sat, 29 Aug 2026 21:38:16 +0000

If you have ever set up iOS code signing for a CI pipeline, you already know the feeling. Everything works for months, then one day a build fails with a certificate error, and you spend the next two hours relearning a system you thought you understood.

I want to write about why that keeps happening, because it is not a "you set it up wrong" problem. It is a problem the most popular tool in this space has openly said it has not solved.

The admission

fastlane is the standard way most teams manage iOS signing. It is free, open source, and has been around since 2015. Its own maintainers have said, on a public GitHub discussion, that certificate lifecycle management is one of the few things fastlane still has not figured out:

"The problem of expiring certificates to me is one of the few fundamental signing features that fastlane has not yet solved... we all face again and again... I really hope we can put this issue to bed soon!"

That is not a random forum comment. That is a maintainer, on the project's own GitHub, describing a problem that keeps coming back for everyone who uses the tool. If you search fastlane's issue tracker, you will find real, specific reports of what that looks like in practice. One developer described fastlane match hanging indefinitely on "Installing provisioning profile," and said outright: "I accidentally tried waiting for 2.5 hours." Another reported an expired WWDR intermediate certificate silently breaking their local keychain with no clear error pointing at the actual cause.

And when match genuinely gets stuck, the documented recovery path is match nuke, which deletes every certificate and profile of the affected type for your entire team, not just yours. One developer's reaction to that in the same thread sums it up: "does nuking remove all certificates & profiles... including other people's... in your iOS team?" Yes. It does.

I am not writing this to pick on fastlane. It is a genuinely useful tool and a lot of serious iOS shops run on it successfully. I am writing this because if the tool built specifically to solve this problem says the problem is not solved, that tells you something real about how the underlying system works, not about who is using it wrong.

Why the certificates themselves are the trap

Apple caps how many active Distribution certificates you can have on an account. In practice this is usually two or three. That sounds generous until you see what actually exhausts it.

If your CI pipeline is set up to auto-provision (generate a fresh certificate on every run instead of reusing one you already created), you will hit that cap surprisingly fast. Bitrise's own documentation for their automatic provisioning steps says this plainly: without a certificate you pre-uploaded yourself, "steps with automatic provisioning will generate one on the fly every time." Run that pipeline a few dozen times and you can burn through your entire certificate allowance without ever manually creating one.

When you do hit the cap, the error from Apple's own API is not exactly friendly:

"Could not create another Distribution certificate,
reached the maximum number of available Distribution certificates."

That message tells you what happened. It does not tell you which of your existing certificates is safe to revoke, or which apps depend on which certificate. If you have more than one app signed with certificates from the same account, you now have to go figure that out manually before you can unblock yourself, usually while a release is waiting.

The errors that are not your fault

A few other things I have hit, or seen well documented elsewhere, that are worth knowing before they happen to you at 11pm the night before a submission:

A bare 500 on profile creation. UNEXPECTED_ERROR on a POST to the provisioning profiles endpoint is a real, recurring error reported directly on Apple's own developer forums. Sometimes it resolves on a plain retry with zero changes to your config. If you see this, try again before you start second-guessing your setup.

The wrong kind of API key. App Store Connect API keys come in two flavors: Individual and Team. Provisioning-related endpoints specifically require a Team key. If you are using an Individual key, you will get a 403 on exactly those endpoints while everything else you try with that same key works fine, which makes it a lot more confusing to diagnose than a blanket permission error would be.

Enterprise vs. App Store account type is invisible to the API. Apple's own documentation admits the API cannot automatically tell these two account types apart, so if you are generating certificates programmatically for an Enterprise (in-house distribution) account, you need to set the in_house flag manually. Nothing will warn you if you get this wrong until later.

Apple can change the API out from under you with no warning. In 2025, Apple silently removed an undocumented parameter, templateName, from the App Store Connect API. That parameter was load-bearing for fastlane's automated provisioning-profile creation, and its removal broke automated signing industry-wide with no migration path and no changelog entry anyone could point to in advance. There is a real postmortem about it if you want the full story (search "Sourcetoad Apple templateName fastlane"), and the related GitHub issue was still open the last time I checked. This is the part that is genuinely hard to defend against: the tool can be correct today and wrong next month because Apple changed something nobody announced.

What actually helps

None of this means give up and do everything by hand. A few things that make a real, measurable difference:

Check your certificate count before you create a new one, not after you get the error. A simple GET on the certificates endpoint tells you exactly how many of your two or three slots are already in use, so you can decide whether to reuse one or revoke an old one before you are blocked mid-release.

Never auto-provision on every CI run. Generate your signing certificate and provisioning profile once, store them (encrypted) somewhere your pipeline can reach, and reuse them. This alone avoids most of the cap-exhaustion problem entirely.

Build retry logic around the specific error codes above, not a generic catch-all. A 500 on profile creation deserves a retry with backoff. A 403 on provisioning specifically, when your key works everywhere else, deserves a message that says "check whether this is a Team key," not "permission denied."

Keep a place to watch for expiry before it becomes an outage. A scheduled check that looks at your certificate and profile expiration dates and pings you a few weeks out is a small thing to build and it turns a surprise failure into a calendar reminder.

I ended up building most of the last two points directly into my own pipeline (Macless, macless.dev), because I kept hitting exactly this set of problems while shipping my own app without owning a Mac, and got tired of relearning the same lessons every few months. If you are dealing with this on your own setup right now, I hope at least the specific error messages above save you the hour I spent figuring out what they meant the first time.

I hosted the no-Mac iOS pipeline

Jackson — Thu, 27 Aug 2026 05:01:48 +0000

A bit ago I wrote about the GitHub Actions setup I built to ship Citolex to the App Store without owning a Mac. That part hasn't really changed. What changed is how you actually set it up.

Before this, you'd download a template and run a script yourself. Works fine, but it's still a terminal and a bunch of manual steps between paying and actually having something running.

So I hosted it. You pay, log into GitHub, pick or make a repo, and a wizard pushes the whole pipeline into it for you using GitHub's API, you don't touch git at all. Then it walks you through your signing secrets and actually tells you what's wrong with a cert or profile before you waste a build on it, not after.

The signing check part runs as a Cloudflare Worker, no Mac or VM behind it. Turns out provisioning profiles and certs are just regular crypto formats, Web Crypto can read them fine on its own.

It's $19.99/month, or $299 once and nothing after — iOS and Android both. If you've fought with iOS signing in CI before, I'd like your eyes on it.

I built this, it's my thing. macless.dev

Citolex is live on the App Store, built without owning a Mac

Jackson — Mon, 24 Aug 2026 22:40:03 +0000

Citolex just went live on the App Store. It's a speed-reading app, flash-based word-by-word reading with synced text-to-speech, everything on-device.

The part I actually want to write about is how it got built and shipped. I don't own a Mac. Xcode needs one to sign and archive an iOS build, so instead of buying hardware I built a GitHub Actions pipeline that does it for me.

Capacitor wraps the web app (HTML/JS/CSS) in a native iOS shell, so most of the UI didn't need native code. But Citolex needed a few things Capacitor can't reach on its own: text-to-speech, a Share Extension so you can send text into the app from Safari or Notes, an App Group so the extension and the main app can share data, and background audio so narration keeps playing when the app isn't in the foreground. Those are native Swift plugins layered on top of the Capacitor shell.

The workflow runs on GitHub's free macOS build minutes (available on public repos), checks out the code, pulls signing certs and provisioning profiles from GitHub secrets, archives with xcodebuild, exports a signed ipa, and uploads to App Store Connect on a normal git push.

What actually took the time wasn't the workflow file. It was the signing debug loop: certificate and profile mismatches, needing the exact same name between the Apple Developer portal and the CI config, and TestFlight silently rejecting a reupload with an unchanged build number while the CI log stayed green the whole time with no useful error. Eventually I added a validate step that runs before the real build and checks the Team ID and bundle ID actually match what's in the provisioning profile, so a mismatch fails fast with a specific message instead of a cryptic xcodebuild error twenty minutes in.

It shipped. Citolex is live, built and signed entirely through that pipeline, no Mac at any point: apps.apple.com/us/app/citolex/id6800933053

If you're in the same position, no Mac, need to ship a real iOS app, that pipeline is now packaged up as Macless (macless.dev).

Orchard Cloud's Pricing Philosophy, Explained

Jackson — Sun, 23 Aug 2026 17:37:08 +0000

A lot of people ask us why Orchard Cloud costs what it costs. Fair question. Here's the honest answer.

We looked at what enterprise cloud compute costs, we looked at what enterprise device leasing costs, and then we asked what it would take to combine the two into a single line item a finance team could approve without too many follow-up questions.

Starter exists mostly so people have something to compare Growth to. This is a well-understood pattern and we're not going to pretend otherwise.

Enterprise is "Contact us" because at that volume we genuinely do need to have a conversation, mostly about logistics.

Onboarding takes 12 to 16 months. We used to say 6 to 8 weeks. We've since gotten more experience with what onboarding actually involves, and the current estimate reflects that.

If any of this makes sense to you, orchard.macless.dev has a calculator.

How We Built Orchard Cloud's Enterprise Mac Provisioning Platform

Jackson — Sun, 23 Aug 2026 16:09:44 +0000

At Orchard Cloud, we give engineering orgs elastic, on-demand access to fruit-branded computers they'll never personally own. Here's a look at how the platform works under the hood.

Provisioning runs through a queue, evaluated against fleet availability and priority tier. Once approved, you get remote access to a Mac located somewhere in our fleet — we don't say where, for reasons of security.

We also built a Total Cost of Mac Rental calculator so customers can see exactly what indefinite rental costs against just buying a Mac outright. It's the most honest part of the platform, which should tell you something.

Full pricing, onboarding timelines, and the provisioning flow are live now.

https://orchard.macless.dev