Visual editor
Can I use npm packages and custom native modules in Draftbit?
Yes for npm packages. You add them in Build Config or ask an agent to install and configure them. Native functionality works through Expo packages and React Native packages that auto-link or ship an Expo config plugin, and native previews must be rebuilt after a native package changes. Draftbit has no workflow for writing your own Swift or Kotlin module, so that work happens outside the builder.
Reviewed September 2, 2026
Every Draftbit project has a normal package.json. The Packages tab in Build Config shows its dependencies in two sections, Standard for anything the app needs at runtime and Development for build and test tooling. You can add a row with a package name and version range, edit a version inline, or remove a package. If you would rather not pick the package yourself, ask the agent in AI Chat. It can compare options, check Expo compatibility, install the package, and add the providers, config plugins, permissions, or config files the package needs. Agents also have tools that list recommended packages for your app type, add and remove packages, and, for Expo apps, upgrade the Expo SDK and run expo-doctor afterwards.
For mobile apps the native side is where compatibility matters. Draftbit apps run on Expo, so prefer Expo-maintained packages and React Native packages known to work with Expo. A package must either auto-link or provide an Expo config plugin. If it does neither, it is not a good fit and you should look for an alternative. Packages that need hand-edited native project files or heavy custom build steps fall into that group. After you add, remove, or change a package that includes native code, build new native previews before testing on the iOS or Android simulators. The web preview updates on its own, while a native build does not.
Custom native modules are where the builder stops. The builder has no workflow for writing your own Swift or Kotlin, and the code editor gives those files no autocomplete or linting. If your app needs one, export the code on the Standard plan and do that work with local native tooling, or package the module with a config plugin so it can be added like any other dependency.
Before you commit to a package, ask the agent whether it supports the web. Some native-first packages behave differently or not at all there, and the agent can add a web fallback if you publish to the web. Install one package at a time so a broken preview is easy to trace and undo.
Useful links
Related questions
Start with your app idea
Create a free account and describe what you want to build.