The mobile tax
Every business platform eventually faces the same fork. The screens your admins design for the web have to reach phones. The obvious routes are all expensive: build a second app by hand and pay for every screen twice, or wrap the web app in a shell and pay in user experience instead.
xMatix took a third route. Admins design layouts, forms, cards, and list views once, in the browser-based studio — and devices render those designs as genuinely native mobile UI. Change the design, and every phone in the field picks it up without an app-store release. This is how that pipeline works, and why we refused the webview shortcut.
Why not a webview
Wrapping web screens in a native shell is the fastest way to ship, which is why so many platforms do it. We rejected it for reasons that have nothing to do with fashion.
- Offline is not optional for us. A webview renders pages served from somewhere. Our field app must open, browse, and edit with zero signal, reading from a local database on the device. Retrofitting a genuinely local read/write path into a web rendering stack means rebuilding the app inside the wrapper anyway — the shortcut stops being short.
- Field work is hardware work. Barcode scanning at a shelf, camera capture on a job, geo-stamped check-ins, biometric app lock, push notifications that deep-link into a record, a live session card on the lock screen. Each of these lives on the native side of the bridge. A wrapper spends its life negotiating that bridge; a native app just uses the device.
- Touch quality is felt, not measured. Scroll physics, gesture response, keyboard behavior, transitions — users cannot name what is off about an embedded web page, but they feel it in the first minute. Reps use this app hundreds of times a day. The friction compounds.
- The economics invert at scale. A webview saves effort per screen but pays it back on every interaction, on every device, forever. A rendering pipeline costs more once and then every new entity, form, and layout rides it for free.
The real objection to native was never quality — it was the release treadmill. Every screen change meaning a store submission, a review queue, and a fleet of devices on old versions. So we built the pipeline to remove exactly that.
The pipeline: metadata in, native UI out
xMatix is a metadata-driven platform. An entity, its fields, its validation rules, its layouts — all of it is configuration, defined by admins in the studio, not code compiled into a binary. The mobile app exploits this fully: the binary ships a library of native components, and the layouts tell it how to compose them.
Design in the studio
Admins design in a drag-and-drop designer — record layouts, forms, cards, list views, and whole apps with navigation and role-scoped pages. Web and mobile are designed separately, because a good phone screen is not a shrunken desktop screen: the studio carries a distinct mobile designer, so the phone layout is a first-class artifact, not a responsive afterthought.
Render on the device
The app downloads layout definitions as data and walks them at render time, mapping each element to a native component: native inputs, native pickers, native photo capture, native signature, native lists with real scroll performance. Calculated fields and field dependencies come along too — the same expressions admins define in the studio evaluate on the device, so a dependent field updates as the rep types, even offline. Where a computation is genuinely server-side, the app shows a clearly provisional value and reconciles it when the record syncs.
Ship without shipping
Because layouts are data, publishing a change means devices pick it up on their next sync — no build, no store review, no version fragmentation for a form change. The binary itself updates over the air as well: updates are code-signed, and a preview channel lets a pilot group run a change before the fleet sees it. App-store releases still exist, but they are reserved for what actually needs them — new native capabilities — not for moving a field on a form.
Many apps, one binary
A tenant rarely wants one monolithic app. The sales team, the service technicians, and the delivery crew each need their own navigation, home page, and branding. On xMatix, tenants publish multiple branded mobile apps — own colors, logos, splash screens, per-app configuration — and gate each one by user profile. All of them are the same binary wearing different metadata. A rep signs in and gets their app; a technician on the same download gets theirs. New app for a new team is an afternoon of configuration, not a second codebase.
Offline as policy, not accident
A device cannot hold the whole tenant database, and it should not try. What goes offline is an admin decision, made in the same place the rest of the system is governed.
- Scope — admins choose which entities are offline-enabled: which masters hydrate fully, which transactions sync within a recent window.
- Retention — retention windows keep the local footprint bounded; the app prunes what falls outside policy and adapts to low-storage devices rather than filling them.
- Transparency — users see what is pending upload, when each entity last synced, and how much storage the app is using. Sync health is a visible fact, not a mystery.
Writes are deliberately not gated by any of this. Every create and edit queues in a durable outbox and replays with no-duplicate delivery regardless of offline settings — the sync policy decides what the device pre-downloads for reading, never whether a save survives. And every local row is isolated per user and per tenant, so a shared device is safe by construction.
What governance buys the whole pipeline
Notice what this architecture makes true end to end. The layout an admin designs is the layout the server enforces — business rules run server-side on every channel, so a phone cannot save what the platform would reject. The fields a user cannot see on the web are masked on the phone, because the same record- and field-level permissions scope the sync. The change an admin publishes reaches the field in one sync, and if it was wrong, the next publish fixes it just as fast. One definition of the truth, rendered natively wherever the work happens.
The trade we made, honestly
A rendering pipeline is more engineering than a wrapper — a component library to maintain, a layout interpreter to keep faithful, expression evaluation on the device, an OTA channel with signing and previews. We think the trade is obviously right for field software: the people using this app are standing in warehouses and doorways, not sitting at desks with a fallback browser tab. For them, "native" is not a technology preference. It is whether the barcode scans, the form opens with no signal, and the app feels like it belongs on the phone. Design once, render native — and let the app store be the exception, not the release process.