# Semaloop use cases

Last reviewed: 2026-10-26

Semaloop is a continuous testing platform for iOS and Android apps. Teams describe what to test in natural language. Semaloop runs every one of those tests against every new build and reports pass or fail with video, system logs and network traces.

## Natural language mobile app testing

Source: https://semaloop.com/use-cases/natural-language-mobile-app-testing

Natural language mobile app testing means writing a test as a description of what should be true, and Semaloop is a tool that runs those descriptions on real iPhones and Android emulators against every build you ship.

### What you get

- Tests are written as descriptions of intent, with no selectors, test IDs or tap sequences
- One description runs on iOS (real iPhones and simulators) and on Android emulators
- No SDK to embed and no instrumented build: Semaloop drives the app you ship
- Secrets and custom tools let a test sign in, reset data or seed an order before it starts
- A coding agent can write and revise tests over the MCP server
- A judging step checks the outcome against your description, not just that the last step ran

### Write the outcome, not the taps

A scripted test is a list of instructions: tap this element, type into that one, wait, tap again. A Semaloop test is the sentence a product manager would write in a ticket. You state what the user is trying to do and what should be true afterwards, and the agent works out the taps fresh on every run.

The description below replaces a script that names five or six screens and buttons. It keeps the data, because the data defines a successful outcome, and drops everything about how the interface happens to be laid out today.

```text
Reset the test account, then complete sign up with the newly reset account.
Add the first item in the catalogue to the basket, and complete checkout.
Verify the order confirmation screen shows the correct item and total.
```

### What the agent does with a description

The agent looks at the screen the way a person does, using computer vision to understand what is rendered and a reasoning model to decide what to do next. It does not read the accessibility tree or depend on test IDs, so there is nothing to add to your app.

It can tap, type and swipe, and on the right devices it can also speak into the microphone, set a GPS location, throttle the network, follow a deeplink, read an emailed magic link or code, and force-quit and resume the app. A separate judging step then checks the run against your description. A success means the intent held, not merely that a script reached its last line.

### Three habits that make a good description

These come from the writing tests guidance in the documentation, and they are most of what separates a test that stays useful from one that needs constant care.

- Give the agent context, not assumptions. Saying 'log in with a premium account' only works if a secret, a seeded account or a setup step provides one.
- Describe the goal, not the taps. Keep amounts, names and quantities. Drop button names, tap order and screen names.
- Check something durable. Anchor to what stays on screen, such as an item in a list or an updated value, not a spinner or a toast that disappears.

### Where tests come from

You can write a test in the dashboard, or ask a coding agent to write it. Connected to the Semaloop MCP server, an agent can list your existing tests, compare them with a pull request description and create a test for a flow that is not yet covered.

Semaloop tests what you ask it to test. It is not an exploratory crawler that discovers flows on its own, and it is not a recorder: nothing is captured by walking through the app, and nothing is replayed. That is the trade. You decide what matters, and the work of keeping that coverage alive is far smaller than maintaining a script.

### For UK teams

Semaloop's team is based in London, and pricing is published in full at /pricing with a calculator, so a UK team can model the monthly bill before speaking to anyone.

### Frequently asked questions

#### What is natural language mobile app testing?

It is writing a mobile test as a description of the outcome you expect, such as 'add an item to the basket and check the total', and letting an AI agent work out the taps on a real device. In Semaloop the description is the test, and the agent re-interprets it on every run.

#### Do I need to write code to create a Semaloop test?

No. A test is a sentence or a short paragraph. Setup that depends on your backend, such as resetting an account, is done with a [custom tool](https://docs.semaloop.com/writing-tests/custom-tools/), which is a named HTTP call to your own endpoint that the agent can make during the test.

#### How is this different from record and replay?

A recorder captures one path through the app and replays it, so it breaks when that path changes. Semaloop stores a description of intent and works out the path on each run. Nothing is recorded and nothing is replayed.

#### How specific should a description be?

Specific about the data and the expected result, silent about the interface. 'Add three items and check the basket total is the sum of their prices' is a good description. 'Tap the second tab, then the plus button' is not.

#### Can a coding agent write the tests for me?

Yes. Over the [MCP server](https://docs.semaloop.com/integrations/mcp-server/), an agent can discover your apps and tests, write a test from a natural language description of a flow and revise it as the app changes. Creating or updating tests needs the write or admin organisation role.

#### Does natural language testing work on both iOS and Android?

Yes. The same kind of description runs on both. On iOS the agent works on real iPhones or simulators, and on Android it works on Android 15 emulators. What differs is which device capabilities are available, which the [supported platforms](https://docs.semaloop.com/getting-started/supported-platforms/) page sets out.

### Related reading

- [Test authoring basics](https://docs.semaloop.com/writing-tests/test-authoring-basics/)
- [Best practices](https://docs.semaloop.com/writing-tests/best-practices/)
- [Agent capabilities](https://docs.semaloop.com/writing-tests/agent-capabilities/)
- [Semaloop vs Appium](https://semaloop.com/compare/appium)
- [Semaloop vs Maestro](https://semaloop.com/compare/maestro)
- [Semaloop vs testRigor](https://semaloop.com/compare/testrigor)

## Real-device iOS testing with video, logs and network traces

Source: https://semaloop.com/use-cases/real-device-ios-testing

Semaloop runs your iOS tests on real iPhones, from the iPhone 14 upwards on iOS 18 and later, and returns video, system logs and network traces with every run.

### What you get

- Real iPhones, iPhone 14 and newer, on iOS 18 through the latest release
- Push notifications, the camera and sandbox in-app purchases, which simulators cannot do
- Video, system logs, network traffic, audio capture and an interaction timeline on every run
- TestFlight builds run on real devices with nothing to trigger by hand
- Real iPhone and simulator runs side by side, so each test can use the one that fits
- Physical devices run by Semaloop, so you do not provision or maintain any hardware

### What real iPhones catch that simulators do not

Simulators are useful early in development, but they share the host's networking stack, use a case-insensitive filesystem and cannot do several things your app depends on. Real devices are where those failures show up.

| Capability | Real iPhone | Simulator |
| --- | --- | --- |
| TestFlight builds | Yes | No |
| Push notifications | Yes | No |
| Camera | Yes | No |
| Sandbox in-app purchases | Yes | No |
| Phone number and SMS codes | Yes | No |
| Voice input and audio capture | Yes | No |
| Network conditions and airplane mode | Yes | No |
| Face ID and Touch ID | No | Yes |
| Production-matching filesystem | Yes, case-sensitive | No, case-insensitive |

### Push notifications, camera, purchases and permissions

Push notifications and the camera work on real iPhones only. A test can check that a notification arrives and that the destination behind it opens, and can use the camera where your app does.

In-app purchases and subscriptions run through Apple sandbox accounts, stored as sandbox secrets. Each concurrent run claims its own account, so provision as many as the tests you run in parallel. Sandbox accounts are available on real iPhones, not on simulators or Android emulators.

System permission prompts appear as screens in the run, and the agent responds to them the way a person would, which means a test can cover first launch, a denied permission and a granted one. Face ID and Touch ID are the one common exception: they are supported on iOS simulators, not on real iPhones.

### What you get back from every run

Every run keeps the evidence needed to reproduce a problem, without asking anyone to rerun it.

- A high-FPS video replay of the whole run, with audio where there was microphone input or media playback
- An interaction timeline: each step the agent took, with its reasoning
- System logs, which can be downloaded from the dashboard
- Network activity: responses, headers and timings
- Issues the agent noticed along the way, such as a slow screen or clipped text
- On a failure, a root cause analysis and a suggested fix

### Getting a build onto a real iPhone

The most common route is TestFlight. Semaloop's agents join your external group by public link or email invite, or your internal group, and pick up each new build as you make it available. TestFlight builds always run on real devices.

If you would rather not use TestFlight, push an .ipa signed with Semaloop's device IDs using the CLI, the GitHub Action or the upload API. A .app runs on a simulator instead. Setting up a new app is not self-serve yet, so contact the team first.

### Limits worth knowing

Real-device coverage starts at iOS 18 and iPhone 14. An app that supports older versions can still be tested, but only on those versions. Android tests run on Android 15 emulators today, so the hardware-dependent rows above do not apply there. The supported platforms page has the full matrix.

### For UK teams

To check a UK launch, ask the agent to set the device region and a GPS location, for example a named London address, so pound sterling formatting, UK date formats and location-based flows are covered on the same real device.

### Frequently asked questions

#### Does Semaloop test on real iPhones?

Yes. iOS tests run on real physical iPhones that Semaloop manages, from the iPhone 14 to the latest models, on iOS 18 through the latest release. Simulators are also available where they fit better.

#### Can Semaloop test push notifications on iOS?

Yes, on real iPhones. Push notifications do not work on simulators or Android emulators. A test can check that a notification arrives and that the screen behind it opens.

#### Can Semaloop test in-app purchases and subscriptions?

Yes, on real iPhones, using [Apple sandbox accounts](https://docs.semaloop.com/writing-tests/secrets-and-credentials/#sandbox-accounts) stored as secrets. Each concurrent run claims its own account, so keep at least as many accounts as tests you run in parallel.

#### What does a failed iOS run give me to debug with?

A high-FPS video replay, an interaction timeline with the agent's reasoning, system logs, network activity, and a root cause analysis with a suggested fix. Logs can be downloaded, and a coding agent can read all of it over the MCP server.

#### Can Semaloop test Face ID on a real iPhone?

Not today. Face ID and Touch ID are supported on iOS simulators, where the agent can enrol a biometric and send a matching or non-matching one. They are not supported on real iPhones.

#### Do I need to own or manage any devices?

No. Semaloop runs and maintains its own physical devices. You connect your app through TestFlight or by pushing a build, and runs are scheduled across the agents on your plan.

### Related reading

- [Supported platforms](https://docs.semaloop.com/getting-started/supported-platforms/)
- [Connecting your app](https://docs.semaloop.com/getting-started/connecting-your-app/)
- [Reading test results](https://docs.semaloop.com/test-results/reading-results/)
- [Semaloop vs BrowserStack](https://semaloop.com/compare/browserstack)
- [Semaloop vs Sauce Labs](https://semaloop.com/compare/sauce-labs)
- [Semaloop vs AWS Device Farm](https://semaloop.com/compare/aws-device-farm)

## Continuous mobile testing on every build

Source: https://semaloop.com/use-cases/continuous-mobile-testing

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.

```yaml
- 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

#### Does Semaloop test every TestFlight build?

Yes. Once your [TestFlight](https://docs.semaloop.com/getting-started/connecting-your-app/#testflight-ios) 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](https://docs.semaloop.com/integrations/github/) 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.

### Related reading

- [Automatic runs](https://docs.semaloop.com/running-tests/automatic-runs/)
- [Connecting your app](https://docs.semaloop.com/getting-started/connecting-your-app/)
- [GitHub integration](https://docs.semaloop.com/integrations/github/)
- [Semaloop vs Maestro](https://semaloop.com/compare/maestro)
- [Semaloop vs AWS Device Farm](https://semaloop.com/compare/aws-device-farm)
- [Semaloop vs Firebase Test Lab](https://semaloop.com/compare/firebase-test-lab)

## Self-healing, low-maintenance mobile tests

Source: https://semaloop.com/use-cases/self-healing-mobile-tests

Semaloop's self-healing works because a test is a description of intent rather than a script: when a button moves or a screen is redesigned, the agent finds the new route to the same goal instead of failing on a missing selector.

### What you get

- Tests state intent, so a moved button, renamed label or redesigned screen usually needs no edit
- The agent reads the rendered screen, not selectors or the accessibility tree
- Routines learned from successful runs are reused while the UI stays the same
- When a learned routine stops working, the agent falls back to recovery and finds a new path
- Real behaviour changes still fail the test, so self-healing never hides a regression
- The trace labels each routine, so you can see where the agent had to adapt

### Why scripted tests break

Most mobile test tools find an element by an identifier, a path or a position, tap it and assert on another element. That is fast, and it works until someone redesigns a screen. Then every test built on those selectors fails, even though the app still does what it should. The fix is a person, editing the script.

### How self-healing works in Semaloop

There is no stored list of selectors to repair. The mechanism has four parts, and it helps to be specific about each.

- The spec states the goal and what should be true afterwards, not the path. A redesign changes the path, not the goal.
- The agent works from what is rendered on screen. A restyled, moved or renamed control is just a screen that looks different, and the agent reads it again.
- Skills are repeatable routines the agent learns from successful runs, such as how to complete onboarding or perform a search. While the UI stays roughly the same, later runs reuse them, which is faster. The trace marks them New Skill Learned or Existing Skill.
- If the UI has shifted or a skill hits a hiccup, the agent falls back to recovery mode and finds a new way to the goal. If it cannot, the trace says Existing Skill Failed.

### What self-healing does not do

It does not make a test pass. If the behaviour your spec describes is broken, such as a checkout that no longer shows the right total, the test fails, because the judging step checks the outcome against your description. That is the point: the agent adapts to how the app looks, not to what it does.

It does not rewrite your spec, and it does not discover flows nobody described. A spec needs editing when the product behaviour it describes genuinely changes. Editing a spec also invalidates its learned skills, so expect the next run to take longer while they are relearned.

### Keeping maintenance low in practice

Self-healing does most of its work when specs are written as outcomes. Describe the goal rather than the taps, keep the data, check something that stays on screen, and keep each test to one workflow. Give the agent the state it needs with secrets and custom tools rather than assuming it.

If the agent keeps getting stuck on one part of a test, give a thumbs down to the skill in the trace. That invalidates it, and the agent relearns that part on the next run.

### For UK teams

Semaloop is a London company and publishes its data processing agreement at /dpa, which is useful to have to hand when a UK security or procurement review asks how test runs are handled.

### Frequently asked questions

#### What is self-healing mobile test automation?

It is test automation that keeps working when the app's interface changes, instead of failing on a selector that no longer matches. Tools do this in different ways. In Semaloop there is no selector to repair, because the test is a description of intent and the agent finds the route to the goal on each run.

#### Does Semaloop rewrite my test when the UI changes?

No. The spec stays exactly as you wrote it. The agent adapts at run time, and the routines it has learned are refreshed when they stop working. You edit a spec when the product behaviour it describes changes.

#### What happens to my tests when a screen is redesigned?

Usually nothing needs updating. The spec describes an outcome, so a moved button or renamed label leaves it valid. The first run after a redesign may be slower while the agent finds the new route and relearns its routines.

#### Can self-healing hide a real bug?

It should not. The agent adapts to how the app looks, but a judging step checks the result against your description. If the behaviour is wrong, for example a wrong total or a missing confirmation, the test fails.

#### How do I see when the agent had to adapt?

Open the run's trace. Steps are labelled New Skill Learned, Existing Skill or Existing Skill Failed, and each step shows the agent's reasoning, alongside the video.

#### How much maintenance do Semaloop tests still need?

Far less than a scripted suite, but not none. You revise a spec when the behaviour it describes changes, add tests for new flows, and keep credentials and setup tools current.

### Related reading

- [Skills](https://docs.semaloop.com/test-results/skills/)
- [Core concepts](https://docs.semaloop.com/getting-started/core-concepts/)
- [Best practices](https://docs.semaloop.com/writing-tests/best-practices/)
- [Semaloop vs testRigor](https://semaloop.com/compare/testrigor)
- [Semaloop vs TestMu AI](https://semaloop.com/compare/testmu-ai)
- [Semaloop vs Drizz](https://semaloop.com/compare/drizz)

## Debugging mobile test failures

Source: https://semaloop.com/use-cases/debugging-mobile-test-failures

When a test fails, Semaloop gives you a high-FPS video replay, a step-by-step interaction timeline, system logs, network activity, a root cause analysis and a suggested fix, all on the run's page.

### What you get

- High-FPS video replay, with audio where the test used the microphone or played media
- An interaction timeline showing every step and the agent's reasoning
- System logs and network activity, with logs downloadable from the dashboard
- A root cause analysis and a suggested fix on every failure
- A ready-made prompt that hands the run to your coding agent over MCP
- Build summaries and questions in natural language across runs, for failures that span builds

### What you see on every run

A run ends in one of three outcomes. Success means the agent verified the behaviour. Failure means it could not verify that the functionality worked as expected. Error means the run hit a problem on Semaloop's side, such as a model provider outage, and the Semaloop team is told.

- Video replay: a high-FPS recording of the whole run
- Interaction timeline: a step-by-step trace with the reasoning behind each step
- Audio capture: any microphone input or media playback is included in the video
- System logs: what your app output during the run
- Network activity: responses, headers and timings
- Issues: friction the agent found along the way, such as a slow page or text that is cut off

### From failure to cause

On a failure, Semaloop combines everything its agent had, including the system and network logs, into a short root cause analysis and a suggested fix. Start there, then check it against the evidence.

Step through the trace with j and k, and play or pause the video with the space bar, to see exactly which step went wrong and what was on screen. Then open the system logs and network activity to confirm what happened underneath, for example a request that returned an error. Both logs can be downloaded.

### Fixing it with your coding agent

Every failure has a Send to agent prompt containing the run's ID. With the Semaloop MCP server connected, a prompt such as 'Help me fix Semaloop test run' followed by that ID lets your coding agent pull the run, the video, the network logs and the system logs, work out whether the app broke or the test was brittle, and then push a code fix or revise the spec in the same session.

### Failures that span builds

Once every run on a build has finished, a written build summary says what changed since the last build, with each change linked to its run. Ask answers questions in natural language about an app's builds, tests and runs, such as which tests started failing or whether a failure only happens on one device.

Ask works from results and root cause analyses. It cannot see a run's video, trace, logs or network traffic, so it points you to the run's page for those. Recurring problems are grouped into issues across runs.

### Limits worth knowing

A root cause analysis is a summary and a suggestion, not a guarantee, so treat it as a strong starting point. If a result looks wrong, answer 'Was this result correct?' on the run page. The answer is used to train the agents, with no effect on that run.

### For UK teams

Run videos, logs and network traces can contain data from your test accounts. Semaloop holds SOC 2 Type II certification, and a data processing agreement is published at /dpa.

### Frequently asked questions

#### How do I debug a failed mobile test in Semaloop?

Open the run. Read the root cause analysis and suggested fix, step through the interaction timeline against the video replay, then confirm in the system logs and network activity. Or send the run to your coding agent with the Send to agent prompt.

#### What does a Semaloop failure include?

A high-FPS video, an interaction timeline with reasoning, system logs, network activity, audio capture where relevant, any issues the agent found, a root cause analysis and a suggested fix.

#### Can I download the logs?

Yes. Both system logs and network logs can be downloaded from the Semaloop dashboard.

#### Can a coding agent fix a failure for me?

It can start the work. Connected to the [MCP server](https://docs.semaloop.com/integrations/mcp-server/), an agent can pull the run's video, logs and root cause, decide whether the app or the test is at fault, and propose a code change or a revised spec. You review and merge as usual.

#### What is the difference between a failure and an error?

A failure means the agent could not verify that your functionality worked as expected. An error means the run hit a problem on Semaloop's side, such as a model provider outage, and the team is informed.

#### Can I ask questions about my results?

Yes. [Ask](https://docs.semaloop.com/test-results/ask/) answers questions in natural language about an app's builds, tests and runs, and links to the runs it mentions. It cannot see a run's video, trace, logs or network traffic.

### Related reading

- [Reading test results](https://docs.semaloop.com/test-results/reading-results/)
- [Debugging failures](https://docs.semaloop.com/test-results/debugging-failures/)
- [Build summaries](https://docs.semaloop.com/test-results/build-summaries/)
- [Semaloop vs BrowserStack](https://semaloop.com/compare/browserstack)
- [Semaloop vs Kobiton](https://semaloop.com/compare/kobiton)
- [Semaloop vs Sauce Labs](https://semaloop.com/compare/sauce-labs)

## Mobile test integrations: GitHub, Slack, webhooks, MCP and CLI

Source: https://semaloop.com/use-cases/mobile-test-integrations

Semaloop integrates with GitHub (pull request checks and a build-push Action), Slack, webhooks, an MCP server and a CLI, so builds go in from your CI and results come out where your team already works.

### What you get

- GitHub Action to push builds, and pull request checks for the results
- Slack channel summaries for each build, and direct messages for a single test
- Signed webhooks, delivered by Svix, when a run succeeds, fails or errors
- A remote MCP server so a coding agent can write tests, run them and read failures
- A CLI and a three-call upload API to push builds from any CI system
- A route into Jira, Linear or any tracker through a webhook or an agent

### Which integration does what

Builds go in through TestFlight, the CLI, the GitHub Action or the upload API. Results come out through any of the others.

| You want to | Use | How it works |
| --- | --- | --- |
| Test every iOS build | TestFlight | Agents join your group and pick up each build |
| Push a build from CI | CLI, GitHub Action or upload API | An .app, .ipa or .apk is uploaded with an API key |
| See results on a pull request | GitHub checks | Reported when the build was pushed with the Action or CLI |
| Get a summary in chat | Slack | A channel summary per build, and DMs for one test |
| Trigger your own tooling | Webhooks | A signed test_run.status_changed.v1 event per finished run |
| Let a coding agent write and fix | MCP server | Create tests, trigger runs and pull video and logs |
| File failures in Jira or Linear | Webhook or MCP | No native integration; both routes work today |

### GitHub pull request checks

Connect the repository in Settings, then add the build-push Action to a workflow with a Semaloop API key stored as a repository secret. The Action works out the repository, commit and ref for you. When builds arrive this way, the results of the tests run against them are reported on the pull request as checks.

Pull request checks are GitHub-only today, and they need builds pushed through the Action or the CLI. TestFlight builds are not tied to a commit. On other CI systems, push builds with the CLI and use a webhook to post results.

```yaml
- uses: semaloop/cli/actions/build-push@v1
  with:
    path: build/YourApp.app
    api-key: ${{ secrets.SEMALOOP_API_KEY }}
```

### Slack

A channel of your choice gets a summary whenever a full suite run completes on a new build, and the message updates in place if a result changes because a spec was edited. You can also subscribe to a single test and get its outcome as a direct message. Channel summaries are sent for automatic runs only.

### Webhooks

Semaloop sends a signed webhook to your endpoint when a run reaches success, failure or error. The event is test_run.status_changed.v1, and its payload carries the app, test, build and run IDs, a link to the run and the failure or error reason. A transformation in the webhook portal can cancel everything that is not a failure.

```json
{
  "type": "test_run.status_changed.v1",
  "data": {
    "previousStatus": "pending",
    "nextStatus": "failure",
    "testRunId": "a379af73-217d-464b-b4ee-266b63a1f48d",
    "url": "https://app.semaloop.com/app/uk_example_app/run/a379af73…",
    "failureReason": "Tapping 'Sign in' showed an error"
  }
}
```

### MCP server and CLI

The MCP server runs at mcp.semaloop.com over Streamable HTTP with OAuth 2.1 sign-in, and CI or headless agents connect to the API-key endpoint instead. It can discover apps, builds and tests, create and update tests, trigger runs, pull root cause analysis, video and logs, track issues, and manage secrets and custom tools.

The CLI is in early access. It installs with Homebrew or as a downloaded binary, authenticates with an API key from Settings, and pushes builds with semaloop build push. Its git flags let results come back as pull request checks.

### Jira, Linear and other trackers

There is no built-in Jira or Linear integration. Two routes work today: a webhook that opens a ticket when a run fails, or a coding agent connected to both the Semaloop MCP server and your tracker. The documentation has a worked guide for each.

### Frequently asked questions

#### Does Semaloop integrate with GitHub?

Yes. A GitHub Action pushes your builds to Semaloop, and when builds arrive that way from a connected repository, the test results are reported on the pull request as checks.

#### Does Semaloop send results to Slack?

Yes. A channel gets a summary when a full suite run completes on a new build, and you can subscribe to a single test to get its result as a direct message. Manual reruns do not post a channel summary.

#### Does Semaloop support webhooks?

Yes. Semaloop sends a signed test_run.status_changed.v1 webhook when a run succeeds, fails or errors, delivered by Svix, with a portal to inspect and replay deliveries.

#### Does Semaloop have an MCP server?

Yes. It runs at https://mcp.semaloop.com/mcp, with OAuth 2.1 sign-in, and at https://mcp.semaloop.com/mcp/key for CI with an API key.

#### Is there a Semaloop CLI?

Yes, in early access. semaloop build push sends an .app, .ipa or .apk to Semaloop from any CI system, and installs with Homebrew or as a binary from the releases page.

#### Does Semaloop integrate with Jira or Linear?

Not natively. Use a webhook to open a ticket when a run fails, or connect a coding agent to the Semaloop MCP server and your tracker's own server.

### Related reading

- [Integrations overview](https://docs.semaloop.com/integrations/)
- [Test notifications](https://docs.semaloop.com/test-results/notifications/)
- [Jira and Linear](https://docs.semaloop.com/integrations/jira-and-linear/)
- [Semaloop vs BrowserStack](https://semaloop.com/compare/browserstack)
- [Semaloop vs TestMu AI](https://semaloop.com/compare/testmu-ai)
- [Semaloop vs Klarent](https://semaloop.com/compare/klarent)