The Watch app editor combines a screen canvas, layer list, inspector, app settings, and an interactive preview. Select the app, a screen, or one or more layers to change the inspector’s scope.

Open Manage screens to review the app in List or Flow view. List cards show each screen's structure, layer count, role, and navigation issues. Select a card to edit that screen, or use its actions to duplicate it and assign the entry or onboarding role.

Flow view maps navigation actions between screens, distinguishes unreachable screens, and lets you jump directly to a destination. A screen with no connection is not necessarily invalid—for example, it may open from a lifecycle event or reusable workflow—but it is worth reviewing before release.

Choose Add screen to start from a page, menu, picker, message, or confirmation structure. When space is available, Studio also adds an Open screen control to the current screen so the new destination is immediately connected. New apps begin with connected Home and Details pages as a small editable example. Rename, reorder, or remove the selected screen from its screen settings.

Each screen can use a freeform canvas or scrolling rows, and can show no chrome, a title, or a title with status. The screen name is rendered on the watch only when Title or Title and status chrome is selected.

One screen is the entry screen. You can also identify an onboarding screen and choose whether later launches return to the entry screen or the last screen. Studio prevents deletion while another action still points to the screen.

Layers and controls

Visuals: Text, shape, icon, image, list, and QR code.
Data: Metric, map, and sensor.
Actions: Button and hardware control.

A screen supports up to 24 layers and an app supports up to 32 screens. Use the layer list and canvas to select, group, lock, hide, reorder, move, and resize content. Freeform screens use XYWH placement; flow screens arrange controls as scrolling rows.

Use responsive layouts when the same screen needs different spacing or structure on round, rectangular, touch, or button-only watches. Preview another target before building to check which layout is active.

Actions and focus

Focusable controls participate in touch and button navigation. Actions can open or complete onboarding into another screen, go back, dismiss, start or manage an activity, request a permission, set or adjust app state, pair a profile, send a hardware command, or undo the last supported command.

Check focus order on a button-only target. Keep the primary action early, give every workflow a clear exit, and avoid depending on touch alone.

An event can run several steps in order, branch on conditions, wait, or call a reusable workflow. Controls can define separate select and hold behavior. App and screen events cover launch, resume, suspend, exit, open, and close. Preview shows the event log and each workflow step; add a breakpoint when you need to inspect state before a step runs.

Reusable components and assets

Turn a layer selection into a component when the same interface appears in more than one place. A component can expose labels, colors, visibility, actions, and slots. Instances stay linked to the source until you detach them, while their position and exposed values remain editable.

Uploaded images are stored once in Project assets and referenced by layers and components. Replace an asset to update every use. Studio shows usage before deletion and flags unused assets in App checks.

App state and visibility

App state fields can be booleans, numbers, or strings. Persisted fields survive another launch; session fields do not. Bind metrics to state, change fields with actions, and show a layer only when a field matches a visibility rule.

Use stable field names and sensible defaults. Removing or changing a field can affect bindings, actions, and visibility rules elsewhere in the app.

Data sources and bindings

Add a typed data source for watch values, companion data, or an HTTPS service. Each source defines named fields, data paths, refresh and cache behavior, fallback values, and preview samples for fresh, stale, offline, empty, and error states.

Select a text or metric layer and choose a source field from its binding control. The same field is available to expressions. Studio prevents removal while a layer or expression still uses the source, and web or companion sources request the Communications permission when generated.

Preview uses the fixture for the selected scenario. Generated apps perform HTTPS GET requests, map JSON response paths, cache successful values, and expose loading, fresh, stale, offline, and error status bindings. Companion sources listen for phone-app messages, and watch sources read the selected system value directly. Add a Refresh data source workflow step for manual updates. Custom authentication remains an integration boundary.

Activities, maps, and FIT data

Enable activity support before using start, pause, resume, lap, stop, discard, or save actions. Choose what happens when a session is interrupted. Add FIT developer fields only for values the app can supply consistently.

Maps can show current position or route progress, route selection, off-course state, and a low-power fallback. Route geometry and progress are supplied to the generated runtime by your integration.

Import a GPX or FIT track, or add route points in Studio. Preview draws the route, moves the position marker, follows the selected camera mode, and emits waypoint and turn events as progress changes. Use map states such as loading, ready, unavailable, and permission denied to review fallbacks. The editor map is interactive simulation data, not a static screenshot.

Collections hold typed records for lists and other repeated content. Lists can filter, sort, group, paginate, track selection, and run a workflow for the current row.

Sensors, pairing, and hardware

Sensor profiles use native, ANT+, or Bluetooth transport and can define zones, alerts, reconnect behavior, and whether the sensor is required. Pairing can use a QR code or short code and can support account linking and device naming.

Hardware controls define a transport, command, range, firmware limits, risk, confirmation, acknowledgement, timeout, retry limit, fixtures, and optional undo window. The generated adapter deliberately fails closed until you implement the real device protocol.

Preview and design checks

Preview navigation, Back behavior, state changes, permission decisions, activity state, sensor connections, pairing, and each hardware outcome. Use snapshots and recorded flows to revisit important states.

Design checks cover compatibility, missing action targets, unreachable screens, invalid references, limits, and configuration that cannot safely build. Fix blocking issues before opening the desktop build flow.

Checks are grouped by navigation, device support, data and simulation, project assets, and runtime state. When a safe fix is available, such as enabling Maps or adding a sample route, you can apply it from the checks dialog.

For web-service data sources that do not require OAuth, the editor canvas and Preview can use live responses alongside simulated watch and companion data. Choose a source in Canvas state, switch it independently between Live and Sample, and refresh it without leaving the editor. Preview also exercises refresh actions in the app flow. Studio keeps the last successful values visible when a later request goes offline. OAuth sources remain simulated because account sign-in happens on the watch.

Watch and companion sources use editable, typed sample values. Configure their fresh, loading, stale, offline, unauthorized, empty, and error fixtures in Data sources to review realistic states without connecting hardware.

Checks also flag unusually large layer, workflow, collection, route, or image workloads. These are recommendations rather than build limits; test flagged projects on the slowest watch you support.

Source extensions

Most apps should stay entirely visual. When a native integration is outside Studio’s built-in capabilities, add a source extension under app settings. Studio stores the Monkey C module with the project, exports it as a separate source file, and can call a Module.method() hook during app initialization or shutdown. Extension source is portable across repeated exports, but remains your responsibility to test with the Garmin SDK.

Screens and navigation