Developers

One app release. Every flow after that ships from Studio.

Your engineers add the Swift package and register the components your app already ships, then map each action a flow may take to your app’s navigation.

Your app: The SDK, added in one release. Swift today, with Android and React Native in the first half of 2027.
Your CRM: Who each customer is and what they have consented to.
Your catalog and loyalty program: Connected through MCP (Model Context Protocol) connectors, so every price and point on a screen is live.
Your push provider: Delivers each notification with the link Ambipath created for its screens.

Add the Swift package and configure it with your key.
Call identify when a customer signs in.
Register the components a screen may use.
Map each action, such as reorder or open settings, to your navigation.
Declare one route for Ambipath’s links.

RoostAmbipath.swiftRoost’s integration, shortened

import AmbipathKit

// At launch, with the key you were issued
Ambipath.configure(apiKey: key)

// On sign-in: who, and whether an order is open
Ambipath.identify(userId: member.id, traits: [
    "firstName": member.firstName,
    "midOrder": !bag.isEmpty
])

// Components Roost already ships
Ambipath.register("OrderCard") { props in
    OrderCardView(order: ComposedOrder(props.any("order")))
}
Ambipath.register("RewardTile") { props in
    RewardTileView(rewardId: props.string("rewardId"))
}

// A tap on a built screen, into Roost's own navigation
Ambipath.onAction { event in
    RoostRouter.shared.handle(event)
}

Roost registered five components and six actions. Every Roost screen in the examples was built from them, with no release after the first.

Boundaries

Your app stays in charge of what it draws.

The SDK renders only what your build registered, in your design tokens, and it steps aside whenever it cannot help.

Your tokens only: Every color, typeface and radius on a screen comes from your design system. The SDK draws no spinner, error state or placeholder of its own.
Prices from your systems: Prices, points and offers are bound from your catalog and loyalty connectors. A screen that states a price your systems did not supply is rejected.
Falls back on failure: If Ambipath cannot answer, the link opens the screen your app would have opened, and a composed slot draws nothing.
Only the data you send: The SDK links no framework that can read contacts, location or health data. Every trait beyond a user ID is one you chose to send.
Only components this build has: The model is offered only the components the installed build registered, so a screen never uses one shipped in a later release.

Questions

What engineering leads ask first

What happens if Ambipath is slow or down?: Your app keeps working as it does today. The first screen of every flow is built before the notification is sent, so a tap never waits on a model. If Ambipath cannot answer, the link opens the screen your app would have opened without it.
What customer data does it use?: Only the fields you choose to send. The SDK records in-app behavior and the events you declare, and your connectors return only what you expose. It reads nothing from the phone outside your app, and you can delete a customer’s data on request through an API.
What do our engineers maintain?: After the first release, engineering registers a component when the design team ships a new one. New objectives and flows need no release.

See what Ambipath would build for your app.

Talk to the founders