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

1. The bundle identifier and package name. These are the app’s permanent identity in each store, and they cannot be changed after publication.
2. The name shown under the icon.
3. Which native capabilities it genuinely needs, because each one has to be justified at review.
4. 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.