Use cases · QA + engineering teams

Test on the real thing.

Your users are on iPhones. Your test grid probably isn't. Driftstack gives your suite the exact engine iOS users run — as a cloud session your CI (your automated build-and-test pipeline) starts with one API call.

The problem

The bug you can't reproduce is on a phone.

Mobile Safari is its own world: its own rendering, its own JavaScript timing, its own quirks. A desktop browser shrunk to 390 pixels doesn't reproduce it — the layout break your iPhone users hit simply isn't there, so your suite stays green while your users see a broken page.

Driftstack sessions run a browser built from Apple's WebKit source — the same engine your iOS users actually run. Same rendering, same JavaScript timing, same quirks: the bug you reproduce is the bug your users hit, and the fix you verify is the fix they get. No hardware to buy, nothing to install.

The engine, not an approximation

Built from Apple's WebKit source code — the engine inside every iPhone's Safari, the same one your iOS users run

The iPhones your users hold

iPhone 15 Pro, 16 Pro, and the current 17 lineup — iOS 18.7 / Safari 26.4

Ready when CI is

Sessions created per test run and destroyed after — no fleet to keep warm

// wire it into CI

Your pipeline speaks HTTPS. So do we.

First-party SDKs in TypeScript, Python, and Go — plus a plain HTTPS API any HTTP client can drive: Playwright test fixtures, n8n workflows, plain curl from a cron job. The snippet below is the whole session lifecycle.

driftstack-typescript-sdk

import { Driftstack } from '@driftstack/sdk';

const ds = new Driftstack({ apiKey: process.env.DRIFTSTACK_API_KEY });

const session = await ds.sessions.create({
  archetype: 'iphone17_ios18_7_safari26_4',
  label: 'target-flow',
});

try {
  await ds.sessions.navigate(session.id, { url: 'https://target.example' });
  await ds.sessions.capture(session.id, { kind: 'screenshot' });
  const state = await ds.sessions.getState(session.id);
  console.log(state.url, state.title);
} finally {
  await ds.sessions.destroy(session.id);
}

Create a session on the archetype you ship for, drive the flow with structured actions (navigate, interact, capture, extract), assert on state and screenshots, destroy it in the teardown. Every run gets a fresh, real iPhone Safari — or reuse a persistent profile when a test needs logged-in state that survives between runs.

Sessions are metered on one number: concurrent — how many run at the same time, like browser tabs. Parallelize your suite up to your cap; hours and calls inside it are unmetered.

Which plan

Code calling → the API ladder.

The API ladder is built for code-first workloads — SDK keys, session creation from CI, concurrent caps sized for parallel suites. (Every paid tier includes API access; the API ladder's caps are sized for it.)

See API pricing →

The free tier is manual-only — use it to check by hand that pages render right and the fingerprint holds up, before you connect the SDK.

Ready when you are

Green in CI. Green on the phone.

Verify the rendering by hand on the free tier, then point your pipeline at the API ladder when you're convinced.

Start free Read the docs