Building a Mobile App

Defining a native app — its identity, branding, sign-in and the native capabilities it declares.

The Mobile App Builder

The mobile app builder produces genuine native applications for iOS and Android from screens you design in the platform.

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

Architect Panel → Configuration:

Site Settings — the Mobile Apps option group

The console has four tabs: design, builds, devices and settings.

What it is not

Not a wrapped website. The app declares native permissions, compiles them into the binary, and can use device features a browser cannot reach — camera, biometrics, background location, NFC, Bluetooth.

Which is exactly why it is more work than the progressive web app, and why you should be sure you need it.

Native or progressive web app

Use the progressive web app if you want an installable, fast interface and nothing more. It costs a few settings.

Use the mobile app builder if you need any of: app store distribution, camera or barcode capture, biometric unlock, genuine offline working with queued changes, push to a native device, or background location.

Being honest about that decision saves months. Store review, signing and release management are real ongoing costs.

Settle these first

The bundle identifier and package name. These are the app’s permanent identity in each store, and they cannot be changed after publication.
The name shown under the icon.
Which native capabilities it genuinely needs, because each one has to be justified at review.
Whether it works offline, and for how long.

The app definition holds a lot

Identity, branding colours, icon and splash images, sign-in method, biometric unlock, session and refresh lifetimes, offline mode and its window, the home screen, navigation mode, update channel and store status.

Most of it is settled once and left alone. The parts that change routinely are screens, and screens do not require a rebuild.

Screens change without a rebuild

The most important operational fact in the whole module. Screen layouts and components are delivered to the installed app, so a screen change reaches users immediately.

Native capabilities are different — they are compiled in, and changing them means a new build and a new store release.

Start with a development build

The development profile produces a simulator build with no signing, so it needs no Apple membership. That is the profile you can actually try the feature with before committing to anything.

Worked example

A field service organisation chose the native builder because engineers work in basements with no signal and photograph completed work. Its bundle identifier and package name were agreed before the first build. Screens have changed weekly since; the binary has been rebuilt three times in a year.

Recommendations

Use the progressive web app unless you need device features or store distribution.
Settle the identifiers first — they are permanent.
Try a development build before committing.
Remember screens ship instantly; capabilities do not.

Identity and Branding

An app’s identity is settled early and mostly permanent.

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

The permanent parts

Bundle identifier (iOS) and package name (Android). Once an app is published under these, they cannot change. A new identifier is a new app, with no upgrade path for existing users.
The URL scheme and universal domain, which is how links open your app rather than a browser.

Choose them as you would a domain name: reverse domain notation, your own domain, no version numbers, no project code names.

The changeable parts

Display name — what appears under the icon.
Description.
Primary, secondary, background and text colours, and a theme.
Icon, splash and notification icon images.

These need a rebuild to take effect, because they are compiled in, but they are not permanent decisions.

The display name is truncated

Home screen labels show around a dozen characters. Test the name by installing the app and looking at it rather than by counting letters.

The notification icon is separate

And frequently forgotten. Android renders notification icons as a flat silhouette, so a full-colour logo becomes a grey blob. Supply a simple single-colour shape.

Colours are used throughout

Not just on a splash screen. The primary colour appears on buttons and headers, background and text colours decide readability. Check the contrast between text and background properly — a palette that works on a website can be unreadable in sunlight.

Version and build number

The version is what users see; the build number is what the stores use to distinguish uploads. The platform owns the build number rather than letting the build service increment it, so numbering stays consistent across platforms.

A minimum app version can also be set, which is how you stop very old installs from continuing to work.

Universal links are worth setting up

They mean a link in an e-mail opens the app rather than a browser, on the right record. That single feature removes a large amount of friction, and it is configured once.

Get the icon right before the first store submission

Changing it later is possible but every existing user keeps looking at the old one until they update. First impressions of an app are largely its icon.

Worked example

An organisation set its bundle identifier from its own domain before the first build, tested the display name on a device, and supplied a separate single-colour notification icon after the first Android build showed a grey square. Universal links were configured so job e-mails open the app directly.

Recommendations

Identifiers from your own domain, no code names.
Test the display name installed, not on paper.
Supply a flat notification icon for Android.
Set up universal links — they remove real friction.

Native Capabilities

A capability is a device permission compiled into the app. The platform knows thirteen, and each carries real consequences.

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

The catalogue

Camera — photos, video and barcode scanning.
Photo library — choosing an existing photo instead of taking one.
Microphone — audio notes.
Location (while in use) — stamping records and showing them on a map.
Location (always) — tracking with the app closed.
Push, biometrics, files, contacts, calendar, NFC, Bluetooth and motion.

Each maps to specific iOS usage keys and Android permissions, and each names the components that need it.

Background location is a different application

It is deliberately separate from ordinary location, not a flag on it — because Apple treats it as a different kind of app. It requires written justification at review, produces recurring "this app has been using your location" prompts for the user, and is frequently refused outright.

Enable it only if the app genuinely cannot do its job otherwise. Turning on foreground location must never opt you into it by accident, which is why the two are separate.

Every capability needs a purpose string

The sentence the user sees when the permission is requested, and the one a reviewer reads. The platform supplies a sensible default for each, and you should replace it with something true of your app.

"This app requires camera access" is rejected. "Take photographs of work carried out and attach them to the job record" is approved, and it is also the honest answer to a user wondering why you are asking.

Ask for the narrowest thing

Photo library read rather than write. Location while in use rather than always. Each narrowing makes review easier and makes users more likely to agree.

Unused capabilities are a problem

A declared permission the app never uses is flagged at review as an unused permission. So capabilities you turned on to try something must be turned off again — and that means a rebuild.

Components are hidden without their capability

A component needing a capability the installed binary does not declare is omitted from what the app receives, rather than sent and failed.

That is deliberate: on a device, using an undeclared permission does not show an error — it terminates the app. Omitting the component is the only safe behaviour.

Turn one on, and you owe a rebuild

Both directions. Turning a capability on means the installed app cannot use it until rebuilt; turning one off means the installed app still declares it until rebuilt. The platform tells you which, and why.

Worked example

A field app declares camera, photo library, location while in use, push and biometrics — five capabilities, each with a purpose string describing the actual job. Background location was considered and rejected as unlikely to survive review for the benefit it offered.

Recommendations

Write a real purpose string for every capability.
Avoid background location unless the app cannot work without it.
Turn off what you tried and rebuild.
Ask for the narrowest permission that does the job.

Sign-in and Sessions

An app holds a session on a device, which is a different security problem from a browser session.

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

Architect Panel → Configuration:

Site Settings — the Mobile Apps option group

Admin Panel → User Administration:

User Groups — what the user can reach once signed in

The settings

Sign-in method — the platform’s own, or through an identity provider.
Biometric unlock — whether the app can be unlocked with a fingerprint or face.
Session lifetime in minutes.
Refresh lifetime in days.

A session is short-lived; a refresh token keeps the user signed in across sessions until it expires. The two together decide how often somebody has to type a password.

The trade

A long refresh lifetime means people rarely sign in, which is what they want. It also means a lost device stays signed in for that long, unless the device is revoked.

Somewhere around a fortnight to a month suits most workforce apps, with biometric unlock covering the gap.

Biometric unlock is the right compromise

It lets you keep a short session lifetime without making people type a password all day. The app locks quickly and unlocks with a fingerprint, which is both more secure and less annoying than a long session.

The installation can also require it, so it is not left to each user.

Sessions are per device

Each is recorded against the device that holds it, with its issue time, last use, issuing address and expiry. So a session can be revoked individually — which is what you do when somebody loses a phone.

Limit devices per user

An installation-level maximum. Without one, a user accumulates sessions on every device they have ever installed the app on, including ones they no longer have.

Five is a sensible default and generous for most workforces.

Idle devices expire

A device not seen for a set period is expired automatically. That is what stops the device list becoming a list of every phone anybody has ever owned, each holding a valid session.

Have a lost-device procedure

Written down, before you need it: revoke the device, revoke its sessions, and know who can do it out of hours. A phone is lost at the weekend, not on a Tuesday morning.

Test what expiry feels like

Let a session expire and use the app. A user hitting an expired session mid-task should be asked to sign in and returned to what they were doing — not dropped at the home screen having lost their work.

Worked example

A workforce app uses a fifteen-minute session with biometric unlock required and a fourteen-day refresh, limited to three devices per user, with idle devices expiring after six months. A lost phone is revoked by the service desk, which has a written procedure and out-of-hours cover.

Recommendations

Short sessions plus biometric unlock, not long sessions.
Limit devices per user.
Write the lost-device procedure before you need it.
Test an expiry mid-task.