SMF·DRAFTBIT
Can a prompt replace Draftbit?
No-code apps — internal tools and application builders
Exhibit tracking slip
Verdict
Draftbit's promise is that you are not locked in: whatever you assemble visually comes out as readable React Native you can take to a normal repository. Building a tool that emits clean code rather than a runtime interpreter is the whole design problem, and it is a genuinely different job from a no-code runtime. It is reachable in a fortnight for a constrained component set. What is not reachable is the build pipeline — provisioning profiles, signing, store submission — which is where mobile projects actually stall.
Exhibit A — The prompt
Received on31.07.2026Build a visual editor for React Native screens that emits readable source code as its only output. There is no runtime, no interpreter and no proprietary format at build time.
Component set, fixed and small: Screen, ScrollView, View with flex layout, Text, Image, Button, TextInput, Switch, Picker, FlatList, Card, Tabs and a bottom navigator. Each has a declared prop schema — the editor only exposes props that exist on the component it will emit.
Canvas: a screen tree on the left, a canvas in the middle rendering at phone dimensions, and a prop panel on the right. Layout is flexbox only: direction, justify, align, gap, padding, flex. No absolute positioning, because the emitted code has to stay readable and a canvas that lets you drag anywhere produces code nobody can maintain.
Theme: a token file for colours, type scale and spacing. Components reference tokens, and the emitted code imports them from a single theme module.
Data binding: define a data source as a REST endpoint with a sample response pasted in. The editor derives the shape from the sample and offers its fields for binding to component props. A FlatList binds to an array field and its item template binds to the element shape. Emit a typed fetch hook per data source; do not emit a generic client that hides what is happening.
Code emission, which is the whole point:
- One file per screen, named after the screen, with components in the order they appear in the tree.
- Real component names and real props, formatted with Prettier — the output must look like code a person wrote.
- Styles emitted as a StyleSheet.create block at the foot of each file, with names derived from the element's role rather than generated ids.
- A complete Expo project: package.json, app config, navigation wiring, theme module, data hooks. Running the documented command must start it on a simulator.
- Re-export must be non-destructive: emit into a directory the editor owns, and leave any file the developer has added or edited outside it untouched. Document that once you edit the emitted code, the round trip is one-way.
Storage: the design as JSON in the project repository, so it diffs.
Out of scope: cloud builds, code signing, store submission, live device preview, a component marketplace, and any hosted service or account. State in the README that getting the app onto a device is the user's job and is the larger half of shipping a mobile app.Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 cloud builds, code signing and App Store or Play Store submission
- B.2 live preview on a physical device while you edit
- B.3 the integration catalogue wired in ahead of time
- B.4 collaboration on the same app design
Prior art
Exhibit C — Why people still pay: connectors, runtime reliability, and governance
Because the visual part is the fun half and the shipping part is the hard half. Certificates, provisioning and store review are where a mobile project dies, and that is the part Draftbit does for you.
Questions
Can I import a Draftbit app?
Draftbit exports React Native source on its paid plans, which you can keep and build. It does not import back into this build's design format, so the visual design is rebuilt if you want to keep editing visually. The code, at least, is genuinely portable — which was Draftbit's own pitch.
Why limit it to flexbox and a dozen components?
Because the constraint is what keeps the emitted code readable, which is the entire reason to build a code emitter instead of a runtime. Add absolute positioning and arbitrary components and the output becomes generated markup nobody wants to maintain, at which point you have built a worse no-code runtime.
What does it cost to run?
The editor is free and local. Building and shipping the app is where the money goes: an Apple developer account is 99 dollars a year and a Google Play account a one-off fee, and neither is avoidable by any route.
What is the one thing that does not survive the rebuild?
Getting to the store. Cloud builds, signing certificates, provisioning profiles and review submission are what Draftbit handles, and they are the steps that turn a working prototype into an app people can install. Nothing in a local editor helps with any of it.
Related tools
Receipt