Merge into your CI branch. forgeQueue builds iOS on real Apple hardware and Android through Gradle, signs both, and pushes the compiled .ipa or .aab back into your repo — ready for App Store Connect or Google Play Console.
run #142 branch forgeQueue/ci-release commit 8f2a91c ✓ build 2m 14s ✓ sign 0m 08s ✓ artifact MyApp.ipa → /forgequeue-builds/ credits used 4.2 · balance 38.6
1.0 — how a build happens
Six stages, run once at setup, then automatic on every merge.
- 1.0
Connect GitHub
Sign up and authorize forgeQueue to read the repository you want to build. Nothing is cloned until you say so.
- 2.0
Point at a CI branch
Pick or create the branch you merge into for release builds — commonly forgeQueue/ci-release. forgeQueue only builds on merges into this branch, never on every push.
- 3.0
Install the webhook
forgeQueue registers a GitHub webhook on that branch for you in one click, or gives you the payload URL and secret to add it yourself under repo Settings → Webhooks. repo Settings → Webhooks →
- 4.0
Load credits
Credits cover build machine time. Before a merge triggers a build, forgeQueue estimates the cost from your last runs — if your balance won't cover it, the build is held and nothing is pushed back to GitHub until you top up.
- 5.0
Merge — the build runs
The webhook hits forgeQueue, code is pulled onto the build machine, and xcodebuild (iOS) or Gradle (Android) runs with your signing profile. Watch the log stream live on your dashboard.
- 6.0
Ship
On success, the signed .ipa or .aab is committed to /forgequeue-builds/ in your repo and credits are deducted. You'll get a link straight to App Store Connect or Google Play Console to upload it. On failure, you still see the exact reason in the full log — credits are charged for the build time either way, same as GitHub Actions or any other CI. App Store Connect →
7.0 — credits
Credits are provisioned manually while forgeQueue is in early access — message support after signing up to get a starting balance.