I built a macOS app to make mobile E2E testing less awful
Testing mobile apps sucks.
You either click through the same flows manually before every release, or you commit to a heavyweight automation stack that demands code, infrastructure, and a budget you don't have. For indie developers and small teams, neither option fits. You want confidence in your release without turning testing into a second job.
I ran into this repeatedly while shipping apps. So I started building Qampanion.
What it is
Qampanion is a macOS app for creating and running end-to-end tests for iOS and Android. You build test cases visually — tap, swipe, type, wait — instead of writing scripts. It runs on your machine against Xcode simulators and Android emulators, compares screenshots to catch regressions, and handles device setup, app installs, and test execution in one place.
You can also mix in API requests, bash scripts, and reusable linked steps when a pure UI flow isn't enough.
How Qampanion differs
Most mobile testing tools fall into two camps.
AI-first runners generate a new test plan every time you hit run. That means you pay for tokens on every execution, and small changes can produce different results. Qampanion generates tests once, with or without AI, then runs them statically. Same steps, same screenshots, same outcome every time.
The older enterprise route gives you power, but only if your team writes and maintains test code. Qampanion skips that. You build tests in a visual editor, so a non-technical teammate can create and update cases without opening an IDE.
Everything runs locally on your Mac. Your app, your screenshots, and your test data never leave the machine. The project file is plain and versionable, so you can launch it in CI/CD the same way you launch it locally.
The MCP integration is the bridge between the two worlds. Connect any AI agent, describe the flow you want, and the agent will tap through the app and build the test case for you. After that, the test runs on its own. You can also take an existing iOS test case and adapt it for Android without rebuilding it from scratch.
Three ways to work
I didn't want another tool that forces a single workflow:
- Visual editor. Build tests with clicks. No code.
- CLI. Run tests from the terminal or wire them into CI/CD.
- MCP / AI. Connect an AI assistant and generate or adjust tests from descriptions.
The idea is simple: start visual, automate the repetition, and let AI speed up the parts that still feel tedious.
Who it's for
- Indie developers shipping solo and tired of manual regression checks.
- Small teams that need reliable testing without enterprise tooling prices.
- QA engineers who want to spend less time on setup and more time finding real bugs.
Current state
Qampanion is in public preview, free to use, and I'm looking for early adopters. It's built natively in Swift, keeps your data on your machine, and requires macOS 15+.
I'm actively developing it around real testing pain points — visual editing, fast local execution, and AI-assisted test creation. If mobile testing frustrates you too, I'd love your feedback.
I'm looking for my first early users to help shape the product, so if this solves a problem for you, I'd love to hear how it fits into your workflow.
I’m developing indie iOS applications, and I test them manually. For example, when I add new functionality to my app, I test it manually before release (and usually check the whole app with all flows), then I publish it in TestFlight for a small test group to catch typical bugs. After that, I publish the new release.
If an application is not too big, it doesn’t take much time. But I have a few really big apps, and in this case, it is really hard to check the whole app.
I have tried testing through Claude Code with skills, but it spent all the daily limits :D
Thanks for laying out your whole flow — that "check every flow before each release" step is exactly the pain I built this around, and it's the part that stops scaling once an app gets big.
On the Claude Code point: that's actually why I went with a test-editor approach instead of a pure agent. With an agent, every run re-invokes the LLM, so regression testing burns tokens (and daily limits) every single time. In Qampanion you author a test once — visually, or via the MCP integration if you want AI to draft it — and after that the runs are deterministic replays on the simulator. So the AI cost is one-time authoring, not recurring execution, and you can re-run the whole suite on every release for free.
Snapshot comparison also helps with the "big app" case — instead of eyeballing every screen, it flags visual regressions for you. It's a free public preview right now (macOS 15+, iOS sims), so it could slot in right before your TestFlight step.
Question for you: for your big apps, roughly how many distinct flows would a "full" regression pass cover? Trying to figure out where manual stops being viable — and whether people would rather hand-author those tests or let AI draft them first.
My biggest app has about 30 screens. They link into different flows based on user parameters, so the paths change dynamically. I cannot test all real user paths by hand :D
I would start with the main flows and add more over time.
Yeah, 30 screens with paths that change by user parameters is very hard to test by hand. You don't need every path. Start with the main flows and add more later.
In Qampanion each flow is one test. You build it once and run it again for free on every release. Snapshot comparison checks every screen for you.
For the dynamic paths, you can add an API request step. It sends an HTTP request to set the user into the state you want, and then you check that path. So the paths become clear, repeatable tests.
How do you set these user states now when you test by hand? Staging backend, feature flags, or different builds?
Nice app, but there are a few tools like this nowadays
The real challenge isn't making ui tests easier to create - it's making them easy to maintain
That's usualy where tools like these struggle
Fair point.
We can't honestly promise that maintaining tests will always be easy. What we can do is provide tools that reduce the maintenance burden: built-in test data setup, device preparation, reusable test cases, and flexible ignore/assertion zones to make tests less sensitive to UI changes. Our goal isn't to eliminate maintenance - it's to make it much less painful
We have AI too - for people who don't even want to write the test😄
The real work starts after generation, though
Looks interesting. One thing I'm wondering: if I generate tests with AI, do I have to pay for AI tokens every time I run the test, or is AI only used during test creation?
Great question. AI is only used when you choose to generate or modify a test. Once the test is created, it's just a static test case, so every execution is completely free and doesn't consume any AI tokens. You can run it as many times as you want locally.
Thanks, that makes sense. Appreciate the clarification!
I like that you're reducing the cost of writing tests, but I'd pay even more attention to reducing the cost of maintaining them.
A lot of teams don't avoid test automation because creating tests is hard. They avoid it because every product change threatens to break the suite. If maintenance becomes dramatically easier, that's a much stronger reason to switch than "no code."
This comment was deleted 6 hours ago.