Building Native iOS Apps from Windows with a Team of AI Agents

I build OpenV2. Our product is simple to say and hard to ship: you brief a team of AI agents in chat, and they build a native mobile app — SwiftUI for iOS, Kotlin for Android — that you can preview in a simulator and test on a real iPhone. From Windows. No Mac required.

This post is about why we built it as a team with roles, not as a single prompt box, and what that workflow looks like in practice.

The problem I kept hitting

If you want a real iOS app, the traditional path still assumes a Mac, Xcode, and enough SwiftUI experience to not paint yourself into a corner. That is fine if you are a full-time iOS engineer. It is a wall if you are a founder, a PM, or a developer who lives on Windows or Linux and just wants a native app in the store.

The other path people try is "prompt an AI and hope." One chat, one model, one giant answer. Sometimes you get something that demos well. Often you get:

• Generic UI that looks like every other AI-generated screen
• Architecture that collapses the moment you add auth, payments, or a second platform
• No clear ownership of research, product decisions, or code quality

I wanted something closer to how a small product team actually works: someone owns the brief, someone researches, someone writes a PRD, someone designs the architecture, and one engineer writes the code — with handoffs you can follow.

That is Team mode in OpenV2.

Don't prompt an AI. Brief a team.

OpenV2 has Solo mode and Team mode. Solo is fine for small changes. Team mode is the product bet.

In Team mode, six AI agents work on your project like a development team. They are not six humans. They are six roles with clear jobs and handoffs:

The important constraint: Leo is the only one who writes code. Everyone else exists so Leo does not guess the product, the architecture, or the research in the same breath as the implementation.

What a brief looks like (illustrative)

You do not start with "write me a SwiftUI file." You start with a product brief. Something like this (illustrative — not a transcript from a specific run):

Build a habit tracker called Streak.
Daily check-ins, streaks, gentle reminders.
Native iOS first. Clean, calm UI. Offline-friendly.
I am on Windows; I need to preview in the simulator
and test on my iPhone with the Companion app.

From there the handoffs are intentional:

1. Brief → research — Clara pulls constraints, patterns, and open questions so we do not invent fake requirements.
2. Research → PRD — Maya writes a product definition you can read and push back on.
3. PRD → architecture — Oliver shapes screens, data, and boundaries before implementation.
4. Architecture → code — Leo implements in SwiftUI (iOS) / Kotlin (Android).
5. Review loop — Ethan keeps the thread moving; Sofia surfaces what is worth measuring when the app has something to measure.

You stay in the chat. You can redirect the team. You are briefing a team, not babysitting a single autocomplete.

Native means native

When we say native, we mean the output is a real mobile codebase — SwiftUI on iOS, Kotlin on Android — not a webview wrapped to look like an app.

That matters for:

• Platform UI and navigation that feel like iOS / Android
• Performance and offline behavior that are not stuck behind a browser tab
• A path toward store publishing that starts from real project structure

We also keep the surrounding work in one place: Asset Studio for images and icons (and more), a database, RevenueCat for subscriptions, and a store publishing workflow. The point is not "chat that dumps files." The point is a studio where the team can actually finish an app.

The Windows → simulator → real iPhone loop

This was non-negotiable for me personally. I should not need a Mac just to see whether the thing works.

The loop we ship today:

1. Brief the team from your machine (Windows included).
2. Preview in the OpenV2 simulator while the app is being built.
3. Test on your real iPhone with the Companion app — available on every plan, including Free, within your usage limits. You install Companion because you want device testing, not because you upgraded.
4. Send a UI reference with the screenshot button when you want the team to match something you are looking at.

Two examples we actually built this way:

• Streak — a habit tracker built in Team mode (brief a team, get a native iOS app).
• Cinema seat view — tap a seat, fly into the hall, see the screen from that seat. Built on OpenV2, running in the OpenV2 simulator. No Mac needed for that loop.

Pricing, without the fog

Usage-based. Limits reset every 5 hours and weekly.

• Free — $0
• Pro — $25 / month
• Max — $129 / month (5× Pro usage)

Team mode is on every plan, including Free. Build, simulator, and real-device testing are gated by remaining usage (and by installing Companion if you want the device path) — not by "paywall the team."

What is still rough (honest)

I would rather say this out loud than oversell:

• Team mode is more process than Solo. For a one-line tweak, Solo is often the faster choice; Team mode earns its keep on new apps and bigger features.
• You still have to steer. A bad brief still produces a confused product. The team helps structure the work; it does not replace product taste.
• Store publishing is a workflow, not a one-click fantasy. Native output gets you closer. Review, assets, and compliance are still real work.
• We're early. Expect rough edges, and expect us to earn trust the boring way: working demos, clear docs, no invented metrics.

We are not claiming to be the first or only anything. We are shipping a specific bet: a role-based AI team that outputs native mobile apps, reachable from Windows, with a path to a real device.

Try it

If this workflow matches how you already think about product teams, try a small brief on openv2.dev — Free includes Team mode within usage limits.

Start with something you would actually use for a week. Habit tracker. Seat picker. A thin slice of your real idea. Brief the team. Watch the handoffs. Preview in the simulator. Put it on your phone with Companion if you want the honest test.

That loop — brief → research → PRD → architecture → one engineer writes code → device — is the product.

— Tony Roman, founder of OpenV2