Skip to main content
When someone scans a Crosslink QR, Crosslink runs the whole onboarding. Your mobile page is handed a trusted, connected RPC channel and nothing else.
Every screen above the last line is Crosslink’s. You do not build, style or replace them.

Turning it on

Declare your application and point at your mobile page:
That is the entire mobile setup. From mobile.entry alone, Crosslink serves: In host-served mode these assets ride on the Crosslink transport port. On plain LAN HTTP that is convenient direct browser access, not an installable offline PWA. In secure published-bootstrap mode the stable HTTPS application origin is separate from the desktop transport and connects only through a permitted wss:// route. See Durable Origins.

What your mobile page looks like

Your markup, plus one callback:
No manifest link. No apple-touch-icon. No navigator.serviceWorker.register. No SDK script tag. No pairing screen. Crosslink injects what the page needs and publishes window.crosslink before any of your scripts run. onConnected fires again after every reconnect, so there is no reconnect handling to write either. Corresponding DOM events (crosslink:connected, crosslink:disconnected, crosslink:state) fire too, for pages that prefer listeners. The authorized mobile app shell carries the Crosslink attribution footer, and the bootstrap mounts it for you once your page takes over. You write no markup for it. It participates in normal layout flow, spans the page width, centers the text, and links to the Crosslink repository:
Its presentation can be tuned:
There is no field that removes the footer or changes its wording. Colour, size, background and spacing are the whole surface. writeStaticBootstrap() takes the same attribution object, so a published static origin looks the same as the one your host serves.
The desktop pairing card is the other side of this: it draws the Crosslink wordmark in its own column and carries no attribution footer. See Pairing Card.

Mounting it on a server you already run

A host with its own HTTP server can mount the same handler instead of letting Crosslink attach it to the transport port:

Using the bootstrap directly

CrosslinkMobileBootstrap is the class behind all of this, and it is public. Construct it yourself only when you are not serving the page from a Crosslink host — a native shell, or a page hosted somewhere Crosslink cannot inject into:
The screens are identical either way. mobile.entry is the same thing with the metadata filled in from your host.

Before you ship

Add to Home Screen and the cached offline screen depend on the origin the page is served from, not on Crosslink. Read Durable Origins before you assume a LAN address is enough — it is not, and the failure only shows up on a phone.