Builder.io writes web code, and its React Native support is an SDK, not an output.
This is the one distinction that decides whether Builder.io can get you to a phone. Builder documents its code product as a way to prototype ideas, build new web applications, or convert Figma designs to code, and the result lands in a repository you already have as a pull request. React Native does appear in the documentation, in a completely different place: it is one of the frameworks the Builder Content SDKs support, so content you author in Builder can be rendered inside a React Native app that already exists. Those two sentences are not the same offer. One generates code for the web. The other fills screens in an app somebody else built. Every claim about Builder on this page comes from Builder's own documentation at builder.io/c/docs, read on 23 October 2026. If a phone app is the goal, start from build mobile app without coding.
What follows is what Builder actually hands you, exactly how far the React Native SDK goes and which blocks it cannot render yet, what became of the name Visual Copilot, and what Apple says about the shortcut of wrapping a Builder page in a shell. Two findings are worth flagging up front. Builder ships a switch that stops people authoring content a phone cannot display. And when its own documentation needs an app to put the content into, it tells you to go and create one with create-expo-app or Xcode.
Start hereThe short version
Builder fills screens. Somebody still has to build them.
Builder describes its own position plainly on the page about how Builder works. You control your site, code and hosting, and Builder only passes content to your site or application rather than hosting it. That sentence is about the web, and it carries across to a phone without much change. Builder is a content layer with a visual editor on top. It is not a thing that produces an app binary, and nothing in the documentation claims it is.
So there are two honest routes out of a Builder design. Keep Builder as the content layer and have a real React Native app built around it, which is what the Gen 2 React Native SDK is for. Or treat the Figma file as the brief, describe the app you want, and have the project generated. Plenty of teams end up doing both, because the screens that need to work offline and the banners that change weekly are different problems.
What does Builder.io actually hand you?
Code in your repository, and content served to an app you already run. Builder's page on Projects from prompts puts the code half in two lines. Builder Code Projects provides a way to create and iterate on applications using AI and visual editing. Prototype ideas, build new web applications, or convert Figma designs to code. The key concepts page is clearer still about where the output goes. You link a GitHub, GitLab, Azure DevOps or Bitbucket repository, and all Builder Code changes are delivered as pull requests to that repository.
The Figma side has three documented doors. You copy a link to a frame in Figma and paste it into the Projects AI prompt. You use the Builder Figma plugin, which gives you Smart Export and Classic Export. Or you run the Builder CLI inside your own project, which Builder says detects your framework and adds files to the appropriate directories, reuses existing components, libraries and styles, and preserves logic such as form validation and conditional rendering. A .builderrules file at the project root steers it toward your own components. There is a return trip too, through the Export to Figma item in a Project's three dot menu.
Now read the promise at the top of Builder's Import from Figma overview, which is to generate code for your designs no matter the platform. That sentence names no platform, and the page under it names none either. The word that does appear, on the Projects from prompts page, is web. Hold that next to the fact that Builder also publishes an SDK comparison page listing React Native among its supported frameworks, and you have the whole misunderstanding this page exists to clear up. Builder supports React Native as a place to deliver content. It does not offer React Native as a thing it writes for you.
There is a cleaner way to check this than reading any one page. Builder publishes a documentation sitemap at builder.io/sitemap.docs.xml, and on 23 October 2026 it listed 387 pages. All 387 were fetched and searched for the words a mobile release is made of. TestFlight appears zero times. Google Play appears zero times. Play Console, App Store Connect, APK and provisioning profile each appear zero times. The only mention of an app store on any of the 387 pages is Shopify's, in a note about cancelling a subscription you bought through the Shopify App Store. A product that shipped mobile builds would say so somewhere in 387 pages.
Builder.io documentation, SDK comparison, read 23 October 2026
Is React Native a supported output target?
It is a supported SDK, which is a different thing, and the documentation is precise enough to settle the question. On the SDK comparison page React Native sits in the list of frameworks with no Gen 1 SDK and a Gen 2 SDK marked as recommended. The package is @builder.io/sdk-react-native. The code samples use the same imports as the web SDKs, so Content, fetchOneEntry, fetchEntries and register all appear. One small detail gives the game away about what kind of integration this is: on the Content component page, the wrapping element defaults to a div, and in React Native it is a ScrollView.
Support is uneven, and the uneven parts are the interesting ones. Builder's feature table marks four things as in development for React Native: TypeScript types, animations, widgets and variant containers. It marks five rows as not applicable: server and static rendering, A/B tests with server or static rendering, custom fonts, global content styles, and CSS nesting with the ampersand operator. That second group is a list of web concepts a native view tree does not have, so it will stay marked that way. The things carrying a full tick are the ones most teams use day to day, including A/B tests, custom components, dynamic data bindings, Symbols, locales, tracking and heatmaps. Worth noticing what is absent: of the 22 rows in that table, React Native has 13 full ticks, 4 marked in development and 5 marked not applicable, and not a single row marked not supported. Builder is not half-hearted about React Native. It is just pointed the other way.
Builder's Integrate Pages guide settles the direction in its second sentence, before any framework tab loads. It says Builder highly recommends that you integrate Builder into an existing app, and that the instructions assume you already have one. Pick the React Native tab on that page and the setup is npm install @builder.io/sdk-react-native followed by npm run web, which runs your React Native app in a browser. There is a Swift tab as well, marked in beta, which has you add the builder-swift package in Xcode under Frameworks, Libraries, and Embedded Content. In the generation table Swift in beta is listed with no Gen 1 and no Gen 2 SDK. Native iOS is a documented destination for Builder content and it is the least finished one.
Follow where that guide sends you if you do not have an app yet, and the question answers itself. Xcode turns up on exactly two of the 387 documentation pages. One is that integration guide, adding the builder-swift package. The other is a page called Creating an app, which the integration guide links precisely because it assumes you already have one. Pick the React Native tab there and the instruction is to run npx create-expo-app@latest, then read the React Native documentation on setting up the development environment. Pick the Swift tab and it is open Xcode, File, New, Project, and choose App in the iOS section. Builder's own documentation gives the job of creating the app to Expo or to Xcode, and picks the story up again once an app exists.
Then there is a switch most write-ups of Builder never reach. On Builder's Advanced settings page there is a Space level option called Target React Native. Builder describes it as a way to indicate that you intend to deploy your content to React Native, and says that turning it on restricts the visual editor to prevent anyone in your Space from creating content that does not work in React Native. Under it sits Strict React Native Style Validation, which sets whether a problem appears as a warning or an error. The guard rail is on the editor rather than on the output, which tells you the direction the support runs in.
Builder.io documentation, SDK comparison feature and blocks tables, read 23 October 2026
Check your design
Which Builder blocks the React Native SDK renders today
Tick the blocks your Builder content uses. The support state on the left is taken from the blocks table on Builder's own SDK comparison page, read on 23 October 2026, where a tick means full support and a blue dot means in development. The note is what that leaves you to answer for.
Nothing ticked yet. Start with the block your design would be useless without, because that is the one worth checking before you plan anything.
What happened to Visual Copilot?
It is being renamed, and the rename is most of the way through. If you arrived here with the name in your head, that is worth knowing before you go looking for a feature that no longer answers to it. As of 23 October 2026 the documentation navigation has no Visual Copilot section at all. The section that covers designs is called Import from Figma. The path builder.io/c/docs/visual-copilot returns Page not found. Two older paths still work as redirects: ve-visualcopilot and vcp-create-content both land on builder.io/c/docs/visual-editor-ai, a page titled Visual Editor AI.
The old name has not been scrubbed everywhere. It shows up in the body of the Visual Editor AI page itself, in a line on the Get started with Publish page telling you to use Visual Copilot AI to add interactivity, and in the Builder Code metrics API, where the designExports key is described as the number of design component exports or Visual Copilot references and exports. The same page documents a feature identifier whose example values are fusion and vcp, and a designExportId described as a Visual Copilot component export identifier. So the acronym VCP is still load bearing inside an API response while the product name above it has changed. That is normal for a rename in flight, and it is why a guide written off an old blog post will send you hunting for buttons that are not there.
What the surviving page describes is also narrower than the old name suggested. Builder says Visual Editor AI generates and edits content, styles components from style guides, adds interactivity by connecting content to data or responding to user actions, and creates mini apps. That is an assistant inside the Builder editor working on Builder content. The Figma to code work has moved out to Import from Figma, the Builder Figma plugin and the Builder CLI. Neither description mentions a mobile platform. If you came from a design-handoff tool rather than from Builder, the same shift has happened elsewhere, and locofy to mobile app covers a tool that answers the same question differently.
Builder.io and an app builder, job by job
The left column is what Builder documents today. The right column is what an app builder does. Read it as a list of jobs rather than a scoreboard, because the two tools are good at different halves of the same project and the bottom row is a no for both.
| The job | Builder.io | An app builder like Newly |
|---|---|---|
| Generates code from a Figma frame | Yes | No, you describe the app instead |
| Writes into a repository you already own | Yes, as pull requests | Yes, through two-way GitHub sync |
| Produces a React Native and Expo project | No | Yes |
| Creates the app project itself | No, the docs send you to create-expo-app or Xcode | Yes |
| Renders content inside a React Native app you already have | Yes, through the Gen 2 React Native SDK | Not its job |
| Uploads an iOS build to TestFlight | No | Yes |
| Publishes to Google Play internal testing | No | Yes |
| Lets non-developers edit the screen after launch | Yes | Only by prompting another change |
| Submits to the App Store for you | No | No |
Can you wrap a Builder page in a shell and ship it?
You can build it, and Apple has a clause written for it. Guideline 4.2 says your app should include features, content and UI that elevate it beyond a repackaged website, and that an app which is not particularly useful, unique or app-like does not belong on the App Store. Guideline 4.2.2 says that apart from catalogs, apps should not primarily be marketing materials, advertisements, web clippings, content aggregators or a collection of links. A shell whose only screen points at a page you built in Builder is the shape both sentences describe, and a reviewer can see it in under a minute.
Builder's own architecture makes the shortcut worse than it looks. The page on how Builder works says Builder only passes content to your site or application rather than hosting it, and that Builder content loads asynchronously, immediately after your page loads. On a desktop browser that is a sensible performance choice. On a phone in a lift it means the screen is empty, then the screen is empty, then the user closes your app. The web view also cannot send a push notification, cannot read a barcode without the permissions plumbing you would be adding anyway, and holds no state when the connection drops mid-task.
Note what guideline 4.2 does not say. It does not ban web views, and a great many shipped apps contain them. The test is about the app as a whole and whether there is enough of it to be worth installing. A real native form, a list that survives no signal, and a notification when something changes all count toward passing that test. A frame around a URL does not. If your starting point was a design tool rather than a content platform, the same reasoning from that angle is in uizard to mobile app.
What carries over if you build the app properly?
More than people expect, because the valuable half of a Builder setup was never the page. Your design tokens, your custom components, your Symbols and your content entries all stay where they are. The API key stays the same. If you keep Builder as the content layer, the Gen 2 React Native SDK reads the same entries your website reads, and the people who edit a banner on Tuesday carry on editing it on Tuesday. What you are replacing is the rendering of interactive screens, which is the part the blocks table already told you Builder does not finish on a phone.
Two decisions are worth making before anyone writes code. First, draw the line between content and screens. A hero, a promo card and an announcement bar are content, and Builder is better at them than you are. A sign-up flow, a scanner and a checkout are screens, and they belong in the app. Second, decide what happens with no network, because that single question reshapes more designs than any other. Builder content arrives after the page loads, so anything the user must be able to do on a train has to live in the app and not in a content entry.
Newly is an AI app builder for the screens half. You describe the app in plain English and it writes a real React Native and Expo project you own, with two-way GitHub sync so the code is never somewhere you cannot reach. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It is $25 a month, with no free tier. What it will not do is press submit on the App Store for you, and that is on purpose. Apple guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content, and that these services should not submit on behalf of their clients. The mechanics of your side of that step are in publish to app store.
One last thing. Do not throw Builder out. The expensive version of this migration is the one where the marketing pages get rebuilt too, and every copy change then needs a release. Keep the content layer, point it at the app through the React Native SDK, and spend the effort on the screens that could never have been content.
Questions people ask about Builder.io and mobile apps
No. Builder documents its code product, Builder Code, as a way to prototype ideas, build new web applications, or convert Figma designs to code, and the output goes into a repository you already have as a pull request. React Native appears in Builder's documentation in a different role: as one of the frameworks its Builder Content SDKs support, so Builder-authored content can be rendered inside a React Native app that already exists. There is no documented step anywhere that produces an iOS or Android build. All 387 pages in Builder's documentation sitemap were fetched on 23 October 2026 and the words TestFlight, Google Play, Play Console, App Store Connect and APK return zero hits between them.
Keep the content. Build the screens.
Write down which of your Builder blocks are layout and copy, and which ones take input from a person. The second list is the brief for the app, and the first list can stay exactly where it is.
Start building