DEV Community: Jackson

The actual cost of shipping an iOS app in 2026

Jackson — Sun, 16 Aug 2026 02:55:04 +0000

"How much does it cost to put an app on the App Store" gets answered inconsistently online because most answers either only count Apple's fee, or only count hardware, or quietly assume you're renting expensive cloud infrastructure you don't actually need. Here's every cost, split into what's mandatory and what's a choice.

Mandatory: Apple Developer Program — $99/year

This is the one cost nobody can avoid. To submit any app to the App Store — free or paid, one app or fifty — you need an active Apple Developer Program membership, which is $99/year, billed annually, direct to Apple. There's no one-time version and no way around it.

(There is a free-tier Apple ID for personal on-device testing without paying this, but it doesn't let you submit to TestFlight external testers or the App Store — for an actual public release, the $99/year membership is required.)

Required, but where you have genuine choices: building and signing

To submit a build, something has to run Xcode's command-line signing and archive tools — that part isn't optional. Where you have a choice is what runs it:

Option	Cost	Recurring?
Buy a Mac	~$799+ (Mac mini, entry price)	No
Rent a cloud Mac	~$20–100+/month	Yes
GitHub Actions, public repo	$0	No
GitHub Actions, private repo	$0 up to a monthly allowance, then per-minute	Only if you exceed the free allowance

The short version on that last row: on a public repo, this line item can legitimately be $0, indefinitely.

Optional or one-time: the things people assume cost more than they do

App Store screenshots and marketing assets. You can generate these yourself for free — from the Simulator or a physical device — no paid tooling required.
A physical iPhone for testing. Not strictly required to submit, but you'll want one to sanity-check the finished app before release.
TestFlight itself. Free, included in the $99/year membership.
App Store listing itself. Free — no fee to list an app beyond the membership.

Adding it up

For someone shipping a side project on a public repo, using GitHub Actions instead of a Mac or a cloud rental:

Apple Developer Program ....... $99/year  (mandatory)
Build & sign (public repo CI) ..... $0    (GitHub Actions)
Screenshots / assets .............. $0    (self-generated)
TestFlight / listing .............. $0    (included)
-----------------------------------------
Total to actually ship ......... $99/year

Compare that to the same app built with a purchased Mac (~$898 first year, then $99/year after) or a rented cloud Mac (~$339–1,299 first year, then that same range every year after). The gap is entirely in the "how do I run Xcode" line item.

Worth flagging plainly: the $0 build-cost row above is specific to public repositories. Keeping your code private doesn't change how the pipeline works or expose anything extra — it just switches you from unlimited free minutes to a metered monthly allowance. Still usually cheaper than a Mac or cloud rental, just not literally free.

I built the pipeline behind this shipping Citolex specifically to avoid a recurring Mac-rental bill on top of Apple's own fee. Packaged as a one-time $99 template at macless.dev — not a subscription.

GitHub Actions' free macOS minutes, explained

Jackson — Sun, 16 Aug 2026 02:53:18 +0000

GitHub Actions is GitHub's built-in CI/CD system — it spins up a fresh virtual machine, runs whatever commands you tell it to, and tears the machine down when it's done. It supports Linux, Windows, and macOS runners. The macOS runners are the interesting part here, because they're actual macOS machines with Xcode's command-line build tools available, which means they can build and sign iOS apps — not just run tests.

The headline rule: public repos are free

On a public repository, standard GitHub-hosted runner minutes — including macOS — don't cost anything, on any plan, including the free plan. It's a genuine free tier, not a trial or a limited allowance that runs out.

One nuance: this covers standard runners. GitHub also offers "larger runners" (more CPU/RAM) — those are billed regardless of repo visibility. A default macOS build for signing and archiving a typical app doesn't need one, so this rarely matters in practice.

What changes on a private repo

If your repository is private, you get a monthly allowance of free minutes instead of unlimited free usage:

Plan	Included minutes / month
Free	2,000
Pro	3,000
Team	3,000

The number that actually matters for iOS builds is how fast macOS runners burn through that allowance.

macOS minutes cost roughly 10x

GitHub applies a multiplier against your included minutes: Linux runners run at the baseline rate, macOS runners run at roughly 10x that rate. A 6-minute macOS build eats through the same allowance as roughly 60 minutes of Linux CI.

Applied to the table above, a Free-plan private repo effectively gets around 200 macOS-runner-minutes worth of free build time per month before you're billed per minute past it (Pro/Team works out to roughly 300).

The practical upshot: if you're fine building in the open, a public repo gets you unlimited macOS build minutes at zero cost, indefinitely. If you'd rather keep the code private, everything about the pipeline still works the same way — you're just drawing from a metered allowance instead of an unlimited one. Repo visibility only changes CI minute pricing; your signing certificates and credentials live in encrypted GitHub secrets either way, never exposed regardless of visibility.

What this doesn't cover

The Apple Developer Program fee. Still $99/year, paid directly to Apple, completely separate from anything GitHub does.
Storage and artifact retention. A distinct line item if you're archiving builds long-term, not usually a concern for a simple build → sign → upload pipeline.

Numbers on GitHub's side can shift — this reflects GitHub's billing docs as of when this was written, worth a check against GitHub's current billing docs if it's been a while.

Full pipeline built around this free tier at macless.dev.

Why your TestFlight build doesn't show up after a successful upload

Jackson — Sun, 16 Aug 2026 02:46:14 +0000

You push, the build runs, the archive and export steps succeed, the upload step succeeds, the workflow finishes green. You open App Store Connect to check on it and TestFlight shows... the previous build. Not a failed build. Not a processing build. Nothing new at all.

This one is genuinely confusing the first time it happens, because there's no error anywhere — everything you can see reports success.

What's actually happening

App Store Connect silently rejects an upload if it reuses the same marketing version and build number as a build you've already uploaded — even one from weeks ago. It considers that pair a duplicate. But the upload tool (xcrun altool, or the newer transporter flows) reports a successful file transfer regardless — it uploaded the bytes fine, it just didn't tell you App Store Connect threw the result away on the other end.

So the failure genuinely happened, it's just invisible at the layer your CI log is watching.

The fix

Make sure your build number (CURRENT_PROJECT_VERSION in Xcode's build settings) changes on every single upload, even when your marketing version stays the same across several builds while you're iterating.

The reliable way to do this in GitHub Actions is to use GitHub's own per-workflow run counter instead of anything you maintain by hand:

xcodebuild archive \
  CURRENT_PROJECT_VERSION="$BUILD_NUMBER" \
  ...

# where, earlier in the workflow:
env:
  BUILD_NUMBER: ${{ github.run_number }}

github.run_number increments by one on every run of that specific workflow, forever, with no state you have to track yourself. The actual root cause most of the time is someone customizing the archive step and dropping the dynamic build number in the process, usually while debugging something unrelated.

If you're already using a dynamic build number and this is still happening: double check the substitution is actually reaching the archive command — a common way this breaks is the environment variable being set in the wrong step or shell context, so $BUILD_NUMBER silently expands to empty.

How to confirm this is actually your problem

In App Store Connect, look at "Build Activity" or the processing history rather than just the current builds list — a duplicate-version upload sometimes doesn't even appear there. Worth separately ruling out: processing does take a few minutes even on a successful upload, so if it's only been a minute or two, it may simply not have finished yet.

The Macless workflow file sets CURRENT_PROJECT_VERSION from github.run_number by default, so this failure mode doesn't happen unless you specifically override it. Full details at macless.dev.

Fix "No signing certificate matching team ID" in GitHub Actions

Jackson — Sun, 16 Aug 2026 02:44:29 +0000

If you're building an iOS app in GitHub Actions (or any headless CI, really) and your archive/export step fails with something like No signing certificate "iOS Distribution" matching team ID "XXXXXXXXXX" with a private key was found, the good news is this is almost never a code problem. It's a mismatch somewhere between what Apple's portal has on file and what your CI job is trying to use.

In practice it's one of three things. Check them in this order — it's the order they're easiest to rule out in.

1. Check whether the certificate actually imported

Before anything else, open the "Import signing certificate" (or equivalent keychain-setup) step in your Actions log. It prints the identities it actually found after importing your .p12 file — something like:

1) AB12CD34EF... "Apple Distribution: Your Name (XXXXXXXXXX)"
     1 valid identities found

If that list is empty, or the identity isn't there at all, stop looking at provisioning profiles — the certificate itself didn't import. Usual causes: the base64-encoded .p12 secret got truncated or corrupted when it was pasted into GitHub Secrets, or the .p12 password secret is wrong. Re-export the certificate fresh rather than debugging the existing value.

2. Confirm the certificate and profile actually match

A provisioning profile isn't generic — it's generated against one specific signing certificate. If the identity from step 1 did import successfully, the next most common cause is that the certificate on Apple's portal was regenerated (often because the old one expired) without regenerating the profile that references it. Profiles pin to a certificate's public key; once that certificate is gone, every profile built against it silently stops working, even though the profile itself hasn't "expired" and still shows as valid in the portal.

The fix: in Apple's developer portal, open the provisioning profile and regenerate it (this re-links it to your current active certificate), then re-download it and update the base64 secret your workflow uses.

3. Check the profile name and bundle ID match exactly

The third cause is the most tedious to catch because it fails silently on typos. Two things have to match character-for-character, including case and whitespace, between Apple's portal and your CI configuration:

The provisioning profile's name, as typed into your IOS_PROVISIONING_PROFILE_NAME variable/secret.
The bundle ID in IOS_BUNDLE_ID — it has to match the App ID the profile was actually generated for.

Copy both values directly out of the Apple Developer portal rather than retyping them from memory — that's the single easiest place a mismatch sneaks in.

If you've checked all three and it's still failing: double-check you're not mixing up an "Apple Development" certificate with an "Apple Distribution" one — TestFlight and App Store builds need Distribution, not Development.

Why this happens more in CI than in Xcode

Xcode's GUI does a lot of this matching for you automatically when "Automatically manage signing" is on. CI has none of that; it uses exactly the certificate and profile you hand it, which is more predictable once it's working but means every mismatch surfaces as a hard failure instead of getting quietly patched over.

I hit every one of these building the CI pipeline behind Citolex. Full writeup of the signing setup (and every other error this pipeline has produced) is at macless.dev.

How to build and ship an iOS app without a Mac

Jackson — Sun, 16 Aug 2026 02:38:29 +0000

If you want to put an app on the App Store, Apple requires you to build and sign it with Xcode, and Xcode only runs on macOS. That's true no matter what you built the app with — Swift, React Native, Capacitor, Flutter, whatever. At some point, something running on a Mac has to sign the thing.

Not owning a Mac is a common enough problem that there are a few genuine ways around it, each with its own cost. Here's what I found when I hit this wall building an iOS app of my own, and what each option actually costs versus what it's usually advertised as.

Option 1: Buy a Mac

The straightforward option. A Mac mini starts around $799 (Apple raised the entry price in 2026), which is a one-time cost — no recurring bill, and it's hardware you own outright and can use for other things. If you're going to be doing iOS development regularly, long-term, this is genuinely the simplest answer and probably the right one.

Where it doesn't make sense: a side project, a one-off app, or testing whether an idea is worth pursuing before you've made any money from it. Spending $799 to find out if your app idea has legs is a genuine barrier, and it's the reason a lot of iOS side projects never ship.

Option 2: Rent a cloud Mac

Services like MacStadium, MacinCloud, and similar exist specifically to rent you remote access to an actual Mac by the hour or month. Typical pricing runs anywhere from about $20/month for a shared, lower-spec machine up to $100+/month for dedicated, faster hardware.

This solves the ownership problem but trades it for a recurring bill, and most of these services are built around interactive use — you remote into a desktop and click around, same as if you owned the machine. For something you might only need for a few minutes every time you cut a release, paying by the month is a lot of unused capacity.

Option 3: GitHub Actions' free macOS runners

The option that actually got me unblocked. GitHub Actions — GitHub's built-in CI/CD system — provides macOS build machines, and on public repositories, macOS runner minutes are free. They're intended for running test suites before a merge. Nothing about a macOS runner requires that it only run tests, though — it's an actual macOS machine with Xcode's command-line tools available, and it can run the exact same xcodebuild commands that sign, archive, and export an app that Xcode's GUI runs under the hood.

At a high level, the pipeline looks like this:

$ git push origin main
→ GitHub spins up a free macOS build machine
→ workflow checks out your project
→ signing certificate + provisioning profile are installed from secrets you set once
→ xcodebuild archives the app and exports a signed .ipa
→ the .ipa uploads straight to App Store Connect / TestFlight

No Mac touched at any point. You push code, the machine that briefly exists to build it goes away when it's done, and the signed build shows up in TestFlight.

What it costs:

Approach	Cost	Ongoing?
Buy a Mac	~$799+	No — one-time
Rent a cloud Mac	~$20–100+/mo	Yes
GitHub Actions (public repo)	$0 for macOS build minutes	No

One thing to plan around: this $0 figure is specifically for public repos. Private repos work exactly the same way, pipeline and all — you just get a monthly allowance of free minutes instead of an unlimited amount, and pay per minute past it (macOS minutes run at roughly 10x the cost of standard Linux minutes). That's usually still cheaper than renting a Mac, just not literally free. Either way, your signing certificates and credentials sit in encrypted GitHub secrets, never exposed in the repo or build logs — repo visibility only affects CI minute pricing, nothing else. You also still owe Apple's $99/year Apple Developer Program fee regardless of which build option you use — none of this replaces that, it only removes the Mac requirement.

Where this approach actually gets hard

The build pipeline itself is a fairly short workflow file. The part that actually eats time is code signing, because it's fussy in ways that aren't obvious until you've hit them:

Certificate/profile mismatches. A provisioning profile is generated against one specific signing certificate. If you regenerate the certificate in Apple's portal without regenerating every profile that references it, builds start failing with signing errors that don't clearly say why.
Exact-name matching. Provisioning profile names and bundle IDs have to match character-for-character (case and whitespace included) between Apple's portal and your CI configuration, or codesigning fails.
Silent TestFlight failures. If you reupload a build using the same marketing version and build number as a previous upload, App Store Connect silently rejects it — but the upload tool reports success either way, so your CI log shows green while the build never actually appears in TestFlight. The fix is making sure your build number changes on every single run.
Export Compliance and App Privacy. Not CI problems, but they'll block a TestFlight install or App Store submission if you haven't answered them.

None of this is a sign the approach doesn't work — it's the same signing complexity every iOS build has, Xcode's GUI just hides more of it behind clicks. Once the certificates, profiles, and workflow are set up correctly once, every build after that is just git push.

Which option is actually right for you

If you're going to be doing iOS work regularly for years, buying a Mac is genuinely the simplest long-term answer. If you need occasional interactive access to a macOS desktop — for reasons beyond just building, like testing something Simulator-only — a rented cloud Mac covers that in a way CI can't. But if what you actually need is just: build this, sign it, get it into TestFlight, on a public repo — GitHub Actions' free macOS minutes get you there without spending anything on hardware or hosting.

I went through all of this shipping Citolex, a full App Store app with native Swift plugins, entirely through this pipeline. I packaged the GitHub Actions workflow, the signing script, and a setup guide covering every pitfall above as a one-time template at macless.dev — no subscription.