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.
C'est un très beau projet, et merci de votre part
The deterministic angle is the right wedge. Teams get burned twice by AI-first runners, once on tokens per run and once on flaky results they cannot reproduce, so 'same steps, same outcome' is a real buying trigger. My advice: put a price on it now, even in preview, because free early adopters will tell you it's great while never telling you if it's worth money.
useful
Thank you! Do you test mobile apps in your own work?
I’ve avoided full E2E for mobile mostly because maintaining tests becomes a headache after a few UI changes. This visual approach makes sense for small teams.
How do you handle updating tests when the UI changes across multiple flows? Is there some way to edit steps globally or reuse components?
This is the main pain of mobile testing. If your Login screen changes, you do not want to fix 50 tests manually.
We solve this with Linked Steps:
It should be easy to update often-changing flow ;)
Definitely something I'd use.
Thanks, that means a lot. It is a free public preview right now, so you can try it on a real app today.
What kind of app would you test with it first?
Yo that's a really nice project right here but I would have to say that if I don't stop for a little while just to check my post on my feed, I would have skipped yours.
I just wanna say that title doesn't really grab attention at the first, there's a lot of potential that I see from this, just imagine you can sharpen the title by cutting the word and maybe you hook them, grab more attention? For example, instead of saying "I built a macOS app to make mobile E2E testing less awful" now you say "Running E2E Test. Even When You're Sleeping" see the difference? I'm here to offer you that I can help you sharpen it for free in time if you're interested.
Thanks.
Thank you, this is kind of you. And you are right, the title matters a lot. People skip a post in one second, so the first words really need to grab them.
I like how you think about the hook. Your example is catchy. I am open to better titles, so feel free to drop a few ideas here in the thread. What do you think makes a title stop the scroll?
The "generate once, then run deterministically" choice is the part that jumped out. I work a lot with AI coding agents, and the failure mode of AI-first test tools is exactly what you're dodging — if the plan regenerates every run, your suite is non-deterministic, so a "fail" might just be the model taking a different path, not a real regression. That kills trust in CI fast. Using the agent only for the initial authoring (your MCP step) and pinning the flow afterward feels like the right split.
On what breaks tests most: in my experience it's rarely the happy path — it's selectors/anchors drifting after a UI refactor, and telling that apart from an intentional change. How does the snapshot diff handle deliberate UI tweaks (a copy change, a spacing nudge) without drowning you in false positives? That triage step is usually where no-code test tools lose me.
Either way — nice niche, and local-first + native Swift is the right call. Following the preview.
You hit the exact point. Running AI on every test in CI is expensive and flaky. One different token breaks the build.
About deliberate UI changes and false positives:
Qampanion works strictly with screenshot comparisons and coordinates.
If you change the UI on purpose, the test will fail. To handle this without pain, you can:
If you have too many tests to update manually, you can use any AI via MCP. The agent will run the app, find the new coordinates, and record new baseline screenshots. You pay for AI tokens once to fix the suite. After that, you run fast, deterministic tests for free.
The local-first approach is a big part of the appeal here. Static, repeatable tests seem much more useful for regression checking than regenerating a test plan on every run. The MCP integration is especially interesting too: letting an agent create the initial flow, then keeping the actual test deterministic, feels like a practical balance between AI flexibility and reliable CI.
Yes, you got the idea. AI helps you build the first flow, and after that the test stays the same on every run. So you get AI to start fast, but your CI stays stable and cheap.
Local-first was a clear choice for me too. The app and data stay on your machine, and tests run fast because nothing goes to the cloud.
Do you use MCP tools much in your own work? I am trying to learn if that first step feels easy or new for most people.
great
Thank you! It is free to try right now. What would you want to test with it first?
nice work
Thanks a lot! Is mobile testing something you deal with in your own work?
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."
You are right, and this is a great point. Writing tests is only half of the problem. Tests that break on every product change are the real reason teams stop.
A few things help here. The visual editor lets you fix a broken step in a few clicks, with no code to refactor. Snapshot comparison shows you what changed on the screen, so you can see fast if it is a real bug or just a small UI update. And each flow is a separate test, so one change does not break the whole suite.
But you are right that this is the hard part, and I want to make it even better. In your experience, what breaks tests most often? UI changes, new steps in a flow, or changed data?
That's a good question.
The reason I'm hesitant to answer it in a few lines is that I don't think the answer is universal—it depends on the assumptions you're making about what the product should optimize for as it evolves.
I'd rather explain the reasoning in the context of Qampanion itself than give you a generic answer.
If you're open to it, what's the best email to reach you on?
Sure, that makes sense. A good answer depends on the goal, so the context helps.
You can reach me at [email protected]. I would be glad to hear your thinking.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
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?
It sounds like a very useful project
Thank you! It is a free public preview now, so you can try it on a real app today. Do you work on mobile apps yourself?
Yes, that's exactly the idea. You create a test once and run it the same way every time. Because the test stays consistent, regression checks are more reliable and repeatable.
You're also right about small teams. With the visual editor, non-technical team members can create and maintain tests without writing code or using an IDE. That means QA engineers, product managers, and other stakeholders can contribute—not just developers.
Are you part of a small team? I'm curious who would be responsible for creating and maintaining the tests in your case—a developer, or someone in another role?
Generating tests once and running them the same way every time instead of regenerating a plan on each run feels like the more trustworthy approach for actual regression testing.
Letting a non-technical teammate build and update test cases without opening an IDE is the part that probably matters most for small teams.
Yes, that is the main idea. You build a test once and run it the same way every time. This makes regression checks stable, because the test does not change on its own.
And you are right about small teams. The visual editor lets a non-technical person build and update tests with no IDE and no code. So QA and product people can help too, not only developers.
Are you on a small team? I want to know who would build the tests in your case, a developer or someone else.
Nice!
Thanks! Do you build mobile apps yourself?
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!
This comment was deleted 21 hours ago.