Run a Studio App on its own
Goal
Open the app you drew as an app in its own right — from the Shell's list, with nothing around it but the platform's top bar.
Why this exists
A Studio App is not a page inside something else. It holds its own screens and moves between them, so it does not need a navigation rail, a site map or a model-driven app to be a whole thing. That is what makes it usable as the front of a portal later, and it is why it appears in the app list beside your other apps rather than only inside one of them.
Both ways of reaching it are real, and you choose per app:
| Reached | Looks like | Use it when |
|---|---|---|
| On its own, from the app list | your drawing, full width, no rail | the app is the drawn screens |
| Inside a model-driven app's navigation | a rail of tables beside your drawing | the drawing is a landing page over records — see Open a Studio App from a model-driven app |
Prerequisites
- A Studio App you have drawn and saved — see Draw a Studio app.
- The environment it was built in, or one its solution has been imported into.
Steps
- Open the Platform Shell and check the environment picker is on the environment your app is in.
- On the app list, find your app. Its tile says Studio App under the icon.
- Press it. The app opens on its start screen — the one named in Opens at in the designer.
- Move around it with the buttons you drew. Every
navigate("…")takes you to that screen.
The address bar is part of it
Each screen has its own address: /apps/<your app>/<screen name>. That is not decoration —
- the browser's Back returns to the screen before it, rather than leaving the app;
- a reload comes back to the screen you were on;
- a link you copy opens there for whoever you send it to.
The screen name in the address is the name on the frame, so a screen called Order details reads
as Order%20details — the browser's spelling of a space.
What a link cannot carry is a value handed over by navigate("Details", { id }). Those travel
in the moment, between two screens; arriving by Back, by reload or by a pasted link opens the
screen with nothing in screen.params. If a screen has to be reachable by what it is showing,
that is a portal page with a designed address, not a hand-off.
Who can open it
Opening an app is a permission, checked when the document is fetched — the same grant whether the app is opened on its own or from inside a model-driven app. A user with no grant is told they may not open it, rather than being shown a blank screen.
Note that a grant is per app, not per screen. Two screens that different people should see are two apps, or one app that hides what a person may not see — and hiding in a drawing is a courtesy, not security: what actually protects a record is the permission on the record.
It is on a person's app list only if they may open it. To give an app to people, select it under Studio apps and choose Share. It is the same panel as for a model-driven app: tick the roles the app is for, and People who get it names who that reaches. See Give an App to the People Who Will Use It.
Filling the window: hiding the platform's bar
An app can ask the Shell to show none of its own chrome — no top bar, no environment switcher, no language or theme controls, and no user menu. Tick Hide the platform bar on the app (Studio apps → your app → Edit). It is off unless you turn it on.
Draw those things into the app first. What the tick removes is the only way out of the product, so a drawn app that replaces the bar has to carry what the bar carried:
| What the platform's bar has | What a screen can draw |
|---|---|
| Who is signed in, and their photo | user.name, user.email, and an image whose Picture binding is user.photo |
| Light and dark | setTheme("dark") / setTheme("light"), and ui.theme to read which it is now |
| Sign out | signOut() |
| The environment picker | nothing — which is the reason to leave the bar on for anything a maker uses |
The Support desk sample does all of this; open it and look at its top bar.
Use it for an application that is not obviously part of a suite — a kiosk, a screen on a wall, a single-purpose tool — or where your own top bar sits directly under the platform's and the two read as one thing twice.
Moving it to another environment
An app travels in its solution, like every other component. Export it from the environment you built it in and import it into the next one; the app appears in that environment's app list with no further step. Links keep working across the move, because an app is addressed by its logical name and not by an id that changes.
Troubleshooting
- The app is not in the list. — you are in the wrong environment, or its solution has not been imported here. Check the environment picker first.
- It opens on the wrong screen. — Opens at in the designer names the start screen. Open the app in the designer and check it, then Save.
- A button says this app has no screen by that name. — the frame was renamed after the handler was written. The message names what was asked for; rename the frame back, or fix the handler.
- The app says it could not be opened. — your role has no grant on it. Opening an app is a permission like any other; ask whoever manages your security roles.
- Back leaves the app instead of going to the last screen. — you arrived on that screen directly (a pasted link, a reload), so there is nothing before it in this app's history.
- There is no way out of the app. — Hide the platform bar is on and the app draws no Sign out
of its own. Turn it off, or add a button whose handler calls
signOut(). - The photo in my top bar is blank. — the person has no photo on their profile, which is the
ordinary case. Bind the image's Shown to
user.photo != ""and draw a coloured circle behind it, as the sample does.