Builds & Releases

Build Channels

A build turns the app definition into an installable binary, through one of four profiles.

Where to find it

Architect Panel → Mobile Apps:

• Mobile Canvas — the app, its screens and its settings
• App Builds & Releases — building and submitting
• Mobile Devices — the devices that have installed it

Development

A simulator or emulator build with no signing, which means it needs no Apple developer membership. This is the profile you can genuinely try the feature with before committing to anything.

Start here. It costs nothing and answers most questions.

Internal

Signed, but distributed by link rather than through a store. This is how you test on real hardware — real camera, real GPS, real biometrics — before committing to a review.

Most of your testing should happen on this profile.

Beta

Store distribution to a limited audience, through TestFlight or the Play testing tracks. For a wider trial with people outside your team.

Production

The public release. The platform owns the build number rather than letting the build service increment it, so numbering stays consistent between platforms and across releases.

Build state is tracked

Each build records its platform, channel, version, build number, status and message, the provider’s own build identifier, the artefact, and its native fingerprint. Status moves from queued through building to built, released, failed or rejected.

A build with no status from the provider for four hours is marked failed rather than left hanging, which stops a stuck build looking like one still in progress.

Read the log tail on a failure

It is captured with the build. Most failures are configuration — a missing image, an invalid identifier, a certificate problem — and the log says which.

Build both platforms together

Or they drift. An iOS release ahead of Android means two versions of your app in the field, and screens that assume the newer one.

Do not build for every change

Screens and components ship without a rebuild. Save builds for what genuinely needs one: capabilities, branding, identity, and the app version itself.

Worked example

An organisation runs development builds while designing, moves to internal builds for field testing on real phones, and produces a production build roughly quarterly. Screens change weekly and never trigger a build.

Recommendations

• Start with a development build — no membership needed.
• Test on internal builds on real hardware.
• Build both platforms together.
• Only build for what needs it.

When a Rebuild Is Needed

The single most useful thing the module does: it tells you when your configuration has moved ahead of the installed app.

Where to find it

Architect Panel → Mobile Apps:

• Mobile Canvas — the app, its screens and its settings
• App Builds & Releases — building and submitting
• Mobile Devices — the devices that have installed it

What the fingerprint is

A summary of everything compiled into the binary — the identifiers, the icons, the URL scheme, the sign-in method, and the capability set with its permission strings. Each successful build records its fingerprint.

Comparing the current configuration against the last successful build’s fingerprint answers the question that otherwise causes hours of confusion: does this change need a rebuild?

Why it matters

Native permissions cannot be delivered over the air. They are compiled in. So a capability turned on in the console does not exist in the app somebody has installed, and a component needing it will simply not appear.

Without something tracking this, that is an unexplainable bug.

It explains both directions

• A capability turned on — the installed app cannot use it until rebuilt.
• A capability turned off — the installed app still declares it until rebuilt, which reviewers flag as an unused permission.

The second is the one people miss, and it is a review rejection.

What changes it

Capabilities and their purpose strings, the bundle identifier and package name, the URL scheme and universal domain, the icons and splash images, and the sign-in method.

What does not

Screens, components, layouts, filters, sort orders, permissions and offline settings. All of those are delivered to the installed app.

Which is worth internalising, because it means most improvements need no release at all.

Check before promising

Before telling anybody a change is live, check whether it needs a build. "It is configured" and "it is on people’s phones" are different states, and the fingerprint is what distinguishes them.

Batch capability changes

Since each needs a rebuild and a release, decide the capability set deliberately rather than adding one at a time. Three capability changes in a quarter is three store reviews.

Keep a note of the last build

Which version, when, and what changed in it. When somebody reports that a feature is missing, the first question is what build they are running, and the second is what that build contained.

Worked example

A team added a barcode component and found it missing on devices. The fingerprint comparison said the camera capability had been enabled since the last build. A rebuild and a release fixed it, and the team now checks the fingerprint before announcing anything.

Recommendations

• Check the fingerprint before saying a change is live.
• Batch capability changes into one release.
• Turn off capabilities you abandoned — reviewers flag them.
• Record what each build contained.

Store Submission

Production builds go to the app stores, and the stores review them.

Where to find it

Architect Panel → Mobile Apps:

• Mobile Canvas — the app, its screens and its settings
• App Builds & Releases — building and submitting
• Mobile Devices — the devices that have installed it

Credentials live on the build host

Apple and Google credentials are read from the build host’s own configuration rather than being held in the app definition. That is deliberate — store credentials are among the most sensitive things an organisation holds, and they are not kept in the app record.

What gets apps rejected

• Vague permission purpose strings. The commonest cause and the easiest to fix.
• Declared permissions the app never uses — usually left over from something you tried.
• Background location without a compelling written justification.
• An app reviewers cannot sign in to. Provide working test credentials.
• An app that is mostly a website, with no native value.
• Missing privacy information, or information that does not match what the app does.

Give reviewers an account that works

The single most common avoidable delay. A reviewer who cannot get past your sign-in screen rejects the app, and you lose a week.

Provide credentials, and check them yourself the day you submit.

Write purpose strings for a reviewer

They are read by a person deciding whether your request is reasonable. Describe the specific job: not "to access your camera" but what the photograph is for and what happens to it.

Allow real time for the first submission

First submissions take longer than later ones and are rejected more often. Two or three rounds is normal. Do not schedule a launch on the assumption of a first-time pass.

Privacy declarations must match

Both stores ask what data the app collects and what it is used for. That declaration should match what the app actually does — the capability set is a good checklist, and an inconsistency is both a rejection and a compliance problem.

Releases are not instant

Even after approval, a release rolls out over hours and users update on their own schedule. Assume a long tail of old versions, which is what the minimum app version setting is for.

Plan the update path

Some users will not update for months. Decide what happens to them: keep working, be prompted, or be blocked below a minimum version. Blocking is occasionally right and should be a decision rather than an accident.

Worked example

An organisation was rejected twice on its first submission — once for a vague camera purpose string, once for an unused microphone permission left from a trial. Both were fixed in one rebuild. Later releases have passed first time, with test credentials checked on the day of submission.

Recommendations

• Provide working test credentials and verify them.
• Write purpose strings for a person, not a checklist.
• Remove permissions you abandoned before submitting.
• Allow for two or three rounds on a first submission.