Skip to the content

What's new in Trailcam

New features and improvements, as they ship.

  1. Google's accessibility checks, and requests you can open anywhere

    Android runs are now checked by Google's Accessibility Test Framework, the checks Accessibility Scanner runs, and every run's requests download as a HAR file for your own network tools.

    • On Android, more kinds of problem: a text field described instead of labelled, two things to tap in one place, something TalkBack can't say the kind of.
    • Requests download as HAR, which Chrome's developer tools, Charles and Proxyman open.
    • A slow request says where its time went: finding the server, connecting, waiting for the answer, receiving it.
    Read about the accessibility checks

  2. An accessibility report from the journeys you already run

    Every run now checks the screens its journey passes through for what keeps people out, so the journeys you monitor become an accessibility report, with nothing to write.

    • Three checks on iOS and Android: words for screen readers, sizes to tap, and contrast.
    • Each problem on the screen it's on: a picture with the problem outlined, and the recording from there.
    • The flow's page says what's new on the latest build and what it fixed.
    • It never fails a run.
    Read about the accessibility report

  3. Slower, not just broken

    Trailcam now knows how long each journey usually takes on its device, and tells you when a production check stays markedly slower, and which step slowed, before anything fails.

    • Every passing run says how it compares with the usual time, with the step that slowed most.
    • Three slower checks in a row alert the check's channels, and they hear again when it's back; PagerDuty gets a warning.
    • CI results say when a build's run took markedly longer than on the builds before.
    • Expected it? Make the new time the usual in one click.
    Read about slower checks

  4. Was it the app or the server?

    Every run now records the requests your app made, under its steps, and Trailcam AI reads them: a failure your server caused is explained as the server's, naming the request.

    • Each request's time on the recording, its step, where it went, how it answered and how long it took; the failed ones flagged, and one click plays the recording from there.
    • Never what a request carried: no headers, no bodies, no query values.
    • On iOS every URLSession request; on Android plain HTTP in full and HTTPS by its server.
    Read about the app's requests

  5. Sign-ups that email a code

    Every run now has an email address of its own. Sign up with it, and Trailcam reads the code in the email your app sends, so a sign-up that confirms its email is checked and monitored like any other journey.

    • ${TRAILCAM_EMAIL} is the run's own address, and the step runScript: trailcam/email-code.js waits for the email and puts its code in ${output.emailCode}.
    • Describe it and Find my journeys write these sign-ups themselves.
    • The run's page shows each email that came: who sent it, the code found, and whether the flow typed it.
    Read about sign-ups that email a code

  6. Find my journeys

    Upload a build, and Trailcam AI looks round your app on a device, proposes the journeys worth checking and writes the ones you choose. One click monitors those that pass.

    • It never taps anything that pays, books, places an order, deletes, sends a message or signs out, nor anything other people would see, like a like or a follow, and types nothing but a test account you give it into sign-in.
    • Each journey stops at the button that would pay, book, post, send or move money, so nothing real happens: a checkout goes as far as the payment step.
    • Each paid plan includes searches every month, and on Free each person's first search is free, journeys and all.
    Read about Find my journeys

  7. Trailcam, ready for your critical journeys

    Everything you need to know the moment sign-up or checkout breaks: flows on hosted iOS simulators and Android emulators, on every build and around the clock in production.

    • Production checks as often as every 5 minutes, with incidents and alerts by email, Slack, webhook and PagerDuty.
    • Phones, tablets and a foldable to run on, each on the system you choose: from the app, from CI and for production checks.
    • Every run recorded: the recording in step with the flow, the device's log and the screen at the failure.
    • Trailcam AI explains why a run failed, suggests the fix, and writes flows from a description.
    • A GitHub Action and a command-line tool for every CI service, with status checks and pull request comments.
    • A public API, with its reference in the docs.
    Get started