Agents write code at the speed of light. So why would they need a platform?

Your app is built once with the Ripul SDK and goes through App Review like any other. From then on its screens, forms and data come from a description your agent writes. Change the description and the app follows the next time it opens: no build, no upload, no wait.

Most changes are to screens, forms and data, and never need a build. Some still do: the app itself, a new kind of building block, or your own native code. Those go through Xcode and Apple as before, and once a new building block is in the app, every screen can use it live.

When a build is needed, a fleet of agents meets a different bottleneck: the machines. A laptop used to be enough for one developer. A fleet of agents needs a fleet of Macs, because every agent wants to build at once and every build wants every core.

We hit it ourselves. One afternoon in October our Mac Studio was running seven builds at once and had slowed to a crawl, while the MacBook beside it sat almost idle.

Trainyard, part of Ripul, shares the work out across your Macs.

A few builds per Mac

Each Mac runs as many builds at once as it can take, and the rest wait their turn. It works in any project, with nothing to set up.

The Mac with room

A build can go to whichever of your Macs has the most to spare, and the finished build comes back to the agent that asked.

Shared, in turn

Simulators are lent out and given back, a test phone is held while someone tests on it, and releases go out one at a time.

In view on your phone

See what is building, what is waiting and why.

It isn't a website inside an app. Every screen is drawn with Apple's own controls: lists, menus, date pickers, sheets, and Liquid Glass where iOS has it. It feels like an iPhone app because it is one.

The same description also works as a website.

If you would rather write native apps than use a no-code platform, so would we. That's why the platform doesn't replace your app. It comes in the Ripul SDK, a Swift package you add to the app you already have, and each screen it draws is an ordinary SwiftUI view. Use it for one screen or for most of them, and keep writing the rest in Swift.

Your screens beside its screens

A tab you wrote in Swift sits next to tabs the platform draws, in one tab bar, in one app.

Start with one screen

Put the platform behind the screen that changes most, such as a list, a form or a settings page, and move more over only if it earns its place.

Agents for the code you write

Everything else in Ripul is for native code: agents working in your Xcode projects, builds shared across your Macs, and your app on a real phone, where an agent can press its buttons and read its logs.

An agent inside it too

The same SDK can put an agent in your app that uses the functions your app already has.

You have controls of your own: a chart, a booking calendar, a signature pad your designers spent weeks on. Next, the platform will place them too. Register one of your views under a name, and the agent can put it on any screen, give it data and change its settings, live, like any other building block.

You never send us your components. They stay in your app and go through App Review with the rest of it, and the platform only needs to know their names and what each one needs. That is what native means here: Swift working with your Swift, a whole screen at a time or one control at a time.

Screens, today

Your screens and the platform's sit side by side in one app.

Controls, next

Your own controls inside the platform's screens, placed and set up by the agent.

Your code stays yours

Your components' code never leaves your app. The platform knows each one by its name.

Like the rest of your app

It is your own view, so it looks and behaves exactly as it does everywhere else in your app.

Low-code was made for people who can't write code. Ours was made for agents that can.

It checks its own work

The whole app, every screen and every link between them, checked in milliseconds.

It sees what your customers see

It opens any screen as a particular customer, at phone size, and reads what's there.

It can go back

Versions of the whole app are kept, and returning to one takes a single step.

It works within your rules

The platform enforces who can see and change which records on every request, whatever a screen asks for.