Learn how to export your Draftbit project as React Native (Expo) code and run it locally on iOS: install dependencies, start the Expo dev server, open it on your iPhone, and prepare for a native build.
Draftbit's visual editor is fast, but some tasks need real code: custom logic, third-party libraries, or fine-grained control the canvas cannot express.
Because Draftbit generates standard React Native (Expo) code, exporting lets you take the project into a normal developer workflow and keep building.
This also reduces lock-in risk. Your app is not trapped inside Draftbit's servers; it is a React Native codebase you can version-control and extend.
Before you begin, confirm your Draftbit plan includes code export, since availability can depend on your subscription tier. Check current plan details on Draftbit's site.
Install a recent LTS version of Node.js on your machine. Expo and React Native tooling depend on Node and npm or Yarn.
Install the Expo command-line tooling as documented by Expo. Modern Expo projects use commands run through the project itself, so follow the current official guidance rather than older global-install instructions.
On your iPhone, install Expo Go from the App Store for quick previews. For anything that needs custom native modules, you will later use a development build instead.
A basic comfort with the terminal helps. You will run a few commands to install dependencies and start the dev server.
In Draftbit, use the export or download option for your app. This produces a React Native (Expo) project, typically as a downloadable archive or via a repository connection.
Unpack the project into a working folder on your computer. You should see a familiar React Native structure with a package.json, app configuration, and your screens.
Skim the folder to orient yourself. Recognizing where screens, components, and configuration live will make later edits much easier.
Keep the exported project under version control from the start. Initialize a Git repository so you can track changes and safely experiment.
Open a terminal in the project folder and install dependencies with npm install or yarn, depending on the project's lockfile.
This step pulls down React Native, Expo, navigation libraries, and everything the app references. It can take a few minutes on the first run.
If you hit version or peer-dependency warnings, note them but do not panic. Many are harmless; genuine conflicts usually surface as clear errors during install.
A clean install is the foundation for everything after. If it fails, resolve it before moving on rather than trying to run a half-installed project.
Start the development server using the project's start script, typically npm start or the equivalent Expo command. A terminal interface and a QR code appear.
The dev server bundles your JavaScript and serves it to a client on your phone or a simulator. Leave it running while you work.
If the bundler reports errors, read them carefully. Import path problems and missing dependencies are the most common early issues and are usually quick to fix.
Keep this terminal visible during development. It is where you will see logs, warnings, and reload activity as you iterate.
With Expo Go installed, scan the QR code from the dev server using the iPhone Camera or the Expo Go app. The bundle downloads and your app launches.
Alternatively, if you have Xcode and the iOS Simulator on a Mac, you can open the app in the simulator directly from the Expo dev tools.
Test the same things you would in Draftbit's preview: navigation, data loading, and layout against the iPhone's safe areas.
Expo Go is perfect for standard components. If your app depends on custom native modules not included in Expo Go, that is your signal to move to a development build.
Now that the project is yours, you can edit code. Open it in an editor like VS Code and locate the screen or component you want to change.
With the dev server running, fast refresh applies most changes instantly on the device. This tight loop makes experimentation low-risk.
Commit working states frequently with Git. If a change breaks something, you can revert cleanly instead of guessing what you altered.
Be aware of the one-way nature of heavy edits. Once you diverge significantly in code, round-tripping back into Draftbit's visual editor is not the intended workflow, so plan where your source of truth lives.
Spending a few minutes to understand the exported project pays off quickly. At the root you will find a package.json listing dependencies and scripts, plus an Expo app configuration file that holds your app name, identifiers, and asset references.
Screens and components typically live in clearly named folders, mirroring the structure you built visually in Draftbit. Recognizing this mapping makes it far easier to find the code behind a given screen.
Navigation configuration, data source definitions, and any shared styling or theme values usually have their own locations as well. Skim each so you know where to look when something needs changing.
You do not need to understand every line to be productive. The goal is orientation: knowing roughly where UI, navigation, and data logic live so edits are targeted rather than guesswork.
Once you export, you face an important decision: is the Draftbit project or the code your source of truth going forward? This choice shapes your whole workflow.
If you expect only light code tweaks, you may keep Draftbit as the primary editor and treat exports as periodic snapshots. That preserves the visual speed for most changes.
If you expect substantial custom logic, third-party native libraries, or a growing engineering team, the code becomes your source of truth. From that point, treat the export as a one-time starting scaffold rather than something to regenerate.
The key is to avoid an ambiguous middle state where both the visual project and the code drift apart. Round-tripping heavy code changes back into the visual editor is not the intended workflow, so pick a direction early and commit to it, documenting the decision for anyone who joins later.
Running in Expo Go is development only. To get an installable, standalone app, you build with EAS Build, which produces a signed iOS binary in the cloud.
Configure your app identifiers, icons, and splash screen in the Expo app configuration. These carry through to the iOS build and your store listing.
You will need a paid Apple Developer Program membership for distribution, along with the signing credentials EAS helps manage.
Remember the honest boundary: exporting code and running via Expo does not turn this into native Swift, and it does not remove Apple's requirement to build with Xcode-based tooling and submit through App Store Connect.
Not necessarily. Code export can depend on your subscription tier, so confirm on Draftbit's official pricing page before relying on it. The exported project is standard React Native (Expo) code.
For Expo Go previews, no Mac is required. The iOS Simulator does require a Mac, but you can build standalone iOS apps in the cloud with EAS Build, which avoids needing a local Mac for the build itself.
Expo Go runs standard Expo-supported components without a custom native build. A development build is needed when your app uses custom native modules that Expo Go does not include.
Light edits are fine, but once you make substantial code changes, round-tripping back into the visual editor is not the intended workflow. Decide early whether code or the Draftbit project is your source of truth.
No. It remains a React Native app running on iOS. Exporting gives you real, standard code and full control, but it is not native Swift, and App Store release still needs Apple's tooling and a Developer Program membership.