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.