Get started with AddTester
AddTester checks your TestFlight builds on a real iPhone. You describe what to check in a sentence; AddTester works out the taps, remembers them, and repeats them on every new build. This guide takes you from nothing to your first check.
Setting up takes about 15 minutes, plus the time it takes a developer on your team to send you two files.
What you need
- A Mac with Apple silicon and macOS 14 or later.
- A spare iPhone on iOS 17.4 or later, used only for testing. Do not use your personal phone: for testing, the iPhone is put into a mode that lets a computer control it. Keep personal mail, messengers and payment cards off it.
- A cable between the two. The iPhone stays plugged in while AddTester works.
- Your app installed on that iPhone from TestFlight. AddTester only tests TestFlight and developer builds; apps from the App Store never appear in its list.
- A developer on your team who can send you two files (step 4). You do not need Xcode, and you do not need access to your team's Apple account.
1. Get the iPhone ready
Do these once, on the iPhone.
- Connect it to the Mac and tap Trust when it asks, then enter the passcode.
- Turn on Developer Mode. Open Settings → Privacy & Security → Developer Mode, switch it on, and let the iPhone restart. After the restart, confirm and enter the passcode. The switch only shows up after AddTester has seen the iPhone, so if it is missing, finish step 2 below with the phone connected and look again.
- Turn on UI automation. Open Settings → Developer → Enable UI Automation. Without it the iPhone asks for its passcode every time a check starts.
- Stop the screen from locking. Settings → Display & Brightness → Auto-Lock → Never. AddTester cannot unlock an iPhone, and it will never try.
- Turn off automatic iOS updates. Settings → General → Software Update → Automatic Updates. An update restarts the iPhone overnight, and after a restart it stays locked until someone enters the passcode.
2. Install AddTester and find it in the menu bar
AddTester lives in the menu bar as a small phone:
 | An iPhone is connected and ready |
 | The iPhone is connected but needs a tap on Trust |
 | No iPhone is connected |
Click the icon for its menu: how things are, Runs from the Cloud, the apps to test, Open AddTester for its window, Settings… and Quit.
3. Sign in
Click the menu bar icon and choose Sign In…. First choose the name addtester.com shows this Mac by: the kind of Mac ("MacBook Pro"), its name in System Settings, or one you type. Only that name is sent; you can rename the Mac later under Macs. Then click Continue in Browser…: a page opens asking whether to let this Mac use AddTester. Approve it, and the menu says Signed in as followed by the name you chose.
Under iPhone in the panel, choose the same way how the connected iPhone is shown on the website. Until you do, it is shown as just "iPhone".
You sign in once. Sign Out under Settings… → Account removes this Mac's access.
4. Add the two signing files
To control the iPhone, AddTester installs a small helper app on it. Apple requires that helper to be signed by a developer team, for this particular iPhone. That takes two files from a developer on your team:
- a development certificate (
.p12) and its password; - a development provisioning profile (
.mobileprovision) that includes this iPhone.
Open Settings… and go to iPhone. Next to Identifier click Copy, and send the identifier to your developer with this request:
Hi! I'm setting up AddTester to test our TestFlight builds on a spare iPhone. Could you send me two files?
- A development certificate exported as
.p12, with its password.- A development provisioning profile that includes this iPhone and covers any app ID (a wildcard profile) or
com.addtester.WebDriverAgentRunner.xctrunner.The iPhone's identifier (UDID) is: paste it here
Both files stay on my Mac. They let AddTester sign one helper app for this one phone; they give no access to our Apple account, our apps or our releases.
When the files arrive, open Settings… → Account, click Add Files… next to
Signing, choose each file, type the password of the .p12, and click Add.
Signing changes to Ready.
If a developer has already used Xcode with this iPhone on this Mac, Signing may say Ready straight away, and you can skip this step.
A profile lasts up to a year. AddTester shows how many days are left and reminds you in the last month; renewing means adding a new profile the same way.
5. Prepare the iPhone
In Settings… → iPhone, next to Test runner, click Prepare. AddTester signs the helper app, installs it, and starts it once to make sure it works. This takes about a minute, and the line changes to Installed.
Turn on Do Not Disturb on the iPhone while AddTester uses it (Control Centre → Focus → Do Not Disturb). A notification from another app shows on top of the app being tested, and could otherwise end up in a screenshot.
6. Choose what AddTester may test
Click Open AddTester. The Apps tab lists the TestFlight builds on the iPhone, each with a switch. Switch on the apps you want tested. AddTester opens and looks at those apps and nothing else on the iPhone. This list is kept on your Mac, and only someone at your Mac can change it. The apps you switched on are also in the menu, under Apps to Test.
If an app asks to sign in, click Test Account… next to it and set the
user name and password AddTester signs in with. They are kept in this Mac's keychain; the
cloud and the AI only ever see {{secret:username}} and {{secret:password}}.
7. Run your first check
On addtester.com, open the app you switched on, click New check, describe what to check, and click Run it now. Leave Keep it as a journey on, and it also runs by itself on every new build. For example:
Open the profile tab and make sure the user's name is shown.
A good description names where to go and what should be visible at the end.
Apps remember things between launches: who is signed in, a selected tab, items in a cart. Two optional fields take care of that:
- Before brings the app to where the check starts, for example "switch to level A1". AddTester first looks at the app's start screen, and if the result of Before is already there, it does nothing.
- After undoes what the check changed, for example "empty the cart", so the next run finds the app the way this one did. If it fails, the result says so, but the check's own result stays as it was.
AddTester learns both the same way it learns the check, and repeats them without the AI.
You will see each step as it happens, then the result:
| Result | Meaning |
|---|---|
| Passed | The goal was reached. AddTester saved the steps it took. |
| Passed, without the model | The saved steps were repeated and gave the same result. This is what every later run looks like, and it takes seconds. |
| Passed — by a different path than before | The app changed, but the goal is still reachable. The saved steps were updated. |
| Not passed | The goal could not be reached. The text says where it stopped. |
| Confirmed regression | A check that used to pass failed twice, each time from a fresh start of the app. |
| Possible regression — not reproduced reliably | It failed once, then passed. Worth a look; the app may be flaky. |
| The app crashed | The crash report from the iPhone is shown below the result. |
| The app stopped responding | The app froze for over 20 seconds after a step, twice. The step is named. |
| Blocked | The check needed something AddTester never does. See below. |
| Needs you on the iPhone | Before could not be done, so the check did not run. Usually a sign-in AddTester cannot do on its own; see below. |
With a test account set, AddTester signs in by itself when the app asks. If your app needs a login it cannot do (Sign in with Apple, a code by SMS or email), sign in once by hand on the iPhone. AddTester does not sign out, so later checks start already signed in.
Let AddTester look round the app
On addtester.com, open the app and its Screens tab, and click Look round the app. The Mac taps through every screen it can reach: it scrolls each one to its end, opens and closes sheets, and notes links that leave the app. Every screen it finds gets a picture and a check of its own, run on each new build. Nothing that adds, saves, deletes, sends or signs out is tapped, and switches and text fields are left alone.
What AddTester will not do
These rules are held by the app on your Mac for every single action, however it was decided: by the AI, by a learned path, or while looking round the app. Each tap, keystroke and swipe is judged on the screen as it is at that moment.
- It does not tap a button that pays, buys, places an order, subscribes, deletes an account, sends or publishes. A check that asks for one of these is refused before the app is even opened.
- On a payment screen it only goes back or closes, and it does not type or swipe there.
- On a cart or checkout screen it does not tap buttons that have no label.
- It opens only the app the check is for, and only while that app is switched on in AddTester on this Mac. It does not read or photograph any other app; if another app comes to the front, it brings yours back instead of looking at it.
- It never accepts a system dialog (permissions, payments); it only dismisses them.
- When it looks round an app, it does not tap anything that adds, saves, deletes, sends or signs out, and it leaves switches alone.
- It never types the iPhone's passcode and never tries to unlock the phone.
These rules recognise buttons by what they say, in several languages. A button that is only an icon, or says something unusual, can slip past them, and a server can act on a tap that looks harmless. So use a test account in your app, a test payment setup if your app has one, and an iPhone kept for testing.
What leaves your Mac
- Sent to AddTester: a text description of each screen of the app under test (the
names and types of buttons, fields and labels), your description of the check, and the
steps taken. The test account's user name and password are replaced by
{{secret:username}}and{{secret:password}}wherever they appear on screen, and password fields are sent empty. This text is what the AI uses to decide the next step. - Sent to AddTester: a small picture of each step and of each screen found, shown to you on addtester.com and to nobody else. Screens with a password field, or showing the test account, are not photographed: a grey picture stands in. Runs and their pictures are deleted after 90 days.
- Sent to AddTester: the names you chose for this Mac and its iPhone, the iPhone's iOS version, and the name, version and icon of each app you switched on.
- Kept on your Mac only: test accounts and your sign-in token (in the Keychain), the signing certificate and profile, the list of allowed apps, and the last week of runs, readable only by your macOS user.
While a check runs, the iPhone's automation can be reached from this Mac by programs of the same macOS user. Run AddTester under a user account you trust, ideally on a Mac kept for testing.
If something goes wrong
The iPhone asks for its passcode whenever a check starts. Enable UI Automation is off. Turn it on in Settings → Developer.
"The iPhone is locked". Unlock it with its passcode and run the check again. Then set Auto-Lock to Never so it does not happen overnight.
My app is not in the list. Only TestFlight and developer builds are listed. Install the app from TestFlight on this iPhone, then click Refresh.
Signing says "Certificate missing" or "Profile missing". One of the two files does not match the other, or the profile does not include this iPhone. Send your developer the iPhone's identifier again and ask for a profile that contains it.
The sign-in page says the link is no longer valid. A sign-in request lasts ten minutes. Choose Sign In… in the menu again.
A banner saying "Automation Running" stays on the iPhone. It normally disappears when a check ends. If it stays, restarting the iPhone clears it.