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.