Mobile Studio — Noderyx Documentation

01

What it is

Mobile Studio is a page served by your own web app at /mobile-studio. Packaged apps download their UI settings from the same server, so what you publish there reaches phones that already have the app installed.

No app store review for a new colour, a new headline, or a feature switched on.
The compiled views stay inside the app; only settings travel over the network.
The last published settings stay on the device, so the app still works offline.

02

Turn it on

Register the mobile UI routes in server.js. This adds the studio page and the API it publishes to.

server.js

import { bearerToken, registerMobileUi } from "noderyx-framework";

registerMobileUi(app, config, {
  authorize: process.env.MOBILE_STUDIO_TOKEN
    ? bearerToken(process.env.MOBILE_STUDIO_TOKEN)
    : null
});

Note

The app must be built with apiUrl pointing at this server—see Packaged mobile app. Turn the feature off for one app with remoteUi: false.

03

What you can change

Open /mobile-studio and pick an app.

Theme Primary, accent, background, surface, text, muted, and border colours, corner radius, and light or dark mode. Presets give you a starting palette.

Text and content Values your views read as {{name}}—for example h1 "{{headline}}".

Feature flags {{flags.name}} in views, Noderyx.flags.name in scripts, native.flags in native builds.

04

Using text and flags in views

Studio values arrive as ordinary render data, so a view reads them like anything else. Give each value a default in the mobile block so the first launch, before any download, still looks right.

NODERFRAME

h1 "{{headline}}"
if flags.offers
  div.offer-card "{{offerText}}"

Note

Defaults come from mobile.data in noderyx.config.js.

05

A live preview before anyone sees it

The studio shows each screen at a real phone width—small, medium, or large—and updates as you type. Fields with a problem are flagged before you can publish. Text and flag edits go to a preview endpoint that compiles the screens without saving anything, and links inside the preview switch screens.

HTTP

POST /api/mobile/<app>/preview   # compile, never save
GET  /api/mobile/<app>/ui        # what devices download
PUT  /api/mobile/<app>/settings  # publish

Note

Discard returns to the published settings. Ctrl+S publishes.

06

How devices pick it up

Apps check for a newer version at launch and when they return to the foreground. Nothing changed means a single 204, so the check costs almost nothing.

A new version is applied the next time the screen renders.
If the server cannot be reached, the app keeps the last published settings.
A fresh install with no network uses the defaults built into the app.

07

Who can publish

Reading the UI is public, because installed apps have no session. Writing calls authorize(context). Without one, the studio is read-only. bearerToken checks a shared secret of 16 or more characters, which the studio asks for once per tab. Any function works instead:

server.js

registerMobileUi(app, config, {
  authorize: ({ session }) => session.role === "admin"
});

Note

Keep MOBILE_STUDIO_TOKEN in .env, never in the repository.

08

Validation and storage

Every value is validated before it is saved, so a typo cannot break installed apps.

Colours must be hex, rgb(), or hsl().
Text must be plain values—no markup or scripts.
Settings are saved under storage/mobile-ui/ by default.

server.js

registerMobileUi(app, config, {
  authorize,
  store: { get: (app) => Settings.find(app), set: (app, value) => Settings.save(app, value) }
});

Note

Pass store: { get, set } to keep settings in a database, which you need when the web app runs on more than one server.