Continuous mobile testing on every build
Semaloop is a continuous mobile testing tool: every new TestFlight build, and every APK, .app or .ipa your CI pushes, automatically gets a run of every active test, with no one needing to kick off a cycle.
What you get
- iOS builds come straight from TestFlight, with no SDK and nothing to trigger
- Android APKs, and iOS .app or .ipa files, are pushed from any CI with the CLI, the GitHub Action or the upload API
- One run per active test per build, created the moment the build lands and run in parallel
- Results as GitHub pull request checks, Slack summaries, webhooks and an MCP server
- A written summary of how each build did compared with the last one
- Any test, or all the failures on a past build, can be rerun by hand on any earlier build
How a build reaches Semaloop
On iOS, connect TestFlight once. Semaloop's agents join your group as testers and pick up each build as you make it available, so the build that went to your team is the build that gets tested. Three routes are supported: an external group by public link, an external group by email invite, and internal testing.
From CI, push the artefact yourself: an .app for a simulator, an .ipa signed with Semaloop's device IDs for a real iPhone, or a single standalone .apk for Android. The CLI, the GitHub Action and the upload API all do the same job. Android has no Play Console integration, so the APK comes from your pipeline.
- uses: semaloop/cli/actions/build-push@v1
with:
path: app/build/outputs/apk/release/app-release.apk
api-key: ${{ secrets.SEMALOOP_API_KEY }}What happens when a build lands
Each active test gets one run against the new build, created automatically. Draft tests are left out. Runs are spread across the agents on your account, the devices that run tests at the same time, so more agents means a build finishes sooner without changing what is covered.
You can switch automatic runs on or off per distribution channel in Settings, and any test can still be rerun by hand on the latest build or an earlier one.
Where the results go
When builds arrive through the GitHub Action or the CLI and the repository is connected, results are reported on the pull request as checks. A channel of your choice in Slack gets a summary when a full suite finishes on a new build, and the message updates in place if a result changes after a spec edit.
Once every run on a build has finished, Semaloop writes a short summary of how the build did compared with the one before it: what newly fails, what newly passes, and why. For anything else, a signed webhook fires as each run finishes, and the MCP server lets a coding agent pull the full context.
Limits worth knowing
Builds from TestFlight are not tied to a commit, so they do not produce pull request checks. Slack channel summaries are sent for automatic runs only, not manual reruns. Semaloop does not pick up a build whose number is lower than the last one it received. And connecting a new app or platform is not self-serve yet: contact the team first.
For UK teams
For teams that ship in the evening, a suite run on every build means results can already be in the team's Slack channel when the day starts, depending on suite size and the number of agents on the plan.
Frequently asked questions
Last reviewed: 26 October 2026
Does Semaloop test every TestFlight build?
Yes. Once your TestFlight group is connected, each build you make available to it is picked up and every active test runs against it automatically, on real iPhones.
How do I run Semaloop tests from CI for iOS and Android?
Push the build from your pipeline with the CLI, the GitHub Action or three calls to the upload API. Every active test then runs against it automatically. iOS accepts an .app or a signed .ipa, and Android accepts a single standalone .apk.
Can I run only some tests on a pull request build?
Yes. From the same pipeline, call the test_runs_trigger tool on the MCP server's API-key endpoint to run a selected set of tests against a specific build.
Can Semaloop upload an Android App Bundle (.aab)?
No. Only a single standalone .apk is accepted, so export an APK from your build first. The documentation shows how, with Gradle or with bundletool.
Do I get results on the pull request?
Yes, for builds pushed with the GitHub Action or the CLI from a connected repository. Results appear as checks on the pull request. TestFlight builds are not tied to a commit, so they do not produce checks.
Can I turn automatic runs off?
Yes. Settings has a Test runs section with a toggle per distribution channel, and tests can still be run by hand at any time.