Share Your App with a Public Link

Create a public URL that plays your running app in the browser, so prospects, customers and teammates can use it live with no install and no sign-in.

An app share link is a public URL that plays a running app in the browser. Send it to anyone — a prospect, a customer, a stakeholder, a teammate without a VibeView account — and they can open it and use the app on a live device, no install and no sign-in required (unless you turn that on).

Prepare a build for independent previews

For React Native and Expo apps, use a simulator build with its JavaScript bundled into the app when sharing a preview that should work without your development server. A debug build that expects Metro may wait for that server after installation. Run the build on the Devices page with your local development server stopped before sharing it.

For iOS, the preview needs a simulator .app, not a device .ipa. For Roku, upload your channel’s .zip; every visitor gets a fresh copy of it. See Preparing Your App Build for build formats.

Creating a link from your app

Open Sharing in the sidebar and click Share an app, or click Share this app on the app’s Share tab. Pick the app, and its platform if it runs on several, choose Send a link, and click Continue. The basics are on the first screen:

Name — starts as your app’s name followed by link (for example, Atlas link). Change it to something that tells your links apart, such as the customer or event you’re sending it to. Only you and your team see it; visitors never do. Up to 100 characters.
Expires — Never (the default), In 7 days, In 30 days, or On a date… to pick an exact date. After that the link stops working.

Everything else is under More options:

Build — choose Latest build (auto) so the link always plays your newest upload, or Pin to a build to lock the link to one specific version. For a React Native or Expo app, Latest build (auto) skips debug builds that load their JavaScript from Metro whenever a release build exists, and the build list marks those builds needs Metro. The dialog warns you when the build the link would play needs Metro — visitors have no development server, so they would see an error screen instead of your app. Picking a specific build turns on Keep for it, so it isn’t removed while the link uses it (see How long builds are kept).
Device models (optional) — pick from a list of the device models currently available to your organization. Select none and visitors get a phone-size device (never a foldable); select one or more and visitors get any available device from your selection (pick a specific model to stream a different form factor, for example a tablet).
Default device (optional) — the device a recipient starts on, chosen from your selected models (or any available model when you haven’t limited the list).
Default OS (optional) — the OS version a recipient starts on, chosen from the versions available for the default model. With two or more models selected, only versions every selected model runs are offered; when they share none, the list stays on Any and says so, and each recipient gets the OS of the device they land on.
Let visitors choose the device — when on, recipients can choose which device to run on. A picker only appears when you’ve selected two or more device models; with one model (or none) selected, everyone gets the default device.
Max session duration (s, 30–7200, optional) — how long, in seconds, a visitor can play once your app is on screen. Time spent waiting in the queue or for the device to start doesn’t count toward it.
Max concurrent sessions (optional) — the most sessions this link can have running at once. Leave it blank for no per-link limit. Your plan’s own concurrent-session limit still applies on top of this. Visitors who tap start while the link — or your plan — is at its limit wait in a queue and start automatically when a slot frees up; if the wait line itself is full, they’re asked to try again in a few minutes.
Show test logs to visitors — when on, recipients see the same dev log sidebar you see on the Devices page. Leave it off to give them a clean player.
Require visitors to log in — when on, a recipient must sign in to a VibeView account before they can play. See Public sharing and untrusted links below before leaving this off for something you’re posting publicly.
Audio — off by default. Set it to Sound only, Microphone only or Sound + microphone to let recipients hear the device and/or speak into its microphone, from the Sound button at the end of the device controls. Sound works on iPhone/iPad, Apple TV, Android, Android TV and Roku, and the microphone on iPhone/iPad and Android phones and tablets (iOS and tvOS 18 or later on Apple devices) — see Device audio.

Click Save to generate the link.

Each link looks like:

https://vibeview.io/app/<link>

Copy it from Sharing or the app’s Share tab and send it however you like — email, chat, a support ticket, a slide, a QR code on a booth banner.

Treat the URL like a key: anyone who has it can start sessions that use your plan’s streaming minutes. If it ends up somewhere it shouldn’t, use Regenerate link (see Managing links) to replace it without losing the link’s settings.

What recipients experience

Anyone who opens the link sees a Tap to Start screen with your app’s icon and name on it, and the browser tab is named after your app. When the link runs on a specific device model — you chose one, or the visitor picks one from the device picker — that screen is already drawn inside the device’s frame (the model’s own frame on iPhone and iPad, a TV frame on Apple TV and Android TV, a neutral phone or foldable frame on Android phones and foldables), and the session appears in the same frame. Otherwise, including on Android tablets and Roku, it uses a generic device frame. Once they tap:

While the device starts, the screen says what it’s waiting for: Starting device… until the device is up, then Opening app… until the first picture arrives. On Roku, Opening app… stays up until your channel is installed and open — each session puts a fresh copy on the device. A start that runs long adds a line saying it can take up to a minute when devices are busy.
The app loads on a live device and they get full, direct control — taps, swipes, typing, buttons — exactly as if they had opened it from Devices themselves. On a phone or tablet browser, a swipe on the device drives the device and doesn’t scroll the page.
On a computer, the device fills most of the page’s height. A handle at its bottom-right corner resizes it; the handle is hidden while a phone or tablet is turned to landscape.
An End session button at the top left ends the session and frees the device straight away.
A small set of device controls sits beside the device (below it on a narrow screen): Home, Screenshot and Type text, plus Shake on phones, tablets and foldables, and that platform’s own keys (Lock on iOS; Back and Recent apps on Android; the d-pad, Back and Menu on TV). Phone and tablet sessions also get a light/dark appearance toggle and Set location, for checking how the app looks in either mode or behaves at a given latitude and longitude. Screenshot downloads a PNG of what’s on screen. On Roku there is no Home button: the session stays inside your channel.
A small floating bar sits centred under the device. It has the Rotate button on any device that can rotate — iPhone, iPad and Android. Rotate switches the device between portrait and landscape; on a foldable such as the iPhone Duo it turns the device a quarter turn per press, closed or open. The button lights up as soon as you press it and stays lit until the device has turned. TV and Roku are landscape-only, so they have no Rotate button. On a foldable — the iPhone Duo, or an Android foldable such as the Pixel 9 Pro Fold — it has three more buttons that fold and unfold it: Open, Partial and Closed. The posture the device is in is highlighted, and the highlight follows the device, so it moves whenever the device folds. Hover a posture button to see the hinge angles the device counts as that posture (for example, Open, 150–180° on the Pixel 9 Pro Fold). TV and Roku sessions have no bar.
If they can’t start straight away, they’re placed in a queue and see their position; the session starts automatically as soon as it’s their turn. When the reason for the wait is known, the queue card says so in one line:
- All devices are in use right now — every device that can run your app is busy with another session.
- A device is being prepared and will be ready shortly — a device is being reset after the previous session, or the devices that run your app are briefly out of service for an update or restart.
- The most sessions this app can run at once are already running — your plan’s limit on sessions running at the same time has been reached; the next visitor starts when one of your sessions ends.
- The most people who can play at once are already playing — the link’s own Max concurrent sessions limit has been reached.
When there’s no specific reason to give, the card shows only the position.
If the link has a max session duration, their session ends automatically once the cap is reached.
If they close the page or navigate away, the session ends automatically a moment later.
If their connection to the device drops and can’t be restored, the session ends and they see Session ended with a line saying the connection was lost, and Play again to start over.
If the device can’t be started, they see Couldn’t start the device (with the reason, when there is one) and Try again, which starts a new session straight away. The same card appears for a session that ends before the device ever showed a picture.
If you regenerate, revoke or delete the link while they’re playing, their session ends with This link is no longer active. Ask the person who shared it for a new one., with no way to play again from that page. Starting from, or reopening, the old URL shows the same message.

No account, download, or setup is required unless you’ve turned on Require visitors to log in.

Logged-in recipients

If a recipient is signed in to a VibeView account (either because Require visitors to log in is on, or because they happened to already be logged in), the shared app is available for that session only. It is not added to their own Apps library — they’re just playing your app for as long as the session lasts.

Usage

Every session started from a share link uses your plan’s streaming minutes — the same pool your own sessions and other shares draw from. A recipient playing your link is billed exactly like you playing it yourself: from the moment a device is assigned, including its start-up, and never for time spent waiting in the queue.

Each running share session also counts toward your plan’s concurrent-session limit. A visitor who arrives while you’re already at that limit isn’t turned away: they wait in the queue and start automatically once one of your sessions ends. A visitor who is still waiting doesn’t count toward the limit. Streaming minutes are different: once your organization has used its included minutes and streaming can’t continue on overage (overage is turned off, or your usage credit can’t cover it), new visitors can’t start a session.

An app share link works for anyone who has it — there’s no built-in limit on who opens it. If you post a link somewhere public (a landing page, a forum, an open Slack channel, social media), anyone who finds it can start sessions that use your plan’s streaming minutes.

For links you’re distributing publicly or to people you don’t fully trust, turn on Require visitors to log in. That way only recipients signed in to a VibeView account can play the app, which cuts down on anonymous, uncontrolled usage of your minutes.

Find everything you’ve shared

Sharing in the sidebar lists every share link and embed in your organization. Each row shows its name, app, kind, the sessions and minutes it has used over the last 30 days, when it expires, its status, and a Copy button. Filter by All, Links or Embeds, or by app. Expired and revoked items fold under Expired and revoked. Click any item to open its details and actions.

Managing links

Click a link on the Sharing page to open its details, where its actions are. Creating, editing, regenerating, revoking and deleting links needs the Developer or Admin role; Viewers can see and copy them. The actions are:

Edit — change any of a link’s settings at any time, including its name, the build it plays, its device options, duration cap, concurrent-session cap, expiry, and login requirement. Changes apply to new sessions started after you save.
Regenerate link — give the link a new URL and keep all of its settings. The old URL stops working immediately, and anyone playing from it at that moment has their session ended. Send the new URL to the people who should keep access. Use this when a link has been shared more widely than you intended.
Revoke — permanently disable the link. Revoking immediately ends any session currently live on that link, and the link stops working right away. A revoked link can’t be edited, regenerated or re-enabled — create a new one if you need it again. It stays in the list, under Expired and revoked and with no Copy button, until you delete it.
Delete — remove the link from the list. You can delete an active link or a revoked one; either way you’re asked to confirm first. Deleting an active link also stops it working and ends any session live on it, exactly like revoking. Deleting can’t be undone. Sessions already played from the link stay in your session history and usage.

Sharing Your App with a Public Link