Store connections & publishing¶

A store connection holds credentials for an app store provider. Today a connection does two things: it proves the credentials you hold are valid, and — for Apple — it lets AppGantry register test devices with App Store Connect. It is also the object a future publishing capability will run against.

What a connection does not do today is push a build to a store. Publishing is not operational, on any plan, for any provider.

Before you start: connections are created per project, so you need project access that can manage project settings — Maintainer or above — and the credentials the provider issues (an App Store Connect API key, a Google Play service account, or an Intune app registration). When you're done you will have a validated connection, and on Apple the ability to register enrolled test devices from it.

Providers¶

Provider	Works today	Not operational
Apple App Store Connect	Credential validation; registering test devices for ad-hoc provisioning	Submitting builds to TestFlight or the App Store
Google Play	Credential validation	Submitting builds to Play tracks
Microsoft Intune	Credential validation	Submitting builds to Intune

All three providers are offered on every account. Creating and validating a connection works the same way for all of them, and so does the publishing limitation.

Creating a connection¶

Connections are created per project, from the project's Store connections page:

Pick the provider.
Give it a display name you'll recognise in a list.
Paste the credentials the provider requires.

The credentials are validated against the provider when you save, so a typo fails immediately rather than at some later point. If the provider can't be reached to validate, the save is refused with a transient error rather than accepted unverified — retry shortly.

Credentials are stored encrypted and are never returned by the API or shown in the UI again. Non-secret configuration is displayed so you can tell connections apart.

To change credentials — a rotated key, an expired certificate — edit the connection and paste the new values. To retire one, delete it.

One connection per provider¶

A project holds one connection per provider: one for Apple App Store Connect, one for Google Play, one for Microsoft Intune. Connections for different providers sit side by side and that is the normal case — a second connection for a provider the project already has is not something you can end up with.

Saving a connection for a provider the project already has replaces that connection's credentials in place. It stays the same connection throughout — same identity, same history — and the audit trail records the change as a credential rotation. Nothing is duplicated and nothing is left behind.

Because credentials are never returned, the values you replace cannot be recovered from AppGantry. If you still need the key, certificate, or service account you are about to save over, take it from the provider's console or from wherever you keep your secrets first.

Publishing a build¶

Publishing is not operational for any provider

No build submitted from AppGantry reaches Apple, Google or Microsoft today. The request is accepted and a publish job is created, but there is no working publisher behind it for any provider, so every job ends Failed. Nothing is uploaded to the store, and nothing is partially submitted.

What this means for you:

Publish your store releases through App Store Connect, the Google Play Console or the Intune admin center directly for now. Keep using AppGantry channels for tester distribution — that path works and is unaffected.
Don't rotate credentials in response to a failed job. A connection that saved successfully has already been validated against the provider; the failure is on the AppGantry side, not in your key, certificate, or service account. Rotating costs you an afternoon and changes nothing.
Don't read a failed job as a rejection by the store. The store never saw the artifact.

The rest of this section describes the workflow and the job states as they are defined — see Feature availability for what is and isn't operational.

The workflow lives on the project's own Publish screen, not on a build:

Open the project → Publish.
Pick a store connection and a build from the two dropdowns.
Choose Publish.

There is no Publish action on a build's detail page — a build knows nothing about store connections. The Publish screen is also where the project's publish history lives, so the job you just created appears below the form.

If either dropdown is empty the screen says which one and links you to the fix: a project with no store connection cannot publish, and neither can one with no active builds.

AppGantry creates a publish job and works on it in the background.

The job status contract¶

This is the status model publish jobs are defined against, and what each state will mean once store publishing ships. It is not a description of what happens today: today every job reaches Failed, and Completed is unreachable.

Status	Meaning
Pending	Queued
Processing	In progress
Completed	The provider accepted the build
Failed	It didn't — the job records the error

Jobs record the attempt count, when they started and finished, and a reference from the provider once there is one. The publish history is listed per project so you can see what was attempted.

Completed will mean the provider accepted the artifact, not that it's live to customers. App review, phased rollout, and track promotion are the store's workflow and happen in the store's console.

When publishing fails¶

The job carries the error it failed with. The causes, most likely first:

Cause	Fix
No publisher is available for the provider — the current cause of every failure	Nothing on your side to fix. Publish through App Store Connect or the Play Console directly
Expired or revoked credentials	Update the connection
Version or build number already used	Bump it; stores reject duplicates
Signing or entitlement problems	Fix in your build, re-upload, publish again
Missing store metadata	Complete it in the provider's console
Wrong artifact format	Stores have their own format requirements, which differ from what installs directly on a device

Every cause below the first one is a provider-side rejection, and none of them can be reached until publishing is operational. Failed jobs stay in the history either way.

Registering devices with Apple¶

An App Store Connect connection can also register test devices you've enrolled, so ad-hoc provisioning profiles can include them. The action is Sync devices now, on the connection's own page: it submits every eligible enrolled device in the organization at once and reports how many were newly registered, already registered, or failed. See Enrolling test devices.

Direct distribution vs the store¶

They solve different problems. Only the first is something AppGantry can do for you today:

	AppGantry channels	Store publishing
Available in AppGantry	Yes	No — not operational
Speed	Immediate	Store review and rollout
Audience	Testers you choose	Store's audience
Rollback	Instant	The store's rules
Review	None	The store's
Device limits	Ad-hoc signing limits apply on Apple	None

Ship internal and beta builds through AppGantry channels — that's the path that works, and it's the faster one anyway. For release candidates and anything customer-facing, submit to App Store Connect or the Google Play Console yourself; don't route a store release through AppGantry expecting it to arrive.

Keeping connections healthy¶

One connection per provider, named for the account it authenticates — saving the same provider again replaces that connection's credentials rather than adding a second one.
Diarise credential expiry. Store credentials expire, and they always expire the week you need to ship.
Least privilege on the provider side.
Delete connections you don't use.
Re-save a connection after any credential change, so it is re-validated against the provider.