Skip to main content

Builds

List builds​

ascelerate builds list
ascelerate builds list --bundle-id <bundle-id>
ascelerate builds list --bundle-id <bundle-id> --version 2.1.0
ascelerate builds list --bundle-id <bundle-id> --platform macos

The output shows each build's app version, platform, build number, processing state, and upload date. Add --json for machine-readable output (conventions).

Archive​

ascelerate builds archive
ascelerate builds archive --scheme MyApp --output ./archives

The archive command auto-detects the .xcworkspace or .xcodeproj in the current directory and resolves the scheme if only one exists.

Without --destination, it archives for the scheme's platform (generic/platform=macOS for a macOS app). An app that builds for several platforms archives for iOS unless you pass --destination.

With --build-number, everything built into the archive (the app, its extensions, its watch app) gets that build number: it sets CURRENT_PROJECT_VERSION for this archive only, and the project stays as it is. Use it when the project's number was already uploaded. A target whose Info.plist sets its own number instead of $(CURRENT_PROJECT_VERSION) keeps it.

ascelerate builds archive --scheme MyApp --build-number 9

With --build-number auto, it first reads the app's builds in App Store Connect: the archive keeps the project's number while that's higher than every build uploaded for the platform, and otherwise gets the one after the highest. Either way, everything built into the archive gets that number, so an extension left at an older number matches the app. A workflow can then archive without anyone changing the project. It needs the API key, as the other commands do, and reads the app's bundle ID from the scheme's build settings.

ascelerate builds archive --scheme MyApp --build-number auto
ascelerate builds archive --scheme MyApp --xcodebuild-output quiet   # xcodebuild's warnings and errors only
ascelerate settings --xcodebuild-output quiet                        # the default for every archive

--xcodebuild-output quiet passes on only xcodebuild's warnings and errors (xcodebuild -quiet), full everything. Without it, ascelerate settings --xcodebuild-output decides (saved in ~/.ascelerate/settings.json; default goes back to the default). Without a setting, the output is full in a terminal and quiet with --json-events or in a workflow run with --json-events. ASCELERATE_XCODEBUILD_OUTPUT=quiet|full overrides the setting for one run.

Archives​

ascelerate builds archives
ascelerate builds archives --bundle-id com.example.MyApp --platform macos --limit 1 --json

Lists the archives in Xcode's archive location (~/Library/Developer/Xcode/Archives), newest first, with their bundle ID, version, build number, platform and date. --bundle-id and --platform narrow the list; --json also gives each archive's path.

Validate​

ascelerate builds validate MyApp.ipa

Upload​

ascelerate builds upload MyApp.ipa

Accepts .ipa, .pkg, or .xcarchive files. When given an .xcarchive, it detects the archive's platform and automatically exports to .ipa (iOS-family) or .pkg (macOS) before uploading, passing the matching platform to altool.

ascelerate builds upload --latest --bundle-id com.example.MyApp --platform macos

With --latest, it uploads the newest archive in Xcode's archive location: the newest of an app with --bundle-id, and of one platform with --platform (an app sold on iOS and macOS under one bundle ID has archives of both).

An .xcarchive signed with App Store distribution profiles (a project signed manually) is exported with the installed App Store profiles of its app and its extensions, so Xcode creates none; other archives are exported with automatic signing. With a file, --bundle-id refuses one that holds another app, before anything is exported or sent.

Upload through the App Store Connect API​

ascelerate builds upload MyApp.ipa --api
ascelerate builds upload --latest --bundle-id com.example.MyApp --api

With --api, the build goes through the App Store Connect API's build uploads instead of altool, using the same API key as every other command. It takes an .ipa or a Mac .pkg (or an .xcarchive, exported first), reads the version and build number from the app inside, uploads the file in chunks with a progress bar on a terminal (one at a time; see Upload chunks), and then waits until App Store Connect has accepted the file. If Apple rejects it, the command fails with Apple's error codes and descriptions; warnings are printed after a successful upload. Processing then continues as usual (see Await processing).

altool stays the default for now.

Progress for other tools​

ascelerate builds archive --scheme MyApp --json-events
ascelerate builds upload MyApp.ipa --api --json-events

With --json-events, both commands print one JSON object per line on stdout (step, archived with the archive's path, uploading, progress, uploaded, and finished with Apple's warnings) and move their readable output, xcodebuild's included, to stderr, as screenshot run --json-events does. When archiving, xcodebuild then prints only warnings and errors.

Upload history​

ascelerate builds uploads <bundle-id>
ascelerate builds uploads <bundle-id> --platform macos --limit 20
ascelerate builds uploads <bundle-id> --delete-stale

Lists the app's recent uploads, whether they were made with altool, Xcode or --api, with their state (Awaiting Upload, Processing, Complete, Failed) and the errors and warnings Apple attached to them. Look here when an upload never turns into a build. Add --json for machine-readable output.

A connection that drops at the wrong moment can leave an upload record waiting for a file that will never arrive. --api uploads remove such records of the same build after they succeed, and --delete-stale removes any that are left: records still waiting for a file while another upload of the same build has moved on, or for more than a day. An upload still in progress is never removed.

Await processing​

ascelerate builds await-processing <bundle-id>
ascelerate builds await-processing <bundle-id> --build-version 903
ascelerate builds await-processing <bundle-id> --build-version 903 --platform macos

Recently uploaded builds may take a few minutes to appear in the API — the command polls with a progress indicator until the build is found and finishes processing.

Attach a build to a version​

# Interactively select and attach a build
ascelerate apps build attach <bundle-id>
ascelerate apps build attach <bundle-id> --version 2.1.0

# Attach the most recent build automatically
ascelerate apps build attach-latest <bundle-id>
ascelerate apps build attach-latest <bundle-id> --platform macos

# Remove the attached build from a version
ascelerate apps build detach <bundle-id>

build attach-latest prompts to wait if the latest build is still processing. With --yes, it waits automatically.

Build lookups are platform-aware: on universal-purchase apps, iOS and macOS builds can share build numbers, so the attach commands only consider builds matching the target version's platform.