smolanalytics
menu
how it worksdocsfeaturescomparedpricinginstrumentmcpintegrationstoolsglossarycontact
log inStart trial
web browsers only · no iOS or Android runner · the tracking SDKs are native

We do not test your app.
We test everything around it.

The agent drives web browsers, so it cannot tap a native control and we are not going to imply otherwise. What it covers is the web half of a mobile product — the marketing site, signup, password reset, billing — which breaks constantly and locks people out of the app just as effectively.

Start the 14-day trialread the docs →
tests/ · the web surfaces a mobile team forgets
tests/reset.md
  Open /forgot-password, enter the test address, submit,
  and confirm the "check your email" screen appears.

tests/billing.md
  Sign in on the web, open billing, and confirm the current
  plan and the cancel link are both shown.

not covered: the app itself. the agent drives web browsers.

can I use this to test my iOS or Android app?

The straight answer for a mobile team: the smolanalytics (smolanalytics.com) agent drives web browsers only. It does not drive an iOS or Android app, it cannot tap a native control, and nothing on this site should suggest otherwise. What it does test is the part of a mobile product that lives on the web and breaks just as often — the marketing site and the app-store links on it, the account signup and password reset a customer completes in a browser, the billing and subscription-management pages, the web version if you ship one, and the support or docs site. Those are ordinary web flows: you write one sentence each, run npx smolanalytics test --suite tests/ --url against a running URL, and an agent uses them in a real browser and returns a verdict, with one comment on the pull request saying what broke. A password reset that stopped sending after a domain change locks people out of your app just as effectively as a bug in the app does, and it is the sort of thing nobody notices because nobody on the team ever resets their own password. The other half of the product is unaffected by any of this and is fully native: the published Swift, Kotlin, React Native and Flutter SDKs handle an offline-safe queue, sessions, device context and screen() tracking, and the agent writes and maintains those tracking calls in your repository the same way it does for a web app, because that job needs the source, not a browser. If a native runner ever exists it will be announced as a thing that ships, not as a thing that is coming. 14-day trial at Pro limits, no card, then $19/month.

what is covered, and what is not

It does not drive your app. Said first.
The agent runs web browsers. There is no iOS runner, no Android runner and no simulator integration, and we would rather you close this page than find that out in week two. If your only surface is a native app, the testing half of this product is not for you today.
The web half of a mobile product is real, and it breaks
The marketing site with the store links. The signup and password reset a customer does in a browser. The billing and cancellation pages. The support site. Those are ordinary web flows, they are covered here, and they are the ones nobody checks because everybody on the team is looking at the app.
Password reset is the one worth a sentence
Nobody on your team has ever reset their own password, so a reset that stopped sending after a domain or provider change locks real users out of your app for weeks before anyone finds out. It is a web flow, it is one sentence, and the cost of it being broken is a churned customer who blames the app.
The tracking side is fully native
None of the above touches instrumentation. The published Swift, Kotlin, React Native and Flutter SDKs handle the offline-safe queue, sessions, device context and screen() tracking, and the agent writes and maintains those tracking calls in your repository — that job needs the source rather than a browser, so it works the same on a native app as on a web one.

Honest pricing: 14-day trial at Pro limits, no card. Then Pro $19/mo, billed on tested pull requests rather than on installs, seats or platforms: 100 included and 10c each after. Replayed runs are not metered, and your data exports in one file any time.

Reset your own password.

It is the web flow nobody on a mobile team has walked in a year, and the one that quietly locks customers out of the app. One sentence, run on every change, and the same agent keeps your native tracking calls correct in the repo while it is there.

Start the 14-day trialread the setup docs →

questions

Can it test my iOS or Android app?
No. The agent drives web browsers, full stop. It cannot tap a native control, it does not attach to a simulator, and there is no version of the command that changes that today. If that changes it will be announced as something that shipped rather than as something planned, because a roadmap promise is how a testing tool loses the only thing it sells, which is being straight about what did and did not happen.
What about a React Native or Flutter app — those are cross-platform.
Cross-platform in source, native at run time: a React Native screen is native views, not a web page, so a browser cannot drive it. The exception is if you also ship the same product to the web, which many teams do. That web build is a normal web app and everything on this page applies to it. What you get is coverage of the shared logic through one surface, which is worth something, and it is not the same as testing the app.
Is there anything for a WebView-based app?
The content in a WebView is a web page, so the URL it loads can be tested the way any URL can. What cannot be tested is the shell around it: the native navigation, the permissions prompts, the bridge between the two. Since the interesting failures in a hybrid app are usually at exactly that boundary, treat this as covering the content and not the app.
Then what is here for a mobile team?
Two things. Coverage of every web surface your product depends on, which is more of them than a mobile team usually counts — store landing page, signup, reset, billing, cancellation, docs. And the whole instrumentation half, natively: the SDKs are published for Swift, Kotlin, React Native and Flutter, they queue offline and retry, and the agent keeps the tracking calls in your repository correct as the app changes.
Do the mobile SDKs still work the same way?
Yes, nothing about them changed. One line to initialise, an offline-safe queue that batches and persists to disk and retries until delivered, automatic sessions, device context, and screen() tracking that powers funnels and paths. Every SDK is also a thin wrapper over one open endpoint, so if you would rather add no dependency you can POST JSON to /v1/events with the HTTP client the app already ships.

keep reading

for React
the web build of the same product
the instrumentation half
native SDKs, tracking kept correct
setup docs
iOS, Android, React Native, Flutter