This is the full developer documentation for Draftbit Docs
# Welcome
> Learn all about using Draftbit to build apps
## What is Draftbit?
[Section titled “What is Draftbit?”](#what-is-draftbit)
Draftbit is a browser-based software for building cross-platform apps that run on the web and mobile devices with the help of the latest AI models. You can design, build, iterate, and then publish your app to the web, Apple App Store, and Google Play Store with a single click!
Draftbit is purpose-built to support non-technical and less experienced developers. It is designed to be easy to use and understand while at the same time offering powerful features that take the pain out of building apps for yourself, team, or clients.
## How does it work?
[Section titled “How does it work?”](#how-does-it-work)
When you first create an app, you provide an initial description of the app you want to build. This description is then given to the AI which creates a list of tasks required to build an initial version of your app. Once the task list is created the AI will get to work building. You can watch the progress in real-time using the web preview. Once the app is ready you’ll be taken into the Builder where you can continue to build your app with the help of AI.
Start from scratch
It’s also possible to start from a blank base app instead of having the AI create the initial build. This gives you more control over how your app is designed and built from the ground up.
You can preview your app as you build in real time using the web preview in the Builder. Previewing on iOS and Android is also possible by creating a [native preview build](/features/publishing#native-previews).
If you have experience writing code you can also edit your app’s codebase directly in the built-in [Code Editor](/features/code-editor). You also get a dedicated cloud storage bucket for all your app sets like image, audio, and video files.
When you’re ready to go live, publishing your app to a custom domain as a Progressive Web App (PWA) and to the Apple and Google app stores is simple. Once you upload a few key bits of data which let us publish on your behalf, publishing your app only requires a few clicks!
[Getting Started ](/intro/building-with-draftbit/getting-started)Ready to dive in? Get started building your first app with Draftbit.
# Overview
> An introduction to features in Draftbit

Visual Editor
Visually design screens, components, and styles with AI
[Read the docs →](/features/ai-app-builder)

Code Editor
Edit your code directly using the built-in editor
[Read the docs →](/features/code-editor)

Preview
Test and preview your application as you build
[Read the docs →](/features/ai-app-builder#preview-panel)

Cloud Storage
Manage images and other media files for your project
[Read the docs →](/features/cloud-storage)

Publishing
Manage app publishing and deployments to web, iOS, and Android
[Read the docs →](/features/publishing)

Integrations
Manage third-party service integrations for your app
[Read the docs →](/features/integrations)

Build Config
Manage environment variables, packages, and build-time configuration
[Read the docs →](/features/build-config)

Logs
Open preview logs and runtime output while debugging your app
[Read the docs →](/features/preview-logs)

Agent Config
Manage agent instructions, prompts, and defaults
[Read the docs →](/features/agent-instructions)

Themes
Customize your app’s shared colors and typography
[Read the docs →](/features/themes)

History
View project activity history and rollback changes
[Read the docs →](/features/history)

Settings
Configure app identity, app configuration, and project actions
[Read the docs →](/features/project-settings)
# Agent Customization
> Manage agent instructions, prompts, and defaults
> Switch to Agent Customization view using the  icon in the [main menu](/intro/building-with-draftbit/builder-overview#main-menu).
The Agent Customization view allows you to manage default agent and models, reusable prompts, and agent instructions. This is useful for customizing the behavior of the AI Agent.

## Defaults
[Section titled “Defaults”](#defaults)
If you have a preferred agent, model, and AI gateway combination you like to work with, you can set it as the default here. These defaults are automatically selected when starting a new chat thread. You can always change them when sending a new message in the [AI Chat tab](/features/ai-app-builder#ai-chat).
| Name | Description |
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Agent | The agent that will be automatically selected for new chat threads. |
| Claude Model | The Claude model automatically selected when using the Claude agent. |
| Codex Model | The OpenAI Codex model automatically selected when using the Codex agent. |
| AI Gateway | The billing path or provider used for new threads, such as Draftbit credits, OpenRouter, OpenAI, Anthropic, or a connected subscription. |
### Bring Your Own Key or Subscription
[Section titled “Bring Your Own Key or Subscription”](#bring-your-own-key-or-subscription)
Agent Config is also where you connect your own AI provider access.
Supported options include:
* OpenRouter API keys
* OpenAI API keys
* Anthropic API keys
* OpenAI subscriptions
* Claude subscriptions
* Codex subscriptions
Threads that use your own key or subscription run through that provider instead of consuming Draftbit credits. Draftbit shows the selected provider in chat and thread history so you can tell which billing path a thread is using.
If a connected key or subscription hits its usage limit, the chat shows a provider-specific recovery message instead of a generic agent failure.


## Provider Keys (BYOK)
[Section titled “Provider Keys (BYOK)”](#provider-keys-byok)
You can connect your own AI provider API keys and have agent runs route directly to that provider instead of through Draftbit credits. This is available on **every plan**, including Free.
### Supported providers
[Section titled “Supported providers”](#supported-providers)
| Provider | Where to create a key |
| ---------- | ---------------------------------------------------------------------------------- |
| OpenAI | [platform.openai.com/api-keys](https://platform.openai.com/api-keys) |
| Anthropic | [console.anthropic.com/settings/keys](https://console.anthropic.com/settings/keys) |
| OpenRouter | [openrouter.ai/settings/keys](https://openrouter.ai/settings/keys) |
### How it works
[Section titled “How it works”](#how-it-works)
* Connect a key under **Defaults → Provider Keys**. Once connected, the corresponding models can be selected as your default or chosen ad‑hoc when sending a message.
* **Threads using your key route directly to the provider and bypass Draftbit credits entirely.** You’ll see provider labels in chat and in your thread history so it’s always clear where a request is going.
* You can still mix Draftbit‑credit threads and BYOK threads in the same project — the provider used is recorded per‑thread.
* Rate limits and model availability are governed by your provider account, not Draftbit. If a request fails because of provider limits or expired keys, the error surfaces inline in the chat.
For more on how this affects billing, see [Credits](/intro/account/credits) and [Using Credits Efficiently](/intro/best-practices/using-credits-efficiently).
## AI Provider Subscriptions
[Section titled “AI Provider Subscriptions”](#ai-provider-subscriptions)
In addition to API keys, you can connect an AI provider subscription plan so that agent threads use your plan’s included usage instead of Draftbit credits or a metered API key.

| Provider | Button | What it connects |
| ---------------- | ------------------- | ------------------------------------------------------------------------------------------ |
| OpenAI ChatGPT | Sign in with OpenAI | Starts Codex threads that use your OpenAI subscription’s included usage. |
| Anthropic Claude | Sign in with Claude | Starts Claude Code threads that use your Claude plan’s (Pro, Max, or Team) included usage. |
Click **Sign in with OpenAI** or **Sign in with Claude** and complete the provider’s authorization flow. Once connected, the status changes from **Not connected** to show the connected account, and new threads for that agent can draw from the subscription’s included usage instead of Draftbit credits.
The **Heads Up** badge next to Anthropic Claude notes that Claude.ai connectors and Remote Control aren’t available when using your Claude subscription in Draftbit, and that usage remains subject to Anthropic’s policies. See [Claude authentication](https://code.claude.com/docs/en/authentication#generate-a-long-lived-auth-token) for more.
## Organization-Wide AI Providers
[Section titled “Organization-Wide AI Providers”](#organization-wide-ai-providers)
Everything above can also be set once at the organization level instead of per app. Go to **Organization → AI Providers** to connect subscriptions or API keys for the whole organization — every project can use them immediately, with no individual setup, and the rest of your team benefits automatically.

This page has the same two sections as an individual app’s Agent Config, but scoped to the organization:
| Section | What it does |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| AI Provider Subscriptions | Connect a Claude or ChatGPT plan once for the whole organization. Every app (including new ones) can start subscription threads immediately — no per-app sign-in. |
| AI Provider API Keys | Connect OpenRouter, OpenAI, or Anthropic keys once for the whole organization. Every app can start BYOK threads that bypass Draftbit credits. |
A few things to know:
* **Only organization admins and owners can manage this page.** Other members see a message pointing them to an admin, or to set app-level keys instead from an app’s Agent Config.
* **App-level connections always override organization-level ones.** If an app has its own key or subscription connected, it uses that instead of the organization’s.
## Saved Prompts
[Section titled “Saved Prompts”](#saved-prompts)
> Switch to Saved Prompts view using the  tab.
Saved Prompts are reusable prompts that you can use when sending a message to the agent. They can be used to set the context for the agent’s response or to provide additional instructions for the agent to follow.
### Creating a New Prompt
[Section titled “Creating a New Prompt”](#creating-a-new-prompt)
Create a new prompt by clicking the  button.
| Input | Description |
| ------ | -------------------------- |
| Name | The name of the prompt. |
| Prompt | Description of the prompt. |
Fill in the details for the prompt and click the  button.
### Editing a Prompt
[Section titled “Editing a Prompt”](#editing-a-prompt)
Edit a saved prompt by clicking the  button.
| Input | Description |
| ------ | -------------------------- |
| Name | The name of the prompt. |
| Prompt | Description of the prompt. |
Fill in the details for the prompt and click the  button.
### Deleting a Prompt
[Section titled “Deleting a Prompt”](#deleting-a-prompt)
Delete a saved prompt by clicking the  button.
### Using a Saved Prompt
[Section titled “Using a Saved Prompt”](#using-a-saved-prompt)
You can use a saved prompt by clicking the  button in the [AI Chat tab](/features/ai-app-builder#ai-chat).
## Agent Instructions
[Section titled “Agent Instructions”](#agent-instructions)
You can customize the system prompt that Draftbit attaches to each agent when it starts a new chat thread. This is useful for telling the agent about your project’s tech stack, conventions, and key files.
Each agent has its own dedicated instructions file:
| Agent | File | What it controls |
| ------ | ----------- | ------------------------------------------------------- |
| Claude | `CLAUDE.md` | System prompt added to every Claude Code agent thread. |
| Codex | `AGENTS.md` | System prompt added to every OpenAI Codex agent thread. |
Open the file for the agent you want to configure, edit it inline, and save. The instructions take effect on the next thread that agent starts. The **Instructions Agent** sidebar on this page can also help you draft and refine these files conversationally.
### Best practices
[Section titled “Best practices”](#best-practices)
* Focus on providing details the agents need to know about the tech stack, conventions, and key files of your project.
* Set any conventions or rules you want the agents to follow, for example “always use the existing component library before creating new components”.
* Don’t include future plans or ideas for the project. This is just base knowledge.
* Provide only the critical details and aspects of your project. Adding too much information can overwhelm and slow down the agent’s performance, while also driving up cost of each request. Experiment to find the right balance.
# AI App Builder
> Create your app with the help of AI and natural language
> Switch to Visual Editor using the  icon in the [main menu](/intro/building-with-draftbit/builder-overview#main-menu).
AI is at the heart of Draftbit, allowing you to use natural language to instruct the AI what to build without needing to write a single line of code.
The **Visual Editor** is the full design surface where you can [chat with the AI Agent](#ai-chat), [adjust component styles](#component-tree), [preview changes in real-time](#preview-panel), [manage screens](#screens-list), and more. The Builder’s default Home view opens a focused workspace with the preview, agent, and editor panel; open Visual Editor when you need the Screens list and component tree.

| # | Name | Description |
| - | ------------------------------------- | ------------------------------------------------------------ |
| 1 | **[Screens List](#screens-list)** | A list of all the screens in your app |
| 2 | **[Component Tree](#component-tree)** | The components used on the selected screen |
| 3 | **[Preview Panel](#preview-panel)** | A canvas where you can preview your app on different devices |
| 4 | **[Utility Panel](#utility-panel)** | Access AI chat, component styling, and other functionality |
## Screens List
[Section titled “Screens List”](#screens-list)
Screens are the base element of your app and contain any number of components that make up the user interface (UI). Every app needs at least one screen. The screens in your app are listed here. You can also add more screens or folders directly. The Screens List is also where your app’s navigation structure is managed, since the way screens and folders are arranged determines the routes and flows available in your app.
Understanding Navigation
For a deeper overview of how navigation works and how screen structure maps to routes, see the [Understanding Navigation](/guides/understanding-navigation) guide.

| Icon | Action | Description |
| ----------------------------------------------------- | -------------- | ----------------------------------- |
|  | **Add Screen** | Adds a new Screen to the app |
|  | **Add Folder** | Adds a new Screen Folder to the app |
## Component Tree
[Section titled “Component Tree”](#component-tree)
Each screen is built-up out of smaller components in a hierarchy from top to bottom. Components can sometimes also be nested within/below another ‘parent’ component. The Component Tree is a visual representation of the component hierarchy on the selected screen.
From here, you can select components on the screen which will update the context of the Utility Panel on the right side of the builder - including the Style and Content tabs.

| Icon | Action | Description |
| ----------------------------------------------------------- | ----------------- | ----------------------------------------- |
|  | **Design Blocks** | Open and browse the Design Blocks gallery |
You can also open and browse the Design Blocks gallery using the  button. Design Blocks help the agent understand your design intentions. Choose a block to pass to the agent as a starting point for adding new sections to your screen. The agent will customize it to your liking in the chat and match your app’s existing theme.

## App Previews
[Section titled “App Previews”](#app-previews)
App Previews are a powerful way to preview your app as you build it. You can preview your app on different devices and screen sizes, and see how your app looks and behaves on different devices.
Draftbit offers both in-browser device previews via web and native iOS and Android simulators as well as the ability to preview your app on real iOS and Android devices using the Draftbit Preview app for iOS and Android.
Preview Canvas
There’s also a dedicated preview canvas by clicking the  icon in the [main menu](/intro/building-with-draftbit/builder-overview#main-menu)
### In-Browser Previews
[Section titled “In-Browser Previews”](#in-browser-previews)
Draftbit offers a powerful app preview mode that lets you see and interact with all the screens in your app at the same time on an infinite canvas.
Within the Preview Panel in the center of the Builder, you can add one or more preview devices so that you can see changes being made as they happen in real-time on different types of devices. Pan and zoom to get a better view, choose between web (laptop/desktop) and native (iOS/Android) devices, change the device orientation (landscape/portrait), and switch device sizes.
Native Previews
You can create native development builds of your app to preview on real iOS and Android devices running in the Preview Panel. Learn more about [native preview builds](/features/publishing#native-previews).

| Icon | Name | Description |
| --------------------------------------------------------------------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|  | **Route View** | * **Single Route View: **Preview one specific route at a time. Use the route input to navigate to different screens.
* **All Routes View: **Preview all routes simultaneously in a grid layout. Great for seeing the overall app structure. |
|  | **Enable Selection Mode** | Highlight and select components inside the preview |
|  | **Show Preview Logs** | View build output and errors while working in preview |

| Icon | Name | Description |
| --------------------------------------------------------------- | ------------------- | -------------------------------------------------------------------------------------- |
|  | **Add Device** | Adds a new preview device to the preview canvas. |
|  | **Zoom Out** | Reduces the level of zoom in the preview area |
|  | **Zoom In** | Increases the level of zoom in the preview area |
|  | **Fit All Devices** | Adjusts the zoom level so that all preview devices fit within the visible preview area |
|  | **Reset Zoom** | Resets the preview zoom level to 100% |
#### Preview Screenshots
[Section titled “Preview Screenshots”](#preview-screenshots)
You can take screenshots of your app previews by clicking the  button. This will attach a screenshot of the screen in the preview to the current chat thread.
Useful for referencing specific design changes or UI elements to change on the screen or when debugging issues.
#### Editing Text in the Preview
[Section titled “Editing Text in the Preview”](#editing-text-in-the-preview)
Double-click any text in a preview to edit it inline. Your change is staged like any other edit, so you can save or discard it from the top bar.
### On-Device Previews
[Section titled “On-Device Previews”](#on-device-previews)
Using the Draftbit Preview app for [iOS](https://apps.apple.com/us/app/draftbit-preview/id1605807667) and [Android](https://play.google.com/store/apps/details?id=com.draftbit.livepreview\&pli=1), you can preview your app on real iOS and Android devices. Simply click the  button and scan the QR code to open the app and preview on your device.

## Utility Panel
[Section titled “Utility Panel”](#utility-panel)
Within the Utility Panel on the right side of the Builder, you can access these features:
| Icon | Name | Description |
| -------------------------------------------------- | ----------------------------- | ------------------------------------------------------------------- |
|  | [**Chat Tab**](#ai-chat) | Interact with the AI Agent to build your app. |
|  | [**Styles Tab**](#styles) | Control the visual appearance and layout of the selected component. |
|  | [**Content Tab**](#content) | Update the content of the selected component. |
|  | [**Code Tab**](#code) | Edit the code of the selected component. |
|  | [**Config Tab**](#config) | Configure the selected component. |
|  | [**Activity Tab**](#activity) | View commit history and other activity for the app. |
|  | [**Updates Tab**](#updates) | View the latest product updates and announcements. |
### AI Chat
[Section titled “AI Chat”](#ai-chat)
> Switch to AI Chat tab using the  icon in the [Utility Panel](#utility-panel).
The AI Chat tab in the Utility Panel is where you can interact with the AI Agent, giving it instructions on what to build in your app.
Create a new thread using the  button. You can provide additional context to the agent in your chat messages by including a specific component selection, file reference, image attachment, pasted image, or supported file.
Prompting 101
Learn about best practices for [writing your initial prompt](/intro/best-practices/writing-your-initial-prompt) when starting a new app project and [composing task prompts](/intro/best-practices/composing-task-prompts) when working with AI in the Builder.

| Icon | Name | Description |
| --------------------------------------------------------------- | -------------------- | ------------------------------------------------------------------------------------- |
|  | **Add component** | Select a component from the canvas to add it to your message. |
|  | **Add reference** | Reference files and assets from your project in your message. |
|  | **Add attachment** | Attach an image or supported file to provide context for your message. |
|  | **Add saved prompt** | Use a saved prompt from the [Agent Customization](/features/agent-instructions) view. |
|  | **Thread history** | View and manage all your previous AI chat threads |
Attachments and queued prompts
You can drag and drop or paste images and supported files directly into the chat tab. If the agent is already running, you can queue follow-up prompts in the same thread; Draftbit runs them in order after the current agent run finishes.
#### When the agent needs your input
[Section titled “When the agent needs your input”](#when-the-agent-needs-your-input)
If the agent needs more information to keep going, it pauses the run and surfaces a **“Draftbit needs your input”** panel inline in the chat. The panel can ask one or more questions at a time. Pick an answer for each, then submit to resume the run — your selected answers are persisted with the thread, so you can refer back to them later.
##### Advanced Configuration
[Section titled “Advanced Configuration”](#advanced-configuration)
The Advanced Configuration section allows you to configure the AI Agent and model to use for the task. You can select the Agent and model from the dropdown menus.

| Name | Description |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Agent** | The AI Agent to use for the task. Anthropic Claude Code (default), OpenAI Codex, Google Gemini (upcoming) |
| **Model** | The model to use for the task. Options depend on the Agent selected. |
| **Subagent model** | For Claude Code threads, choose the model used by helper subagents. Automatic preserves Claude Code’s route-specific helper defaults; selecting a model pins that choice for the thread. |
| **Mode** | The mode to use for the task. Full or Read Only. |
Thread Agent
The Agent, Model, and Subagent model settings you select will be used for all tasks in the new Thread.
### Styles
[Section titled “Styles”](#styles)
> Switch to Styles tab using the  icon in the [Utility Panel](#utility-panel).
Use the Styles tab to control the visual appearance and layout of the selected component. Values map to [NativeWind](https://nativewind.dev/docs/getting-started) utility classes, and you can target specific responsive sizes using the Breakpoint selector. The top of the panel also shows Current Classes so you can review or add classes directly.

| Section | Description |
| ------------------- | ------------------------------------------------------------------------------------------ |
| **Current Classes** | View and manage the utility classes applied to the component. |
| **Typography** | Change the font color, size, weight, decoration, and more. |
| **Background** | Set background color and optional blend modes for overlays. |
| **Flex** | Enable flexbox and control direction, grow/shrink, gaps, alignment, and justification. |
| **Spacing** | Manage margins and padding, either overall or per-side. |
| **Border** | Adjust border width, radius, style, and color. |
| **Shadow** | Apply elevation by choosing a shadow size and color. |
| **Layout** | Control position, visibility, display, inset/offsets, overflow, aspect ratio, and z-index. |
| **Sizing** | Define height and width, including min/max constraints. |
### Content
[Section titled “Content”](#content)
> Switch to Content tab using the  icon in the [Utility Panel](#utility-panel).
Some components, like Text or Button, accept a value. If you have selected a component in the Component Tree which can accept a text value, the Content tab will become available. This is a quick way for you to update the value without needing to ask the AI Agent or manually edit the file in the [Code Editor](/features/code-editor).

### Code
[Section titled “Code”](#code)
> Switch to Code tab using the  icon in the [Utility Panel](#utility-panel).
The Code tab allows you to edit the code of the selected component directly in the browser. This is a quick way for you to make changes without needing to ask the AI Agent or manually edit the file in the [Code Editor](/features/code-editor).
Full Code Editor
For larger refactors or working across multiple files, open the dedicated Code Editor view from the main menu. See the [Code Editor](/features/code-editor) page for a full overview of how to manage and edit your app’s codebase.

### Config
[Section titled “Config”](#config)
> Switch to Config tab using the  icon in the [Utility Panel](#utility-panel).
The Config tab has additional configuration options depending on the selected screen or component.

| Name | Description |
| -------------- | ------------------------------------------------------------------------------------------------------ |
| **File Label** | Use this label to add a more descriptive name to your file. This does not affect the actual file name. |
### Activity
[Section titled “Activity”](#activity)
> Switch to Activity tab using the  icon in the [Utility Panel](#utility-panel).
The **Activity** tab will let you view and manage recent actions, events, or changes related to your app and its components. This can include AI agent actions, user-made edits, file modifications, and other important events within your project. The Activity tab also helps with accountability and collaboration by allowing team members to stay up to date with what’s happening in the project.

### Updates
[Section titled “Updates”](#updates)
> Switch to Updates tab using the  icon in the [Utility Panel](#utility-panel).
The **Updates** tab will let you view the latest product updates and announcements. This can include new features, bug fixes, and other important announcements from the Draftbit team.

## Saving Changes
[Section titled “Saving Changes”](#saving-changes)
The Save button in the top bar of the Builder will indicate when your app has unsaved changes. Click the  icon in the top bar of the Builder to open the save options where you can choose to discard or save your changes.
Here you can add a descriptive message that will help you identify this save-point at a later date. Click the  button to complete the process.

If you’d like to discard your changes and go back to your last save point, click the  button to revert your changes.
Danger
Discarding changes is irreversible, so be absolutely sure you don’t want to save your changes. You can always [roll back](#reverting-changes) to a previous save-point if you change your mind about the changes you’ve saved.
## Reverting Changes
[Section titled “Reverting Changes”](#reverting-changes)
If you decide you want to go back to a previous save-point, you can easily roll back your changes. Click the  icon in the top bar of the Builder to open the save history for your app.

Here you can choose a save-point in your history and once selected will show you which files were changed at that time. Once you locate a point to restore, click the  button.
Danger
Rolling back to a previous save-point will discard any unsaved changes you have! Make a new save point before rolling back if you think you may want to come back to where you were.
# App Configuration
> Configure your app project
Now part of Settings
App Configuration now lives inside [Settings](/features/project-settings). This page remains as a detailed reference for the app configuration fields.
> Open Settings from the [main menu](/intro/building-with-draftbit/builder-overview#main-menu), then use the app configuration tabs.
App Configuration lets you configure the app settings and preferences that are written into your Expo [`app.json`](https://docs.expo.dev/versions/latest/config/app/) file.

Tip
Want full control? Edit this file directly in [Code Editing mode](/features/code-editor).
## General
[Section titled “General”](#general)
These are the basic settings that apply to your app across all platforms. Give your app a name, set how the screen rotates, and configure other fundamental properties that define your app’s identity and behavior.
| Input | Description |
| ------------------- | ------------------------------------------------------------------------------- |
| **App Name** | The name of your app as it appears on the home screen when installed. |
| **Description** | A short description of what your app is and why it is great. |
| **Slug** | A URL-friendly identifier for your app, used in publishing and build processes. |
| **URL Scheme** | URL scheme for deep linking into your app (e.g., myapp\:// would use ‘myapp’). |
| **Orientation** | Lock your app to a specific orientation or allow rotation. |
| **Interface Style** | Force light or dark mode, or follow system setting. |
## Icon
[Section titled “Icon”](#icon)
Your app icon is what users see on their home screen. Upload a square image (we recommend 1024×1024 pixels) and it will be automatically resized for different devices and screen resolutions.
| Input | Description |
| -------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **App Icon** | Local path or remote URL to an image to use for your app’s icon. We recommend that you use a 1024×1024 png file. |
| **Use Project Icon** | Use the icon configured for this project. |
[View icon configuration on Expo Docs →](https://docs.expo.dev/versions/latest/config/app/#icon)
## Splash Screen
[Section titled “Splash Screen”](#splash-screen)
The splash screen is the first thing users see when they launch your app—it displays briefly while your app loads. Choose an image and background color that represents your brand and creates a smooth transition into your app.
| Input | Description |
| -------------------- | ------------------------------------------------------------------------------------------------- |
| **Splash Image** | Local path or remote URL to an image for the splash screen. Use a 1284×2778 png for best results. |
| **Background Color** | Background color for the splash screen. |
| **Resize Mode** | How the splash image should be resized to fit the screen. |
[View splash screen configuration on Expo Docs →](https://docs.expo.dev/versions/latest/config/app/#splash)
## Notifications
[Section titled “Notifications”](#notifications)
Configure how push notifications appear to your users. These settings control the icon, color, and behavior of notifications on both iOS and Android devices.
| Input | Description |
| ----------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Notification Icon** | Local path or URL to an image for the Android notification icon. Must be a 96×96 png with transparency. |
| **Notification Color** | Tint color for the notification icon on Android. |
| **iOS Display in Foreground** | Show notifications when the app is in the foreground on iOS. |
| **Android Mode** | How notifications are displayed on Android. |
| **Android Collapsed Title** | Title shown when multiple notifications are collapsed on Android. |
[View notifications configuration on Expo Docs →](https://docs.expo.dev/versions/latest/config/app/#notification)
## iOS
[Section titled “iOS”](#ios)
These settings are specific to iPhones and iPads. Configure your Bundle Identifier (required for publishing to the App Store), set up iPad support, and manage the permissions your app needs to access device features like the camera or location.
| Input | Description |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Bundle Identifier** | Unique identifier for your iOS app (e.g., com.company.appname). Required for App Store. [Learn more →](https://developer.apple.com/documentation/appstoreconnectapi/bundle_ids) |
| **Supports Tablet** | Whether your app supports iPad devices. |
| **Uses Apple Sign In** | Enable Apple Sign In capability for your app. [Learn more →](https://developer.apple.com/sign-in-with-apple/) |
| **Require Full Screen** | Require the app to run in full screen mode on iPad (disables Split View and Slide Over). |
| **Associated Domains** | Domains for Universal Links and other app-to-web connections. E.g., \[‘applinks:example.com’] [Learn more →](https://developer.apple.com/documentation/xcode/supporting-associated-domains) |
| **App Store URL** | URL to your app on the App Store. Used for rate prompts and sharing. |
[View iOS configuration reference on Expo Docs →](https://docs.expo.dev/versions/latest/config/app/#ios)
#### Permissions
[Section titled “Permissions”](#permissions)
iOS requires a reason for each permission your app uses. Providing a reason here enables that permission—iOS will show your message when requesting access. Leave fields empty for permissions you don’t need.
| Permission | Description |
| -------------------------- | ----------------------------------------------------------------------- |
| **Camera** | This app needs camera access to take photos and scan barcodes |
| **Microphone** | This app needs microphone access to record audio |
| **Photo Library (Read)** | This app needs access to your photos to let you select images |
| **Photo Library (Write)** | This app needs permission to save photos to your library |
| **Location (When in Use)** | This app needs your location to show nearby places |
| **Location (Always)** | This app needs background location access to track your route |
| **Contacts** | This app needs access to your contacts to help you connect with friends |
| **Calendar** | This app needs calendar access to create and manage events |
| **Reminders** | This app needs access to your reminders to sync tasks |
| **Motion & Fitness** | This app needs motion data to track your steps and activity |
| **Face ID** | This app uses Face ID for secure authentication |
| **Speech Recognition** | This app needs speech recognition to convert your voice to text |
| **Bluetooth** | This app needs Bluetooth to connect to nearby devices |
| **Apple Music** | This app needs access to Apple Music to play songs from your library |
| **User Tracking (ATT)** | This app uses tracking to provide personalized ads |
[View iOS permissions guide →](https://developer.apple.com/documentation/bundleresources/information_property_list/protected_resources)
## Android
[Section titled “Android”](#android)
These settings are specific to Android phones and tablets. Configure your Package Name (required for publishing to the Google Play Store), customize your app’s adaptive icon, and select which permissions your app needs.
| Input | Description |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Package Name** | Unique identifier for your Android app (e.g., com.company.appname). Required for Play Store. [Learn more →](https://developer.android.com/studio/build/configure-app-module#set-application-id) |
| **Adaptive Icon Foreground** | Foreground image for Android adaptive icons. Should be 1024×1024 png with transparency. [Learn more →](https://developer.android.com/develop/ui/views/launch/icon_design_adaptive) |
| **Adaptive Icon Background** | Background color for Android adaptive icons. |
[View Android configuration reference on Expo Docs →](https://docs.expo.dev/versions/latest/config/app/#android)
#### Permissions
[Section titled “Permissions”](#permissions-1)
Android permissions to include in your app. These are added to AndroidManifest.xml.
Available permissions:
* ACCESS\_BACKGROUND\_LOCATION
* ACCESS\_COARSE\_LOCATION
* ACCESS\_FINE\_LOCATION
* BLUETOOTH\_CONNECT
* BLUETOOTH\_SCAN
* CALL\_PHONE
* CAMERA
* FOREGROUND\_SERVICE
* POST\_NOTIFICATIONS
* READ\_CALENDAR
* READ\_CONTACTS
* READ\_EXTERNAL\_STORAGE
* READ\_MEDIA\_AUDIO
* READ\_MEDIA\_IMAGES
* READ\_MEDIA\_VIDEO
* READ\_PHONE\_STATE
* RECEIVE\_BOOT\_COMPLETED
* RECEIVE\_SMS
* RECORD\_AUDIO
* SEND\_SMS
* USE\_BIOMETRIC
* VIBRATE
* WRITE\_CALENDAR
* WRITE\_CONTACTS
* WRITE\_EXTERNAL\_STORAGE
[View Android permissions reference →](https://developer.android.com/reference/android/Manifest.permission)
#### Blocked Permissions
[Section titled “Blocked Permissions”](#blocked-permissions)
Android permissions to explicitly remove. Use this to block permissions added by libraries.
## Web
[Section titled “Web”](#web)
When you publish your app to the web, it can work like a Progressive Web App (PWA) that users can install on their devices. These settings control how your web app appears in browsers and when installed on a user’s home screen.
| Input | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Favicon** | Local path or URL to an image for the web favicon. Recommended: 48×48 png. [Learn more →](https://developer.mozilla.org/en-US/docs/Glossary/Favicon) |
| **Theme Color** | Theme color for the web app. Used in the browser toolbar and PWA splash screen. [Learn more →](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta/name/theme-color) |
| **Name** | Full name of the web app, shown in browser tab and PWA install prompt. [Learn more →](https://developer.mozilla.org/en-US/docs/Web/Manifest/name) |
| **Short Name** | Short name for PWA (max \~12 chars). Shown on home screen when installed as PWA. [Learn more →](https://developer.mozilla.org/en-US/docs/Web/Manifest/short_name) |
| **Language** | Language code for the web app (e.g., ‘en’, ‘en-US’, ‘ja’). [Learn more →](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang) |
| **Background Color** | Background color for PWA splash screen and fallback during app load. [Learn more →](https://developer.mozilla.org/en-US/docs/Web/Manifest/background_color) |
| **Description** | Description for PWA manifest. Shown in browser install prompts. [Learn more →](https://developer.mozilla.org/en-US/docs/Web/Manifest/description) |
| **Orientation** | Default orientation for the web app when installed as a PWA. [Learn more →](https://developer.mozilla.org/en-US/docs/Web/Manifest/orientation) |
| **Start URL** | URL that loads when PWA is launched from home screen. Defaults to ’/’. [Learn more →](https://developer.mozilla.org/en-US/docs/Web/Manifest/start_url) |
Note
Not all properties are compatible with all browsers. Refer to the documentation link below for details on browser compatibility for each property.
[View Web configuration reference on Expo Docs →](https://docs.expo.dev/versions/latest/config/app/#web)
# Build Config
> Manage environment variables, packages, and build-time project configuration
> Open Build Config from the Builder navigation. Older docs, screenshots, or app versions may still refer to this area as Environments.
Build Config is where you manage the settings that affect how your app is built and how the AI agent works with your project dependencies. It brings Packages, Environment Variables, and legacy Variables for imported apps into one place.

## Tabs
[Section titled “Tabs”](#tabs)
Build Config includes these tabs:
| Tab | Purpose |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Packages** | Edit `dependencies` and `devDependencies` from your app’s `package.json`. |
| **Environment Variables** | Add and manage variables for development, staging, and production. |
| **Variables** | Edit legacy global variables for apps imported from Draftbit Classic. This tab only appears for imported apps that use those variables. |
## Packages
[Section titled “Packages”](#packages)
The Packages tab lets you edit your app’s npm dependencies without opening `package.json` manually.
It has two sections:
| Section | Description |
| --------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **Standard** | Third-party libraries your app needs to run. These are installed when your app is built and are available to your code. |
| **Development** | Libraries used during development that are not shipped with production versions of your app. |
For each package, you can edit the package name or version inline, remove the package, or add a new row with a package name and version.
Tip
When you add or remove packages that affect native code, create new native preview builds before testing on iOS or Android simulators.
## Environment Variables
[Section titled “Environment Variables”](#environment-variables)
Environment variables are key-value pairs that store configuration outside of your source code. Use them for API URLs, public configuration, feature flags, app identifiers, and sensitive values that should not be committed to your repository.

Click the  button to add a new variable.
| Field | Description |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | The variable name used in code, such as `EXPO_PUBLIC_API_BASE_URL`. Plain text variables used by Expo apps must use the `EXPO_PUBLIC_` prefix. |
| **Value** | The value Draftbit injects for the selected environments. |
| **Visibility** | Controls whether the value is plain text or sensitive. Use sensitive values for secrets, API keys, and tokens that should not be included in compiled app code. |
| **Environments** | Select where the variable is available, such as development, staging, or production. |
Environment variables are commonly used to:
* store public API base URLs that differ between development, staging, and production
* keep service configuration out of source files
* provide feature flags or build-time settings
* configure backend clients such as Supabase, REST APIs, or GraphQL APIs
* provide private values to build configuration files without exposing them in app code
Do not expose secrets
Plain text environment variables can be visible in compiled app code. Store private API keys, service tokens, and passwords as sensitive values.
### Visibility
[Section titled “Visibility”](#visibility)
Environment variables support two visibility levels:
| Visibility | Description |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Plain text** | Available to app code and visible in compiled code. Use this only for public configuration values, such as public API URLs or non-secret feature flags. In Expo apps, plain text variables used at runtime must use the `EXPO_PUBLIC_` prefix. |
| **Sensitive** | Hidden from app runtime code and compiled app bundles. Use this for API keys, service tokens, passwords, and other private values that should only be available to build or configuration files. |
### Using variables in code
[Section titled “Using variables in code”](#using-variables-in-code)
Reference environment variables in code with `process.env.VARIABLE_NAME`.
For example:
```javascript
const apiBaseUrl = process.env.EXPO_PUBLIC_API_BASE_URL;
fetch(`${apiBaseUrl}/users`);
```
Variable names are case-sensitive. If you expect a value to be available in runtime app code, make sure the variable is plain text and uses the `EXPO_PUBLIC_` prefix required by Expo.
Sensitive variables are best for build-time configuration and should not be used for values your app needs to read at runtime.
### Using variables with the AI agent
[Section titled “Using variables with the AI agent”](#using-variables-with-the-ai-agent)
The AI agent can use Build Config values while it works in the sandbox. Mention the exact variable name when you want the agent to use an existing value instead of hardcoding it.
For example:
* “Use `EXPO_PUBLIC_API_BASE_URL` for all API requests.”
* “Initialize Supabase using `EXPO_PUBLIC_SUPABASE_URL` and `EXPO_PUBLIC_SUPABASE_KEY`.”
* “Use the staging value for this integration while testing.”
## Legacy Variables
[Section titled “Legacy Variables”](#legacy-variables)
Apps imported from Draftbit Classic may include legacy global variables. Build Config gives those apps a **Variables** tab to review and edit the imported runtime values across environments without hand-editing the generated files.
## AI Agent Access
[Section titled “AI Agent Access”](#ai-agent-access)
The AI agent can use your app’s environment variables while running commands in the sandbox. This helps it run CLIs and tooling that depend on project-specific keys or service configuration.
When you ask the agent to integrate a backend or package, mention which Build Config values it should use so it does not hardcode credentials into your app files.
# Cloud Storage
> Dedicated and distributed cloud storage for your media files
> Switch to Assets view using the  icon in the [main menu](/intro/building-with-draftbit/builder-overview#main-menu).
Every app project in Draftbit gets its own place in the cloud to store its media assets like image, video, and audio files. These files are served by high-availability and high-performance cloud storage servers.
Once you’ve upload assets into your assets bucket, you can then reference those media files in your chat with the [AI Agent](/features/ai-app-builder#ai-chat) or when making [changes to the code](/features/code-editor) directly yourself.

| Icon | Name | Description |
| ----------------------------------------------------------------------- | ------------------ | -------------------------------------------------------------- |
|  | **Search assets** | Search your app’s media files. |
|  | **Reorder assets** | Reorder the assets view by `Name`, `Date`, `Size`, and `Type`. |
|  | **New folder** | Create a new folder to help organize your app’s media files. |
|  | **List/Grid view** | Switch the layout of the assets view between list and grid. |
## Upload Files
[Section titled “Upload Files”](#upload-files)
You can drag-and-drop files or folders into the ‘dropzone’ or click one of the buttons to upload **Files** or **Folders**. Most media file types are supported.

| Icon | Name | Description |
| --------------------------------------------------------------------- | ------------------ | -------------------------------------------------------------- |
|  | **Upload files** | Select individual media files to upload to your assets bucket. |
|  | **Upload folders** | Select folders of media files to upload to your assets bucket. |
### Supported file types
[Section titled “Supported file types”](#supported-file-types)
Below are some of the common supported file types that you can upload to your app’s cloud storage bucket.
| Type | Extensions |
| ------------ | ----------------------------------------------- |
| **Image** | `.png`, `.jpg`, `.svg`, `.webp`, `.gif`, `.bmp` |
| **Video** | `.mp4`, `.mov`, `.mpeg` |
| **Audio** | `.mp3`, `.aac`, `.ogg`, `.wav` |
| **Document** | `.txt`, `.csv`, `.json`, `.pdf` |
## Storage Details
[Section titled “Storage Details”](#storage-details)
This section gives you insight into the number of files you’ve uploaded to your app’s cloud storage and the amount of space you have left. You can also copy the URL associated with your assets bucket.
The amount of storage space in you assets bucket and the size of the files you’re allowed to upload will depend on your subscription plan. You can upload almost any type of media file that you need within the size and storage limits of your plan.

| Icon | Name | Description |
| --------------------------------------------------------------------- | ------------------- | ---------------------------------------------------------- |
|  | **Copy Bucket URL** | Copy the URL for the app’s asset bucket to your clipboard. |
# Code Editor
> Access and edit your app files in the browser
> Switch to Code view using the  icon in the [main menu](/intro/building-with-draftbit/builder-overview#main-menu).
In addition to Draftbit’s no-code and AI-powered development features, a full in-browser code editor is available for people with more technical experience. Depending on your plan, you can access [your app’s codebase](#file-tree), add or edit files, and open the sandbox in a local editor.
Plan availability
Manual code editing is available on paid plans. On the Free plan you can browse files and view code, but saving edits requires upgrading.

| # | Name | Description |
| - | --------------------------- | ---------------------------------------------------------- |
| 1 | **[File Tree](#file-tree)** | A list of all the files and folders in your app’s codebase |
| 2 | **[Editor](#editor)** | A full in-browser code editor to edit your app files |
## Files
[Section titled “Files”](#files)
You can browse the files and folders in your app project’s codebase from the File Tree. This includes advanced project files such as hidden folders when they are available in your app. From the File Tree you can explore files, add new files, update or delete existing files, and add files to AI Chat context so the agent can help with a specific file.

| Icon | Action | Description |
| ----------------------------------------------------- | -------------- | --------------------------------- |
|  | **Add File** | Adds a new file to the codebase |
|  | **Add Folder** | Adds a new folder to the codebase |
## Editor
[Section titled “Editor”](#editor)
You can open any of your project’s files in the provided code editor to make manual changes to the codebase yourself. The editor features TypeScript-aware autocomplete and hover info, ESLint-backed inline diagnostics, formatting, and search. This is very handy for more technical users who have experience with JavaScript and React Native, allowing you to make changes directly to the code when needed.

### Syntax validation on save
[Section titled “Syntax validation on save”](#syntax-validation-on-save)
The editor checks each file for syntax errors before saving. If a file contains a syntax error, the save is blocked and the editor highlights the offending location. Fix the error and try saving again. The agent and preview won’t see partially broken code.
## Saving Changes
[Section titled “Saving Changes”](#saving-changes)
Changes to files (and folders) that you make yourself are treated the same as when the [AI Agent makes changes](/features/ai-app-builder). You can discard or commit your changes in the [Save menu](/features/ai-app-builder#saving-changes) by clicking on the  icon in the top bar of the Builder.

You can also discard any changes the specific file using the  button at the top of the code editor.
# Git History
> View Git history and rollback changes
> Switch to Git History view using the  icon in the [main menu](/intro/building-with-draftbit/builder-overview#main-menu).
The Git History view allows you to view the history of your project. This is useful for debugging and troubleshooting your app.

## Commits
[Section titled “Commits”](#commits)
The Git History view shows a list of all the commits made to your project. Each commit is represented by a card with the commit message, author, date, and a link to the commit details.
| Input | Description |
| -------------- | ---------------------------------------------------------- |
| Commit Message | The message of the commit. |
| Date | The date of the commit. |
| Files Changed | A count of the files that have been changed in the commit. |
| Lines Added | A count of the lines that have been added in the commit. |
| Lines Removed | A count of the lines that have been removed in the commit. |
## Changed Files
[Section titled “Changed Files”](#changed-files)
The Git History view shows a list of all the files that have been changed in your project. Each file is represented by a card with the file name and path. Click to view the diff of the changes made in the commit.
| Input | Description |
| ----------- | ----------------------- |
| File Name | The name of the file. |
| Path | The path of the file. |
| Commit Hash | The hash of the commit. |
## Diff
[Section titled “Diff”](#diff)
The Git History view shows a diff of the changes made to a file in a commit. The diff is represented by a list of lines that have been changed, added, or deleted. Each line is represented by a card with the line number, the line content, and a link to the file details.
| Input | Description |
| ------------ | ----------------------------- |
| Path | The path of the file. |
| File Content | The diff content of the file. |
## Rolling back
[Section titled “Rolling back”](#rolling-back)
To return your project to the state of an earlier commit, select that commit in the list and use the **Roll back to this point** action. Rolling back creates a new commit that restores the selected state — your full history is preserved, so you can always roll forward again or pick a different point.
Caution
Rolling back discards any unsaved changes in the Builder. Save (or discard) your current work before rolling back.
For an interactive overview of the same flow inside the Design view, see [Reverting Changes](/features/ai-app-builder#reverting-changes).
# Integrations
> Manage third-party service integrations for your app
> Switch to Integrations view using the  icon in the [main menu](/intro/building-with-draftbit/builder-overview#main-menu).
Integrations allow you to connect your app and AI agent to third-party services like Supabase, REST APIs, GraphQL APIs, Canva, Xano, Linear, RevenueCat, and more.

The Integrations page is organized into tabs:
| Tab | Purpose |
| ------------- | ------------------------------------------------------------------------------------------------- |
| **MCPs** | Connect agent tools such as Supabase MCP, Xano, Linear, Canva, Sentry, and custom MCP servers. |
| **REST APIs** | Add REST API sources from the catalog, import OpenAPI specs, or manage custom REST services. |
| **GraphQL** | Import a GraphQL schema, add catalog GraphQL services, and manage generated or custom operations. |
| **Supabase** | Create and manage a Draftbit-provisioned Supabase backend for the app. |
## Supabase Backend
[Section titled “Supabase Backend”](#supabase-backend)
Supabase is available as an open-beta backend for Draftbit apps. You can connect Supabase from the **Supabase** tab in Integrations or during app creation, then let the AI agent help create and manage database tables, authentication, storage, and related app code.
When a Supabase backend is connected, Draftbit can work with separate preview and production branches. The preview branch is the default branch the AI agent uses while building so schema changes and test data are available immediately in the Builder.
If Supabase is not connected, editors see **Create Supabase Instance**. While setup is running, Draftbit shows **Setting up your Supabase instance…**. Once active, the tab shows the project ref, dashboard, and project actions such as deleting the Draftbit-provisioned project.

## REST APIs
[Section titled “REST APIs”](#rest-apis)
The REST APIs area lets app editors add and manage REST API services. Use it to connect preconfigured services from the catalog, import an OpenAPI spec, or configure your own API source.
The REST catalog includes search so you can quickly filter available services by name or tag. Editors can add, edit, test, and import sources; viewers can browse available configuration without changing it.
Apps imported from Draftbit Classic may include legacy REST API services. You can delete those legacy services from the REST APIs tab or the service detail page after confirming the deletion.

## GraphQL APIs
[Section titled “GraphQL APIs”](#graphql-apis)
The GraphQL area lets you connect GraphQL endpoints and import operations for the agent and app to use.
You can:
* use **Import GraphQL** to introspect a schema and create one operation per query or mutation
* add services from the GraphQL marketplace
* test GraphQL endpoints before saving changes
* add custom operations alongside introspected operations
* reimport schemas without losing custom operations
Draftbit includes a catalog of common GraphQL services, including Supabase GraphQL, Hasura, AWS AppSync, Contentful, Hygraph, DatoCMS, Storyblok, Sanity, Strapi, Shopify Storefront, Saleor, and The Graph.

The Integrations page has three tabs:
* **MCP** – connect the AI Agent to a third-party service via the Model Context Protocol so it can manage that service for you.
* **REST APIs** – connect any REST endpoint and have the agent call it as a tool.
* **GraphQL APIs** – connect any GraphQL endpoint and expose its schema to the agent as tools.
> Some services (like Supabase, Xano, and Directus) appear in multiple tabs. Use the **MCP** connector when you want the agent to manage the full lifecycle of the service (create tables, deploy functions, etc.). Use the **REST** or **GraphQL** connector when you just want to expose specific endpoints from a backend you already own to the agent and your app.
## REST API Connectors
[Section titled “REST API Connectors”](#rest-api-connectors)
REST API Connectors let you connect any REST service to your app and expose its endpoints to the AI Agent as tools. Once a service is connected, you can ask the agent to call those endpoints in natural language — for example, “fetch the user’s orders and render them in a list” — without writing the request code yourself.
The REST APIs tab uses a two-column layout: the list of services and endpoints on the left, with configuration and a live request tester on the right. Each REST service also has its own **Integrations Agent** sidebar you can use to add or refine endpoints conversationally.
### One-click services
[Section titled “One-click services”](#one-click-services)
Draftbit ships preconfigured connectors for popular REST services. Pick one of these and you only need to drop in your credentials:
* Webflow
* Bubble
* WordPress
* Shopify
* Xano
* Supabase
* Directus
* Sanity
* Zapier
### Custom REST API
[Section titled “Custom REST API”](#custom-rest-api)
If your service isn’t in the one-click list, choose **Custom REST API**. You’ll provide:
| Field | Description |
| -------------- | ---------------------------------------------------------------------- |
| Base URL | The root URL for the API (e.g. `https://api.example.com`). |
| Authentication | API key, bearer token, or custom header(s) used to authorize requests. |
| Endpoints | The individual paths and methods you want to expose to the agent. |
You can add endpoints by hand, or describe what you need in the Integrations Agent sidebar and let it scaffold them for you.
### How endpoints become agent tools
[Section titled “How endpoints become agent tools”](#how-endpoints-become-agent-tools)
Every connected endpoint is automatically exposed to your agents as a tool. The agent can decide when to call it based on your prompts and the endpoint’s name and description. Use clear, action-oriented endpoint names (“Get current user”, “Create order”) and short descriptions to get the best results.
## GraphQL API Connectors
[Section titled “GraphQL API Connectors”](#graphql-api-connectors)
GraphQL API Connectors work like REST connectors, but for GraphQL endpoints. You connect a GraphQL service once, and Draftbit reads its schema so the AI Agent can issue queries and mutations as tools.
### Connecting a GraphQL service
[Section titled “Connecting a GraphQL service”](#connecting-a-graphql-service)
| Field | Description |
| -------------- | ---------------------------------------------------------------------- |
| Endpoint URL | The GraphQL endpoint, typically ending in `/graphql`. |
| Authentication | API key, bearer token, or custom header(s) used to authorize requests. |
| Operations | The queries and mutations you want to expose to the agent. |
### How operations become agent tools
[Section titled “How operations become agent tools”](#how-operations-become-agent-tools)
Once connected, each query and mutation you select is exposed to the agent as a callable tool. The agent uses the schema to validate arguments and return types, so it can compose multi-step calls (e.g. fetch related records before mutating) without you wiring those steps together.
Like REST, each GraphQL service has its own Integrations Agent sidebar for conversational tool authoring.
## MCP Integrations
[Section titled “MCP Integrations”](#mcp-integrations)
MCP Integrations let you connect the AI Agent to third-party services using the Model Context Protocol. Unlike REST and GraphQL connectors — which expose individual endpoints — an MCP connector lets the agent **manage** the third-party service itself (create tables, deploy functions, configure subscriptions, and so on).
For most services, you will simply be prompted to sign in to the service and grant access to Draftbit to allow the AI Agent to access these services. For some services, you may need to provide additional credentials or API keys.
### Supabase
[Section titled “Supabase”](#supabase)
[Supabase](https://supabase.com) is a open-source backend-as-a-service platform that provides authentication, database, storage, and real-time capabilities for your app.
#### Authenticating
[Section titled “Authenticating”](#authenticating)
The Supabase MCP connector is authenticated using your Supabase account. When you click the **Add & Verify** button, you will be redirected to the Supabase website to sign in and grant access to Draftbit.
Once you have signed in and granted access, you will be redirected back to Draftbit and the Supabase MCP connector will be added to your app.
**The Supabase integration allows the AI Agent to:**
* Create and manage tables in your Supabase database
* Insert, update, and delete data in your Supabase database
* Query your Supabase database
* Store and access files in your Supabase Storage
* Subscribe to real-time updates from your Supabase database
* Set up user authentication and authorization
* Create edge functions to handle business logic
Read more about the Supabase MCP in their [docs](https://supabase.com/docs/guides/getting-started/mcp)
### Xano
[Section titled “Xano”](#xano)
[Xano](https://xano.com) is a no-code/low-code backend-as-a-service platform that lets you model data, build APIs, and handle business logic without managing servers.
#### Authenticating
[Section titled “Authenticating”](#authenticating-1)
The Xano MCP connector requires:
* **Server URL**: The **Streaming Connection** URL from your Xano MCP server
* **Auth Key**: Your Xano access token for that MCP server
> **Important:** When copying your connection URL from Xano, make sure to use the **Streaming Connection** URL — not the “Instance API” URL. These are two different options in Xano’s interface and only the Streaming Connection URL is supported.
Xano’s [Connecting Clients](https://docs.xano.com/ai-tools/mcp-builder/connecting-clients) guide refers to these values as the server **URL** and **Token**.
#### Troubleshooting
[Section titled “Troubleshooting”](#troubleshooting)
**Proxy errors on connection** If you see a proxy error when connecting, check that **Realtime resources** are enabled on your Xano instance. This setting is disabled by default on some Xano plans and must be turned on for the MCP connection to work. You can enable it in your Xano instance settings.
**The Xano integration allows the AI Agent to:**
* Create and manage data models in your Xano database
* Build and deploy APIs in your Xano workspace
* Query your Xano database
* Store and access files in your Xano Storage
* Subscribe to real-time updates from your Xano database
* Set up user authentication and authorization
* Create edge functions to handle business logic
Read more about the Xano MCP in their [overview](https://docs.xano.com/ai-tools/xano-mcp-server) and [client connection docs](https://docs.xano.com/ai-tools/mcp-builder/connecting-clients).
### Directus
[Section titled “Directus”](#directus)
[Directus](https://directus.io) is a open-source backend-as-a-service platform that provides authentication, database, storage, and real-time capabilities for your app.
#### Authenticating
[Section titled “Authenticating”](#authenticating-2)
The Directus MCP connector requires:
* **Server URL**: Your Directus instance URL
* **Auth Key**: Your Directus access token
Directus’ [MCP docs](https://directus.io/docs/guides/ai/mcp) describe this setup as connecting your AI tool to the Directus MCP server using your instance URL and an access token.
**The Directus integration allows the AI Agent to:**
* Create and manage tables in your Directus database
* Insert, update, and delete data in your Directus database
* Query your Directus database
* Store and access files in your Directus Storage
* Subscribe to real-time updates from your Directus database
* Set up user authentication and authorization
* Create workflows to handle business logic
Read more about the Directus MCP in their [docs](https://directus.io/docs/guides/ai/mcp).
### Linear
[Section titled “Linear”](#linear)
[Linear](https://linear.app) is a project management platform that lets you track your work and collaborate with your team.
#### Authenticating
[Section titled “Authenticating”](#authenticating-3)
The Linear MCP connector is authenticated using your Linear account. When you click the **Add & Verify** button, you will be redirected to the Linear website to sign in and grant access to Draftbit.
Once you have signed in and granted access, you will be redirected back to Draftbit and the Linear MCP connector will be added to your app.
**The Linear integration allows the AI Agent to:**
* Create and manage projects and issues
* Work on specific issues in your Linear workspace
Read more about the Linear MCP in their [docs](https://developers.linear.app/docs).
### RevenueCat
[Section titled “RevenueCat”](#revenuecat)
[RevenueCat](https://revenuecat.com) is a subscription management platform that lets you manage your app’s subscriptions and revenue.
**The RevenueCat integration allows the AI Agent to:**
* Integrate subscription billing and in-app purchases into your app
* Create and manage subscriptions and products
* Manage subscription status and renewals
Read more about the RevenueCat MCP in their [docs](https://www.revenuecat.com/docs/tools/mcp).
### Stripe
[Section titled “Stripe”](#stripe)
[Stripe](https://stripe.com) is a payment processing platform that lets you accept payments from your customers.
**The Stripe integration allows the AI Agent to:**
* Integrate payment processing into your app
* Create and manage products and prices
Read more about the Stripe MCP in their [docs](https://github.com/stripe/ai).
### Sentry
[Section titled “Sentry”](#sentry)
[Sentry](https://sentry.io) is a error tracking platform that lets you track and fix errors in your app.
#### Authenticating
[Section titled “Authenticating”](#authenticating-4)
The Sentry MCP connector is authenticated using your Sentry account. When you click the **Add & Verify** button, you will be redirected to the Sentry website to sign in and grant access to Draftbit.
Once you have signed in and granted access, you will be redirected back to Draftbit and the Sentry MCP connector will be added to your app.
**The Sentry integration allows the AI Agent to:**
* Track errors in your app
* Fix errors in your app
Read more about the Sentry MCP in their [docs](https://docs.sentry.io/product/sentry-mcp/).
### Cloudflare
[Section titled “Cloudflare”](#cloudflare)
[Cloudflare](https://cloudflare.com) provides DNS, edge compute (Workers), object/key‑value storage (R2, KV), serverless databases (D1), and other infrastructure services.
#### Authenticating
[Section titled “Authenticating”](#authenticating-5)
The Cloudflare MCP connector is authenticated using your Cloudflare account. When you click the **Add & Verify** button, you will be redirected to the Cloudflare website to sign in and grant access to Draftbit.
**The Cloudflare integration allows the AI Agent to:**
* Manage DNS records and zones for your domains
* Create and deploy Workers
* Read and write data in KV, R2, and D1
* Configure caching, security, and routing rules
Read more about Cloudflare’s MCP servers in their [docs](https://developers.cloudflare.com/agents/model-context-protocol/).
### HighLevel
[Section titled “HighLevel”](#highlevel)
[HighLevel](https://www.gohighlevel.com) (also known as GoHighLevel) is a CRM and marketing automation platform that lets you manage contacts, pipelines, campaigns, and workflows.
#### Authenticating
[Section titled “Authenticating”](#authenticating-6)
The HighLevel MCP connector is authenticated using your HighLevel account. When you click the **Add & Verify** button, you will be redirected to HighLevel to sign in and grant access to Draftbit.
**The HighLevel integration allows the AI Agent to:**
* Read and update contacts and opportunities
* Trigger and manage automation workflows
* Create and update calendar events and appointments
* Send messages through configured channels
Read more about the HighLevel MCP in their [docs](https://highlevel.stoplight.io/).
### Custom MCP
[Section titled “Custom MCP”](#custom-mcp)
There are thousands of MCP servers out there for all kinds of services and purposes. Using the Custom MCP connector, you can connect the agent to almost any of them.
| Name | Description |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Server URL** | The URL of the MCP server you want to connect |
| **Authentication Type** | Choose the authentication type for the MCP server:- **oAuth** - Allows you to sign in to a third-party service using your existing account
- **Header** - Allows you to use a third-party service with an API key or token
- **Defer to Agent** - The AI Agent will determine the best authentication type for the MCP server |
| **Custom Headers** | Set the custom headers for the MCP server:- **Key** - The name of the header (e.g. `Authorization`)
- **Value** - The value of the header (e.g. `Bearer [your token]`) |
| **Use Cache** | Choose whether to enable caching for the MCP server:- **On** - The AI Agent will use the cache for the MCP server
- **Off** - The AI Agent will not use the cache for the MCP server |
### Canva
[Section titled “Canva”](#canva)
Use the Canva integration to import a Canva design into Draftbit. After connecting Canva, choose a design from the searchable thumbnail picker. Draftbit starts a new AI thread that converts the selected design into React Native screens.
### Firebase (Coming Soon)
[Section titled “Firebase (Coming Soon)”](#firebase-coming-soon)
[Firebase](https://firebase.google.com) is a backend-as-a-service platform that provides authentication, database, storage, and real-time capabilities for your app.
**The Firebase integration allows the AI Agent to:**
* Integrate authentication into your app
* Integrate database into your app
* Integrate storage into your app
* Integrate real-time capabilities into your app
* and more!
### Figma
[Section titled “Figma”](#figma)
[Figma](https://figma.com) is a design tool that lets you create and collaborate on designs.
**The Figma integration allows the AI Agent to:**
* Create and manage designs in your Figma project
* Create and manage components in your Figma project
* Create and manage styles in your Figma project
* and more!
# Logs
> View preview logs and runtime output for your app
> Open Logs using the  control in the Builder navigation.
Logs let you inspect runtime output for your app preview while you work in the Builder. They are useful for debugging and troubleshooting app behavior, preview startup issues, and runtime errors.
Logs open as an inline panel, so you can inspect output without leaving the Builder surface you are using. Runtime errors from the web preview can also appear as Builder toasts and update the preview status.

Use the **Restart preview** control in the Builder navigation when you need to reload the running preview after a dependency, configuration, or runtime change.

| Icon | Action | Description |
| -------------------------------------------------------------------- | ----------------------- | ------------------------------------------- |
|  | **Toggle Info Logs** | Toggle the visibility of the info logs |
|  | **Toggle Warning Logs** | Toggle the visibility of the warning logs |
|  | **Toggle Error Logs** | Toggle the visibility of the error logs |
|  | **Search Logs** | Search the logs |
|  | **Clear Logs** | Clear all the logs |
|  | **Pause Logs** | Pause the logs |
|  | **Toggle Timestamps** | Toggle the visibility of the log timestamps |
|  | **Download Logs** | Download the logs |
# Settings
> Configure app identity, app configuration, notifications, and project actions
> Switch to Settings using the  icon in the [main menu](/intro/building-with-draftbit/builder-overview#main-menu).
Settings collects project-level controls and app configuration in one place. Use it to update your Draftbit project details, configure app identity for builds and publishing, manage notifications, and move, duplicate, or delete the project.
Published app metadata
Settings on this page only affect how the project shows up inside Draftbit. The name, description, and icon used by your **published** app are configured in [App Config](/features/app-configuration).

## Basic Settings
[Section titled “Basic Settings”](#basic-settings)
| Setting | Description |
| --------------- | ---------------------------------------------------------------------------- |
| **Icon** | Upload an icon image for the project. Use a square PNG, ideally 1024x1024px. |
| **Name** | Set the project name shown inside Draftbit. |
| **Description** | Set an optional internal description for the project. |
| Icon | Name | Description |
| ----------------------------------------------------------- | ------------------- | ------------------------------------- |
|  | **Upload app icon** | Upload an icon image for your project |
## App Configuration
[Section titled “App Configuration”](#app-configuration)
Use the app configuration tabs in Settings to manage the values that ship with your built app, including app name, slug, URL scheme, orientation, app icon, splash screen, iOS bundle identifier, Android package name, permissions, and web favicon.
These values are used by preview builds, one-click publishing, and exported source code.
## Notifications
[Section titled “Notifications”](#notifications)
In this section you can manage your notification preferences for the current app project.
| Setting | Description |
| ---------------------- | ------------------------------------------------------------------------------------------------ |
| **Agent Done (Sound)** | Enable or disable playing a sound when the AI Agent completes a task for the current app project |
## Move App
[Section titled “Move App”](#move-app)
In this section you can move the app to a different workspace you have access to.
Click the  button to get started.
## Duplicate App
[Section titled “Duplicate App”](#duplicate-app)
In this section you can create a copy of the app with all its settings and content.
Click the  button to get started.
## Delete App
[Section titled “Delete App”](#delete-app)
In this section you can permanently delete your app project. **Once you delete an app, there is no going back**. Please be certain.
Click the  button to initiate the process.
# Publishing Overview
> Learn about the different ways to publish your app
> Switch to Publish view using the  icon in the [main menu](/intro/building-with-draftbit/builder-overview#main-menu).

## Publish Entry Point
[Section titled “Publish Entry Point”](#publish-entry-point)
The fastest way to publish is the **Publish** popover in the top bar of the Builder. It exposes four destinations side‑by‑side:
* **Progressive Web App** — one-click web deployment
* **Apple App Store** — native iOS publishing
* **Google Play Store** — native Android publishing
* **Share** — generate a public [share page](#share-page)
If a native destination hasn’t been configured yet, choosing it routes you to the setup flow on the **Publishing** page first. Once configured, the popover lets you ship a build straight from the top bar.
### Production vs. staging
[Section titled “Production vs. staging”](#production-vs-staging)
Native destinations support both **Production** and **Staging** publishes. Staging publishes work the same as production but ship to TestFlight (iOS) or the Internal Testing track (Android). When you choose Staging, Draftbit shows a brief warning before continuing so you don’t accidentally ship to your testers without intending to.
## Native Previews
[Section titled “Native Previews”](#native-previews)
You can create native development builds of your app to preview on real iOS and Android simulators running in the [Preview Panel](/features/ai-app-builder#preview-panel).
From the **Publishing** page or the simulator-builds dropdown in the [top bar](/intro/building-with-draftbit/builder-overview), choose **Build iOS Simulators** or **Build Android Simulators**. Each platform action updates both the saved and unsaved versions of your app without rebuilding the other platform.
On the **Simulator** page, two build cards appear in the upper-right for the selected platform. The **Saved** and **Unsaved** cards show when their last successful simulator was built. Use a card’s rebuild icon when you only need to update that version; while it builds, the card displays its live status instead.
The build process may take a few minutes to complete. Track the full build history from the **Publishing** page. Learn more about previewing your app in the [Preview Panel](/features/ai-app-builder#preview-panel).
Remember
Create new native builds if you add or remove packages from your app.
## Share page
[Section titled “Share page”](#share-page)
You can create a public share page for any app in Draftbit. This gives your project a clean, standalone page where anyone can view and try it — no Draftbit account required. Great for sharing a prototype with a client, showing off a side project, or sending something to a friend for feedback.

Just click the  button in the top right of the builder and enable the **Share** option. Your share page will be generated and a public URL will be provided which you can send to others.


You can disable sharing later from the same publish popover. Disabled or invalid share links show an unavailable state instead of the app preview.

## Unpublish Web Deployments
[Section titled “Unpublish Web Deployments”](#unpublish-web-deployments)
Production and staging web deployments can be unpublished separately from the Builder publish popover. When a deployment is unpublished, its URL is inactive until you publish that environment again.
## Code Export
[Section titled “Code Export”](#code-export)
You can export your app’s codebase as a ZIP file for [publishing your app](/features/publishing) manually or to continue development outside of Draftbit.
To start the export process, click the  button in the top right of the Builder.

The export process may take a few minutes to complete. Track progress of the export from the export dropdown.
## GitHub Export
[Section titled “GitHub Export”](#github-export)
You can export your app to a GitHub repository to continue development or collaborate with others.
To start the export process, select the **GitHub Export** option from the **Publishing** page. Fill in the required fields and click the **Save Configuration** button.

The export process may take a few minutes to complete. Track progress of the export from the **Publishing** page.
GitHub repository values are validated before saving. You can use a full GitHub URL or an `org/repo` slug, then check access before starting an export.
| Field | Description |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **GitHub Repository URL** | The HTTPS URL of the GitHub repository to which the exported code will be pushed. Example: `https://github.com/username/repository` |
| **GitHub Branch Name** | The branch within your repository where code will be exported. Example: `main` or `develop` |
| **GitHub Access Token** | A personal access token with **repo** (read and write) permissions for authentication with GitHub. [Create a token here](https://github.com/settings/tokens). For security, don’t share your token publicly. |
## App Store Screenshots
[Section titled “App Store Screenshots”](#app-store-screenshots)
Draftbit includes a tool to automatically create screenshots of your app. You can use this tool to create screenshots for your app’s App Store listing.
To open the App Store Screenshot Tool, click the  button in the top toolbar of the [Preview panel](/features/ai-app-builder#preview-panel).

## One-Click Publishing
[Section titled “One-Click Publishing”](#one-click-publishing)
Once you’ve built your app in Draftbit, you’re ready to share it with the world! Draftbit offers two approaches to publishing: **One-Click Publishing** for simplicity, and **Manual Publishing** for more control.
The easiest way to get your app published to the web, iOS, and Android. Draftbit handles the build and submission details automatically.
You can configure publish destinations by switching to the  tab on the **Publishing** page.
Publish activity loads in pages, so long publishing histories stay responsive. Native simulator builds appear separately from web, iOS, and Android publish activity.
When a publish is already running, the publish button shows whether that platform is publishing or queued and prevents duplicate publishes to the same environment. You can still publish a different platform or environment in parallel when available.

iOS Publishing
Deploy to the Apple App Store effortlessly. We manage certificates, provisioning, and TestFlight distribution.
[One-click iOS publishing →](/features/publishing/one-click-publishing/ios-publishing)
Android Publishing
Publish to Google Play Store with a single click. We handle the build process, signing, and submission.
[One-click Android publishing →](/features/publishing/one-click-publishing/android-publishing)
Web Publishing (PWA)
Launch your app as a progressive web app instantly. Share a link and your app works in any browser.
[One-click Web publishing →](/features/publishing/one-click-publishing/web-publishing)
## Manual Publishing
[Section titled “Manual Publishing”](#manual-publishing)
For developers who want full control over the publishing process. You’ll download your app’s source code and handle the deployment yourself.
iOS Publishing
Detailed instructions for building and submitting your iOS app to the Apple App Store.
[Manual iOS publishing →](/features/publishing/manual-publishing/ios-publishing)
Android Publishing
Step-by-step guide to manually build and publish your Android app to Google Play Store.
[Manual Android publishing →](/features/publishing/manual-publishing/android-publishing)
Web Publishing (PWA)
Deploy your app as a progressive web app using your own hosting or deployment service.
[Manual Web publishing →](/features/publishing/manual-publishing/web-publishing)
## How to Choose
[Section titled “How to Choose”](#how-to-choose)
**Choose One-Click Publishing if:**
* You want the fastest, simplest way to publish
* You’re new to app development
* You don’t need custom deployment configurations
**Choose Manual Publishing if:**
* You want full control over the build and deployment process
* You have specific technical requirements
* You want to integrate with your own CI/CD pipeline
* You need to customize app signing or certificates
Ready to publish? Start with one-click publishing for the easiest experience, or dive into manual publishing if you need more control.
# Android Publishing (Local)
> Learn how to manually publish your app to Google Play
One-click publishing
Draftbit offers a one-click publishing feature that can handle all these steps automatically for you. If you prefer a simpler approach, [learn more about one-click publishing](/features/publishing/one-click-publishing/android-publishing).
You can manually publish your app to the Google Play Store by following the directions below.
## Prerequisites
[Section titled “Prerequisites”](#prerequisites)
Before you can publish your app, you’ll need to set up a few accounts and install some software. Think of these as the basic tools you need:
### Required Accounts
[Section titled “Required Accounts”](#required-accounts)
* **[Expo Account](https://expo.dev/signup)** - This is a free service that helps build your app. It’s like having a construction crew that specializes in mobile apps.
* **[Google Developer Account](https://play.google.com/apps/publish/signup/)** - This costs $25 one-time and allows you to publish apps on Google Play Store. Think of it as your business license to sell apps.
### Required Software
[Section titled “Required Software”](#required-software)
* **[Yarn](https://yarnpkg.com/getting-started/install)** - This is a package manager that helps install the dependencies needed to build your app.
* **[Node.js](https://nodejs.org/en/download)** - This is a tool that helps run the code needed to build your app. Download the “LTS” version (which stands for “Long Term Support” - the most stable version).
* **[Git](https://git-scm.com/downloads)** - This helps manage your app’s code files. It’s like a filing system for programmers.
## Using the Console
[Section titled “Using the Console”](#using-the-console)
Throughout this guide, you’ll need to use something called a “console” or “terminal.” This is a text-based way to give instructions to your computer. Don’t worry - it’s easier than it sounds!
### Finding Your Console
[Section titled “Finding Your Console”](#finding-your-console)
* Mac
1. Press Command + Space `CommandSpace` Command + Space `CommandSpace` Command + Space `CommandSpace` to open Spotlight search
2. Type “Terminal” and press Enter
3. A black or white window will open - this is your console
* Windows
1. Press Windows + R `WindowsR` Windows + R `WindowsR` Windows + R `WindowsR`
2. Type “cmd” and press Enter
3. OR: Press Windows + X `WindowsX` Windows + X `WindowsX` Windows + X `WindowsX` and select “Command Prompt” or “PowerShell”
* Linux
1. Press Control + Alt + T `ControlAltT` Control + Alt + T `ControlAltT` Control + Alt + T `ControlAltT`
2. OR: Look for “Terminal” in your applications menu
## What is EAS?
[Section titled “What is EAS?”](#what-is-eas)
EAS (Expo Application Services) is like a specialized factory for mobile apps. Instead of needing complex software on your computer, EAS builds your app in the cloud (on Expo’s powerful computers) and then gives you the finished product.
Think of it this way: instead of baking a cake in your kitchen, you give the recipe to a professional bakery, and they deliver the finished cake to you.
## Install EAS CLI
[Section titled “Install EAS CLI”](#install-eas-cli)
First, you need to install a tool that lets you communicate with EAS. This tool is called “EAS CLI” (CLI stands for “Command Line Interface” - basically a way to give text commands to your computer).
1. **Install EAS CLI**
Open your console (see instructions above) and copy-paste this command, then press Enter:
```bash
npm i -g eas-cli
```
This downloads and installs the EAS tool on your computer. The process might take a few minutes.
2. **Sign in to Expo**
After installation, you need to log in to your Expo account. In the same console window, type:
```bash
eas login
```
The console will ask for your Expo username and password. Type them and press Enter after each one. Don’t worry if you can’t see the password as you type - this is normal for security reasons.
## Download Your Project
[Section titled “Download Your Project”](#download-your-project)
After building your app in Draftbit, you’ll have a folder containing all your app’s code. Here’s how to prepare it:
1. **Download and Open Your Project**
1. Download your app’s code from Draftbit using the **Export** button in the top-right of the [Builder](/intro/building-with-draftbit/builder-overview)
2. Extract the ZIP file to a location you’ll remember (like your Desktop or Documents folder)
3. You can open this folder in a code editor if you have one (like VS Code), but it’s not required
2. **Navigate to Your Project in the Console**
You need to tell the console where your app files are located. In your console:
1. Type `cd `(that’s “cd” followed by a space)
2. Drag your project folder from your file manager into the console window
3. Press Enter
Your console should now show the path to your project folder.
3. **Install Project Dependencies**
Dependencies are like ingredients your app needs to work properly. Install them by typing:
```bash
yarn install
```
This downloads all the necessary components for your app. It might take a few minutes.
4. **Check Everything is Working**
Run this command to make sure everything is set up correctly:
```bash
npx expo-doctor --check
```
This is like a health check for your app. If it finds any issues, it will suggest how to fix them.
## Set Up Your Project
[Section titled “Set Up Your Project”](#set-up-your-project)
Before publishing, you should customize your app’s name and other details.
Easier App Configuration
If you don’t want to manually edit configuration files after downloading your source code, update these settings in Draftbit **before** you export. In **[Settings](/features/project-settings)** you can set properties like **App Name**, **Slug**, **URL Scheme**, **App Icon**, and **Splash Screen**; those values will be included in the exported project.
1. **Updating Your App Name**
1. In your project folder, find a file called `app.json`
2. Open it with any text editor (even Notepad works)
3. Look for a line that says `"name": "..."` and change the text between the quotes to your app’s name
For example:
```json
"name": "My Shopping List App"
```
2. **Setting Your App Slug**
The “slug” is like your app’s unique identifier. It should be lowercase with no spaces:
```json
"slug": "my-shopping-list-app"
```
**Important:** Once you publish your app, you can’t change the slug, so choose carefully!
3. **Initialize EAS for Your Project**
In your console, run:
```bash
eas init
```
This connects your project to EAS. You’ll be asked to choose which Expo account should own this project. Use the arrow keys to select your account and press Enter.
4. **Configure EAS Build**
EAS Build is the service that actually creates your app file. Think of it as setting up the assembly line in that app factory we mentioned earlier.
In your console, run:
```bash
eas build:configure
```
This sets up the configuration for both Android and iOS. You’ll see some text appear - this is normal and means EAS is preparing your project.
## Deploy Your App
[Section titled “Deploy Your App”](#deploy-your-app)
Now comes the exciting part - actually creating your app file and putting it on the Google Play Store!
1. **Build Your App**
In your console, run:
```bash
eas build -p android
```
This tells EAS to build an Android version of your app. The process happens in the cloud, so you can close your console and come back later if you want. You’ll receive an email when it’s done (usually takes 10-20 minutes).
2. **Download Your App File**
Once the build is complete, EAS will provide a link to download your app file (called an APK or AAB file). Download this file to your computer.
3. **Upload to Google Play Console**
Now you need to put your app on the Google Play Store:
1. Go to [Google Play Console](https://play.google.com/console) and sign in
2. Click “Create app” and fill in your app’s details
3. Navigate to “Testing” → “Internal testing”
4. Create a new release and upload the app file you downloaded from EAS
5. Add email addresses of people who should test your app
6. Publish the internal test
4. **Test Your App**
Google will provide you with a testing link. Share this with your testers so they can download and try your app before it goes public.
## Go to Production
[Section titled “Go to Production”](#go-to-production)
Once you’re satisfied with your testing, you can make your app available to everyone:
1. In Google Play Console, go to “Production”
2. Create a new release using the same app file
3. Fill in all required store listing information (descriptions, screenshots, etc.)
4. Submit for review
Google will review your app (this can take a few days) and then make it available in the Play Store for people to download.
## Need Help?
[Section titled “Need Help?”](#need-help)
If you get stuck at any point, remember that Draftbit’s one-click publishing can handle all of these steps automatically. You can also find more detailed technical information in [Expo’s deployment documentation](https://docs.expo.dev/deploy/build-project/).
Don’t be discouraged if this seems overwhelming at first - many successful app developers started exactly where you are now!
# iOS Publishing (Local)
> Learn how to manually publish your app to the App Store
One-click publishing
Draftbit provides a one-click publishing feature that allows you to publish your app to the App Store with a single click. [Learn more about one-click publishing](/features/publishing/one-click-publishing/ios-publishing).
You can manually publish your app to the Apple App Store by following the directions below.
## Prerequisites
[Section titled “Prerequisites”](#prerequisites)
Before you can publish your app, you’ll need to set up a few accounts and install some software. Think of these as the basic tools you need:
### Required Accounts
[Section titled “Required Accounts”](#required-accounts)
* **[Expo Account](https://expo.dev/signup)** - This is a free service that helps build your app. It’s like having a construction crew that specializes in mobile apps.
* **[Apple Developer Account](https://developer.apple.com/account/)** - This costs $99/year and allows you to publish apps on the App Store. Think of it as your business license to sell apps on Apple devices.
### Required Software
[Section titled “Required Software”](#required-software)
* **[Yarn](https://yarnpkg.com/getting-started/install)** - This is a package manager that helps install the dependencies needed to build your app.
* **[Node.js](https://nodejs.org/en/download)** - This is a tool that helps run the code needed to build your app. Download the “LTS” version (which stands for “Long Term Support” - the most stable version).
* **[Git](https://git-scm.com/downloads)** - This helps manage your app’s code files. It’s like a filing system for programmers.
## Using the Console
[Section titled “Using the Console”](#using-the-console)
Throughout this guide, you’ll need to use something called a “console” or “terminal.” This is a text-based way to give instructions to your computer. Don’t worry - it’s easier than it sounds!
### Finding Your Console
[Section titled “Finding Your Console”](#finding-your-console)
* Mac
1. Press Command + Space `CommandSpace` Command + Space `CommandSpace` Command + Space `CommandSpace` to open Spotlight search
2. Type “Terminal” and press Enter
3. A black or white window will open - this is your console
* Windows
1. Press Windows + R `WindowsR` Windows + R `WindowsR` Windows + R `WindowsR`
2. Type “cmd” and press Enter
3. OR: Press Windows + X `WindowsX` Windows + X `WindowsX` Windows + X `WindowsX` and select “Command Prompt” or “PowerShell”
* Linux
1. Press Control + Alt + T `ControlAltT` Control + Alt + T `ControlAltT` Control + Alt + T `ControlAltT`
2. OR: Look for “Terminal” in your applications menu
## What is EAS?
[Section titled “What is EAS?”](#what-is-eas)
EAS (Expo Application Services) is like a specialized factory for mobile apps. Instead of needing complex software on your computer, EAS builds your app in the cloud (on Expo’s powerful computers) and then gives you the finished product.
Think of it this way: instead of baking a cake in your kitchen, you give the recipe to a professional bakery, and they deliver the finished cake to you.
## Install EAS CLI
[Section titled “Install EAS CLI”](#install-eas-cli)
First, you need to install a tool that lets you communicate with EAS. This tool is called “EAS CLI” (CLI stands for “Command Line Interface” - basically a way to give text commands to your computer).
1. **Install EAS CLI**
Open your console (see instructions above) and copy-paste this command, then press Enter:
```bash
npm i -g eas-cli
```
This downloads and installs the EAS tool on your computer. The process might take a few minutes.
2. **Sign in to Expo**
After installation, you need to log in to your Expo account. In the same console window, type:
```bash
eas login
```
The console will ask for your Expo username and password. Type them and press Enter after each one. Don’t worry if you can’t see the password as you type - this is normal for security reasons.
## Download Your Project
[Section titled “Download Your Project”](#download-your-project)
After building your app in Draftbit, you’ll have a folder containing all your app’s code. Here’s how to prepare it:
1. **Download and Open Your Project**
1. Download your app’s code from Draftbit using the **Export** button in the top-right of the [Builder](/intro/building-with-draftbit/builder-overview)
2. Extract the ZIP file to a location you’ll remember (like your Desktop or Documents folder)
3. You can open this folder in a code editor if you have one (like VS Code), but it’s not required
2. **Navigate to Your Project in the Console**
You need to tell the console where your app files are located. In your console:
1. Type `cd `(that’s “cd” followed by a space)
2. Drag your project folder from your file manager into the console window
3. Press Enter
Your console should now show the path to your project folder.
3. **Install Project Dependencies**
Dependencies are like ingredients your app needs to work properly. Install them by typing:
```bash
yarn install
```
This downloads all the necessary components for your app. It might take a few minutes.
4. **Check Everything is Working**
Run this command to make sure everything is set up correctly:
```bash
npx expo-doctor --check
```
This is like a health check for your app. If it finds any issues, it will suggest how to fix them.
## Set Up Your Project
[Section titled “Set Up Your Project”](#set-up-your-project)
Before publishing, you should customize your app’s name and other details.
Easier App Configuration
If you don’t want to manually edit configuration files after downloading your source code, update these settings in Draftbit **before** you export. In **[Settings](/features/project-settings)** you can set properties like **App Name**, **Slug**, **URL Scheme**, **App Icon**, and **Splash Screen**; those values will be included in the exported project.
1. **Updating Your App Name**
1. In your project folder, find a file called `app.json`
2. Open it with any text editor (even Notepad works)
3. Look for a line that says `"name": "..."` and change the text between the quotes to your app’s name
For example:
```json
"name": "My Shopping List App"
```
2. **Setting Your App Slug**
The “slug” is like your app’s unique identifier. It should be lowercase with no spaces:
```json
"slug": "my-shopping-list-app"
```
**Important:** Once you publish your app, you can’t change the slug, so choose carefully!
3. **Initialize EAS for Your Project**
In your console, run:
```bash
eas init
```
This connects your project to EAS. You’ll be asked to choose which Expo account should own this project. Use the arrow keys to select your account and press Enter.
4. **Configure EAS Build**
EAS Build is the service that actually creates your app file. Think of it as setting up the assembly line in that app factory we mentioned earlier.
In your console, run:
```bash
eas build:configure
```
This sets up the configuration for both Android and iOS. You’ll see some text appear - this is normal and means EAS is preparing your project.
## Deploy Your App
[Section titled “Deploy Your App”](#deploy-your-app)
Now comes the exciting part - actually creating your app file and getting it ready for the App Store!
Important
You need an Apple Developer account for this step. This is different from a regular Apple ID - it’s a paid account ($99/year) that allows you to publish apps.
1. **Build and Submit Your App**
In your console, run:
```bash
eas build -s
```
When prompted, select `ios` as the platform. This special command does several things automatically:
1. **Builds your app** - Creates the app file that can run on iPhones and iPads
2. **Submits to App Store** - Automatically uploads it to Apple for you
3. **Sets up TestFlight** - Creates a testing group so people can try your app before it goes public
This process happens in the cloud and usually takes 15-30 minutes. You can close your console and come back later if you want.
2. **What Happens Automatically**
If this is your first time publishing with EAS, it will automatically:
* Create an app entry in your Apple Developer account
* Set up an internal TestFlight group for testing
* Add members from your Apple Developer account to the testing group
* Send invitation emails to testers when the build is ready
3. **Testing Your App**
Once the build is complete, you and your testers will receive invitation emails from TestFlight (Apple’s testing service). TestFlight lets people download and test your app before it becomes publicly available in the App Store.
4. **Follow the Prompts**
Throughout this process, the console will ask you questions. In most cases, you can simply press **Enter** to accept the default answers. The system is designed to work well with standard settings.
## Go to Production
[Section titled “Go to Production”](#go-to-production)
After testing your app and making sure everything works well, you can make it available to the public:
### Making Your App Public
[Section titled “Making Your App Public”](#making-your-app-public)
1. Go to [App Store Connect](https://appstoreconnect.apple.com)
2. Find your app in the list
3. Fill in all the required information:
* App description
* Screenshots
* Keywords
* Pricing information
* Privacy policy (if required)
4. Submit your app for Apple’s review
### The Review Process
[Section titled “The Review Process”](#the-review-process)
Apple will review your app to make sure it follows their guidelines. This process typically takes 1-3 days, but can sometimes take longer. Once approved, your app will be available for download in the App Store.
## Need Help?
[Section titled “Need Help?”](#need-help)
If you get stuck at any point, remember that Draftbit’s one-click publishing can handle all of these steps automatically. You can also find more detailed technical information in [Expo’s deployment documentation](https://docs.expo.dev/deploy/build-project/).
Publishing your first app is a big accomplishment - don’t be discouraged if it seems overwhelming at first. Many successful app developers started exactly where you are now!
# Web Publishing (Local)
> Learn how to publish your app to the web
One-click publishing
Draftbit provides a one-click publishing feature that allows you to publish your app to the web with a single click. [Learn more about one-click publishing](/features/publishing/one-click-publishing/web-publishing).
You can manually publish your app to the Web as a Progressive Web App (PWA) by following the directions below.
## Prerequisites
[Section titled “Prerequisites”](#prerequisites)
Before you can publish your app as a Web App, you’ll need to set up an account and install some software. Think of these as the basic tools you need:
### Required Accounts
[Section titled “Required Accounts”](#required-accounts)
* **[Expo Account](https://expo.dev/signup)** - This is a free service that helps build and host your app. It’s like having a construction crew and web hosting service all in one.
### Required Software
[Section titled “Required Software”](#required-software)
* **[Yarn](https://yarnpkg.com/getting-started/install)** - This is a package manager that helps install the dependencies needed to build your app.
* **[Node.js](https://nodejs.org/en/download)** - This is a tool that helps run the code needed to build your app. Download the “LTS” version (which stands for “Long Term Support” - the most stable version).
* **[Git](https://git-scm.com/downloads)** - This helps manage your app’s code files. It’s like a filing system for programmers.
## Using the Console
[Section titled “Using the Console”](#using-the-console)
Throughout this guide, you’ll need to use something called a “console” or “terminal.” This is a text-based way to give instructions to your computer. Don’t worry - it’s easier than it sounds!
### Finding Your Console
[Section titled “Finding Your Console”](#finding-your-console)
* Mac
1. Press Command + Space `CommandSpace` Command + Space `CommandSpace` Command + Space `CommandSpace` to open Spotlight search
2. Type “Terminal” and press Enter
3. A black or white window will open - this is your console
* Windows
1. Press Windows + R `WindowsR` Windows + R `WindowsR` Windows + R `WindowsR`
2. Type “cmd” and press Enter
3. OR: Press Windows + X `WindowsX` Windows + X `WindowsX` Windows + X `WindowsX` and select “Command Prompt” or “PowerShell”
* Linux
1. Press Control + Alt + T `ControlAltT` Control + Alt + T `ControlAltT` Control + Alt + T `ControlAltT`
2. OR: Look for “Terminal” in your applications menu
## What is EAS?
[Section titled “What is EAS?”](#what-is-eas)
EAS (Expo Application Services) is like a specialized factory for apps and Web Apps. Instead of needing complex software on your computer, EAS builds your app in the cloud (on Expo’s powerful computers) and can even host your Web App for you.
Think of it this way: instead of baking a cake in your kitchen and then finding a place to serve it, you give the recipe to a professional bakery that also runs a café - they bake it and serve it to customers for you.
## Install EAS CLI
[Section titled “Install EAS CLI”](#install-eas-cli)
First, you need to install a tool that lets you communicate with EAS. This tool is called “EAS CLI” (CLI stands for “Command Line Interface” - basically a way to give text commands to your computer).
1. **Install EAS CLI**
Open your console (see instructions above) and copy-paste this command, then press Enter:
```bash
npm i -g eas-cli
```
This downloads and installs the EAS tool on your computer. The process might take a few minutes.
2. **Sign in to Expo**
After installation, you need to log in to your Expo account. In the same console window, type:
```bash
eas login
```
The console will ask for your Expo username and password. Type them and press Enter after each one. Don’t worry if you can’t see the password as you type - this is normal for security reasons.
## Download Your Project
[Section titled “Download Your Project”](#download-your-project)
After building your app in Draftbit, you’ll have a folder containing all your app’s code. Here’s how to prepare it:
1. **Download and Open Your Project**
1. Download your app’s code from Draftbit using the **Export** button in the top-right of the [Builder](/intro/building-with-draftbit/builder-overview)
2. Extract the ZIP file to a location you’ll remember (like your Desktop or Documents folder)
3. You can open this folder in a code editor if you have one (like VS Code), but it’s not required
2. **Navigate to Your Project in the Console**
You need to tell the console where your app files are located. In your console:
1. Type `cd `(that’s “cd” followed by a space)
2. Drag your project folder from your file manager into the console window
3. Press Enter
Your console should now show the path to your project folder.
3. **Install Project Dependencies**
Dependencies are like ingredients your app needs to work properly. Install them by typing:
```bash
yarn install
```
This downloads all the necessary components for your app. It might take a few minutes.
4. **Check Everything is Working**
Run this command to make sure everything is set up correctly:
```bash
npx expo-doctor --check
```
This is like a health check for your app. If it finds any issues, it will suggest how to fix them.
## Set Up Your Project
[Section titled “Set Up Your Project”](#set-up-your-project)
Before publishing, you should customize your app’s name and other details.
Easier App Configuration
If you don’t want to manually edit configuration files after downloading your source code, update these settings in Draftbit **before** you export. In **[Settings](/features/project-settings)** you can set properties like **App Name**, **Slug**, **URL Scheme**, **App Icon**, and **Splash Screen**; those values will be included in the exported project.
1. **Updating Your App Name**
1. In your project folder, find a file called `app.json`
2. Open it with any text editor (even Notepad works)
3. Look for a line that says `"name": "..."` and change the text between the quotes to your app’s name
For example:
```json
"name": "My Shopping List App"
```
2. **Setting Your App Slug**
The “slug” is like your app’s unique identifier. It should be lowercase with no spaces:
```json
"slug": "my-shopping-list-app"
```
**Important:** Once you publish your app, you can’t change the slug, so choose carefully!
3. **Initialize EAS for Your Project**
In your console, run:
```bash
eas init
```
This connects your project to EAS. You’ll be asked to choose which Expo account should own this project. Use the arrow keys to select your account and press Enter.
4. **Configure EAS Build**
EAS Build is the service that actually creates your Web App files. Think of it as setting up the assembly line in that factory we mentioned earlier.
In your console, run:
```bash
eas build:configure
```
This sets up the configuration for web deployment. You’ll see some text appear - this is normal and means EAS is preparing your project.
## Deploy Your Web App
[Section titled “Deploy Your Web App”](#deploy-your-web-app)
Now comes the exciting part - actually creating your Web App and making it available online!
1. **Generate Your Web App Files**
First, you need to create the files that will become your Web App. In your console, run:
```bash
npx expo export --platform web
```
This command takes your app and converts it into Web App files. These files will be saved in a folder called `dist` in your project directory. This process usually takes a few minutes.
Think of this step like converting your recipe into the actual finished product - your app becomes a collection of web files that browsers can understand.
2. **Deploy to the Web**
Now you’ll upload your Web App to Expo’s servers so people can visit it. In your console, run:
```bash
eas deploy --prod
```
This command will:
1. Upload your Web App files to Expo’s servers
2. Give you a web address (URL) where people can visit your app
3. Make your app available to anyone with an internet connection
You’ll be asked to choose a preview URL for your project. You can usually just press **Enter** to accept the suggested URL.
3. **Share Your Web App**
Once the deployment is complete, you’ll receive a web address (URL) that looks something like `https://your-app-name.exp.host`. This is your Web App’s address - you can share this link with anyone, and they’ll be able to use your app in their web browser!
#### What Makes This Different from Mobile Apps?
[Section titled “What Makes This Different from Mobile Apps?”](#what-makes-this-different-from-mobile-apps)
Unlike mobile apps that need to be downloaded from app stores, your web app can be used immediately by anyone with a web browser. People can:
* Visit your Web App on their phone, tablet, or computer
* Use it without downloading anything
* Bookmark it like any other Web App
* Share the link with others easily
## Manage Your Web App
[Section titled “Manage Your Web App”](#manage-your-web-app)
Congratulations! Your app is now live on the web. Here’s what you can do next:
### Updating Your Web App
[Section titled “Updating Your Web App”](#updating-your-web-app)
When you make changes to your app in Draftbit:
1. Download the updated code
2. Follow the same steps to export and deploy
3. Your Web App will be updated with the new changes
### Monitoring Your Web App
[Section titled “Monitoring Your Web App”](#monitoring-your-web-app)
* Your Web App will stay online as long as your Expo account is active
* You can check how many people are visiting through Expo’s dashboard
* The Web App works on all devices and browsers automatically
### Getting Your Own Domain (Optional)
[Section titled “Getting Your Own Domain (Optional)”](#getting-your-own-domain-optional)
If you want a custom web address (like `www.myapp.com` instead of the Expo URL), you can:
1. Purchase a domain name from services like GoDaddy or Namecheap
2. Set up domain forwarding to point to your Expo URL
3. This step is optional - your Expo URL works perfectly fine for sharing
## Need Help?
[Section titled “Need Help?”](#need-help)
If you get stuck at any point, remember that Draftbit’s one-click publishing can handle all of these steps automatically. You can also find more detailed technical information in [Expo’s deployment documentation](https://docs.expo.dev/deploy/build-project/).
Publishing your first web app is a fantastic achievement - you’ve just made your creation available to anyone in the world with an internet connection!
# Android Publishing (Cloud)
> Publish your app to Google Play Store with one click
Draftbit supports publishing your app to the Google Play Store. In order to do this, you’ll need to complete a few setup steps and provide us with some information. This guide details those steps.
## App Settings
[Section titled “App Settings”](#app-settings)
Before you start the publishing process, make sure your app’s configuration properties are up to date in **Settings**. At a minimum, we recommend you review and update:
* **App Name**: The name shown on the device home screen after install
* **Slug**: A URL-friendly identifier used in publishing/build processes
* **URL Scheme**: URL scheme for deep linking into your app (e.g., myapp\:// would use ‘myapp’).
* **Description**: A short description of your app
* **App Icon**: Your app’s icon (we recommend uploading a 1024×1024 PNG)
* **Splash Screen**: The launch screen users see while your app loads
For more details (and the full list of available properties), see [App Configuration](/features/app-configuration).
## Google Developer Account
[Section titled “Google Developer Account”](#google-developer-account)
First, in order to publish to the Google Play Store, you’ll need a Google Developer account.
* [Create a Google Developer Account](https://play.google.com/console/signup) if you don’t already have one
* Pay the $25 fee.
* Provide the required information
* Verify your account by providing a government-issued photo ID that matches the information you provided on sign-up if required.
See [this guide](https://play.google.com/console/signup) for more information on how to sign up.
## Create a Package Name
[Section titled “Create a Package Name”](#create-a-package-name)
Next, you’ll need to create a Package Name for your app. This is unique to your app which identifies it inside of Google’s system. You’ll need to add it to the Google Play Console configuration in Draftbit.
Note
Your Package Name should use the reverse-dns name structure. For example, if the domain you will use for this app is `example.com`, set your Package Name to `com.example.appname`.
## Create a new app in Google Play
[Section titled “Create a new app in Google Play”](#create-a-new-app-in-google-play)
You’ll need to create an App in your Google Play Console in order to upload Draftbit app binaries.
1. **Open Google Play Console**
Go to your [Google Play Console](https://play.google.com/console)

2. **Create a new app**
Navigate to the **All Apps** page, then click the **Create app** button in the upper right.
Select **Default language**, **App or game**, **Free or paid**, fill in the **App name** input and click **Create app** in the bottom right.

You’ll be redirected to a new page, **Dashboard**, where you can fill in all information about your application. *This step can be done later if you prefer.*
## Create Service Account Key
[Section titled “Create Service Account Key”](#create-service-account-key)
In order for Draftbit to publish builds to your Google Play Console, you’ll need to create a **Google Service Account Key** and upload it to your Draftbit account.
1. **Open [Google Cloud Console](https://console.cloud.google.com/projectcreate)**
You will be directed to **New Project** page. You need to enter your project name and organization name (optional) and press on **Create** to continue.
2. **Enable [Google Play Android Developer API](https://console.cloud.google.com/marketplace/product/google/androidpublisher.googleapis.com)**

In the upcoming page ensure that you have selected the project you have recently created and then click on **Enable** button
3. **Create credentials**
Now select **Credentials** tab and click **Create Credentials**button. From the dropdown menu select **Service Account** option.

You will be directed to **[IAM & Admin](https://console.cloud.google.com/iam-admin/serviceaccounts/create)** page.
1. **Enter a Service account name**
Enter a **Service account name**. *Pick a name that makes it easy to identify that this account is for the Google Play Store*.
A “Service account ID” will be added automatically, but you can edit to be whatever you like.

Copy the email address given when you have entered the Service account name and click on **Create and Continue** button.
2. **Select a role**
Next, you’ll grant your service account access to your **Google Play Console Developer** account. Click **Select a role** and choose **Service Accounts > Service Account User**. *Note that typing in the filter text box won’t return the Service Accounts role - you’ll have to scroll to it.*
Important
This is an important step. Missing this step will cause a failure of auto submissions.

3. **Done**
The third step is optional, you can leave it as it is and click **Done** to continue.

You will be navigated back to **APIs & Services** page.
1. **Navigate to Service Accounts**
Now select the service account you have created here and the page will be directed to Service Accounts automatically.

2. **Create new key**
In the navigated page, select **Keys** from the options button for your newly created **Service Account**. Select **Create new key**.

Select **JSON** and then click **Create**. Download the **.json** file and store it in a safe place for future reference.

Keep it safe
The JSON file you download at this step won’t be available for you to download again in the future, so ensure you keep it somewhere secure and easy for you to find in the future.
## Set up account permissions
[Section titled “Set up account permissions”](#set-up-account-permissions)
1. **Open Google Play Console**
Now in your [Google Play Console](https://play.google.com/console) go to the **Users and permissions** page and select **Invite new users** option.
Paste the copied email address at the beginning of the key generation process and then select the account permissions.

2. **Account permissions**
In **Account permissions**, you should choose **Admin** for enabling all the permissions. Then click **Invite User**.

Ready for takeoff
Now, in the builder you can hit the Publish button to start the build process.
## Upload your first Android binary
[Section titled “Upload your first Android binary”](#upload-your-first-android-binary)
Now that you have a successful build, you would need to submit it. When submitting your Android app to Google Play Store for the first time, Google requires that you manually upload it in the Google Play Console. As a result, when you first request an Android publish from Draftbit for a new app, we’ll send you your app binary (.aab) and you’ll need to upload it via your Google Play Console account. **Future publishes for that app will be uploaded automatically by Draftbit**
1. **Open Google Play Console**
Go to your [Google Play Console](https://play.google.com/console) and navigate to your app’s **Dashboard**. Click on **Testing** in the left-hand sidebar, then select **Internal testing**.

2. **Create new release**
Click the **Create new release** button

**App signing by Google Play**.

3. **Choose Signing Key**
In the appearing modal select **use Google-generated key** option. *This is critical to allow Draftbit publish future app for you*.

4. **Submit Release**
Then, enter your **Release name**, enter any relevant **Release notes** and click **Review release**.

You’ll then be navigated to the **Review summary** view. At the top, you’ll see the **Errors** section. If there are errors, click **Show more** to view the details.
What to do about errors
Errors in your in your build could have several causes. Some could be issues with your app code itself, some could be related to the app settings you provided us, etc. If you’re stuck, please reach out to support.
## Add a privacy policy to your app
[Section titled “Add a privacy policy to your app”](#add-a-privacy-policy-to-your-app)
Google requires that all apps in the Play Store have an associated Privacy Policy. If you don’t have one, you may have noticed a resulting error when you uploaded your binary/.aab file the first time.
1. **Open Google Play Console**
Go to your [Google Play Console](https://play.google.com/console) and navigate to your app’s **Dashboard** and click **App content**. You’ll see a **Privacy Policy** section at the top of that page - Click **Start** in that section.

2. **Enter Privacy Policy**
Enter your **Privacy Policy** link in the prompt and click **Save**

Navigate back to the **Internal testing** page and click the **Edit** button for your App. You should no longer see the Privacy Policy error on the **Review Summary** page for your App.
## Add testers for your app
[Section titled “Add testers for your app”](#add-testers-for-your-app)
You can invite people to test your app before publishing it to the Play Store. Here’s how to add testers to your app.
1. **Open Google Play Console**
Go to your [Google Play Console](https://play.google.com/console) and navigate to your app’s **Internal Testing** by clicking on Testing > Internal testing. In the upcoming page select the Testers tab.

2. **Create Email List**
Under “Testers,” you are able to create an email list for testers.

Enter a list name and add email addresses you wish to add. You can also upload CSV file that includes listed testers. Then select Save changes, then Create.

3. **Invite testers**
In the “Testers” tab, you can select the user lists you want to test your release.
In the below, to gather feedback from testers, you can provide a feedback URL or email address. Copy the shareable link to share the release with testers and save the changes


## Configure your app settings
[Section titled “Configure your app settings”](#configure-your-app-settings)
Go to **Publishing** page and select the **Google Play Store** option.

* Enter the **Package Name** you created in the previous step into the
* **Package Name** field. Upload the **Google Service Account Key** file that you downloaded in the previous step into the **Service Account** field. Click the
* **Save Configuration** button
## Publish your app
[Section titled “Publish your app”](#publish-your-app)
Now, you’re ready to publish your app to the Google Play Store.

1. **Open the Publish dropdown**
Click the  button from the top-right of the Builder to open the Publish dropdown.
2. **Choose Google Play Store**
Click the  button for the **Google Play Store** option.
3. **Start a new publish**
Enter a version name, number, and environment for your publish and then click the  to start the publishing process.

| Name | Description |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Version Name** | A name for this version of your app publish (e.g., “Initial Release”, “Major Update”, “v3”). |
| **Version Number** | The version number assigned to this publish (e.g., “1”, “2.0”, “3.1”). |
| **Environment** | The publish environment to use. Options: **Staging** or **Production**. Environment variable values are managed in [Build Config](/features/build-config#environment-variables). |
Staging vs Production
Use **Staging** when you want to validate a release in a non-production environment, and use **Production** when you’re ready to ship your live Play Store release.
Grab a coffee
You can leave and come back to check on the progress of your publish at any time. The publish will continue in the background and you’ll be notified when it’s complete. Visit the [Publishing](/features/publishing) page in the Builder to view the status of your ongoing and completed publishes.
## Publishing apps built outside Draftbit
[Section titled “Publishing apps built outside Draftbit”](#publishing-apps-built-outside-draftbit)
If an Android app was originally published using another toolchain or Draftbit Classic, update builds submitted through Draftbit can fail when Draftbit uses a different upload key. Google Play will reject the upload due to signature mismatch.
If the Play Store listing was created with another key, Google Play requires an upload key reset before accepting new builds.
To resolve this issue, you need to reset the upload key for your app. Here’s how to do it:
Notes
* This reset is needed only once per app
* Do not create a new Play Store app listing
* This changes the upload key, not the Google-managed app signing key
1. **Open Google Play Console**
Go to the [Google Play Console](https://play.google.com/console) and sign in.
2. **Choose the app you want to reset the upload key for**

3. **Go to Test & Release → App integrity**

4. **Find App signing section**

5. **Request upload key reset / replacement**


6. **Provide the new upload certificate**
Download the generated signing files from the Draftbit publish output

7. **Upload the new upload certificate**

8. **Wait for Google confirmation**
After you’ve uploaded the new upload certificate, Google will review your request to reset the upload key. This review process is handled by Google and can take several days to complete. During this time, you don’t need to take any further action—simply wait for Google to complete their verification.
Once Google has finished processing your request and has updated the upload key for your app, they will send a confirmation email to the address associated with your Google Play Developer account. Make sure to check your email (including your spam or promotions folder) for this notification.
Only after receiving confirmation from Google should you proceed with submitting a new build through Draftbit. Attempting to publish before the upload key is updated may result in further errors.
9. **Publish again through Draftbit**
Run a new Android publish through Draftbit. The upload should now succeed with the registered key.
# iOS Publishing (Cloud)
> Publish your app to Apple App Store with one click
Draftbit supports publishing your app to the Apple App Store. In order to do this, you’ll need to complete a few setup steps and provide us with some information. This guide details those steps.
## App Settings
[Section titled “App Settings”](#app-settings)
Before you start the publishing process, make sure your app’s configuration properties are up to date in **Settings**. At a minimum, we recommend you review and update:
* **App Name**: The name shown on the device home screen after install
* **Slug**: A URL-friendly identifier used in publishing/build processes
* **URL Scheme**: URL scheme for deep linking into your app (e.g., myapp\:// would use ‘myapp’).
* **Description**: A short description of your app
* **App Icon**: Your app’s icon (we recommend uploading a 1024×1024 PNG)
* **Splash Screen**: The launch screen users see while your app loads
For more details (and the full list of available properties), see [App Configuration](/features/app-configuration).
## Apple Developer Account
[Section titled “Apple Developer Account”](#apple-developer-account)
First, in order to publish to the Apple App Store, you’ll need an Apple account and a Developer membership.
* [Create an Apple Account](https://appleid.apple.com/account?appId=632\&returnUrl=https%3A%2F%2Fdeveloper.apple.com%2Faccount%2F) if you don’t already have one
* Enroll in the [Apple Developer Program](https://developer.apple.com/programs/enroll/)
* Pay the $99/year fee
* Provide the required information
* Verify your account by providing a government-issued photo ID that matches the information you provided on sign-up if required.
See [this guide](https://developer.apple.com/help/account/membership/program-enrollment) for more information on how to sign up.
## Create a Bundle Identifier
[Section titled “Create a Bundle Identifier”](#create-a-bundle-identifier)
Next, you’ll need to create a Bundle Identifier (ID) for your app. This is unique to your app which identifies it inside of Apple’s system.
Note
Your Bundle Identifier should use the reverse-dns name structure. For example, if the domain you will use for this app is `example.com`, set your Bundle Identifier to `com.example.appname`.
Log in to your [Apple Developer](https://developer.apple.com/account) account and select **Identifiers** from **Certificates, IDs & Profiles** section.

Click on the **Add button (+)**.

The **Register a new identifier** page will open. Select **App ID**s and then select **Continue**.

Select **App** and then click **Continue**.

Enter the Apple Bundle information:
* **Bundle ID**: Enter the **Bundle Identifier** you created in the previous step into this field.
* **Description**: Enter a short description for your Bundle
* **Capabilities**: Scroll down and select the capabilities that are required for your app.

Check the boxes next to any other capabilities your app requires. For example, if your app requires Map capabilities make sure to check the box for that.
When you’re finished, select **Register**.

## Add a New App in App Store Connect
[Section titled “Add a New App in App Store Connect”](#add-a-new-app-in-app-store-connect)
Now, you need to add your app to [App Store Connect](https://help.apple.com/app-store-connect/#/dev2cd126805) which is where you will manage and submit your app to the App Store.
Go to [App Store Connect](https://appstoreconnect.apple.com/apps), select **Apps**, then click on the **Add button (+)** and then select **New App**.

Enter your app information in the modal that appears:
* **Platform**: for mobile apps this will be iOS.
* **Name**: Enter a Name for your app (this is the name that will show in the App Store).
* **Primary Language** for your app.
* **Bundle ID**: Select the Bundle ID you created in the previous step.
* **SKU**: Enter a unique identifier. We recommend using your Bundle ID here, as long as it’s unique.
* **User Access**: You should leave this set to **Full Access** unless you intend to only use this app privately. If you select **Limited Access**, you’ll need to add the users that you would like to grant access to this app. *This will only appear if you have other users included in your App Store Connect account*.

When you’re done, select **Create**.
## Get Your Team ID
[Section titled “Get Your Team ID”](#get-your-team-id)
Next you’ll need to get your Team ID.
From the main page of your [Apple Developer Account](https://developer.apple.com/account), select **Membership Details** from the top menu. Copy the **Team ID** associated with your Developer Account for future reference.
**Organization Membership Details** 
**Individual Membership Details** 
## Get Your API Key
[Section titled “Get Your API Key”](#get-your-api-key)
Note
This step must be performed by an App Store Connect Admin User.
At this point, you need to generate an **API Key**. On the screen that you were navigated to after creating the app, choose **Users and Access**.

From the [Users and Access](https://appstoreconnect.apple.com/access/users) page, select **Integrations** tab on the top.

If you see the **Request Access** button, click on it. If you haven’t added a key before, click on the **Generate API Key**. Otherwise, select the **Add button (+)**.
Enter your **API Key** Information in the modal that appears:
* **Name**: Enter a name for the key. This is a reference and is not part of the key itself. We recommend naming it ‘**Draftbit Publishing**’ so it will be easier to identify in the future.
* **Access**: Select **App Manager** as the access type. For additional information on Roles, [see the docs here](https://developer.apple.com/support/roles/).
When you’re done, select **Generate**.

Find the row for the API Key you just generated and select **Download API Key**. A modal will appear, select **Download**. *Refresh the page if the link doesn’t appear immediately.*

## Get Your Issuer ID
[Section titled “Get Your Issuer ID”](#get-your-issuer-id)
Next you’ll need to get your Issuer ID. In App Store Connect, go to [**Users and Access** page](https://appstoreconnect.apple.com/access/integrations/api) and select **Integrations** tab. Find the **Issuer ID** and select **Copy** for future reference.

## Get Your Key ID
[Section titled “Get Your Key ID”](#get-your-key-id)
Now, you need to get the **Key ID** for the API Key you generated. In App Store Connect, go to [**Users and Access** page](https://appstoreconnect.apple.com/access/integrations/api) and select **Integrations** tab. Find the row for the **API Key** you generated and select **Copy Key ID** for future reference.

## Get Your App Store App ID
[Section titled “Get Your App Store App ID”](#get-your-app-store-app-id)
Finally, you need to get your App ID that was assigned to your new app.
* Go to [App Store Connect](https://appstoreconnect.apple.com/apps) go to the **Apps**.
* Click on your app in the list.
* Click **App Information** under the **General** heading on the left
* Scroll down to the **General Information** section
* Copy your **Apple ID**

## Configure Your App Settings
[Section titled “Configure Your App Settings”](#configure-your-app-settings)
Go to **Publishing** page and select the **Apple App Store** option.

* Enter the **Bundle Identifier** you created in the previous step into the **Bundle ID** field.
* Enter the **Team ID** you copied during the previous step into the **Team ID** field.
* Past the **Key ID** you copied during the previous step into the **App Store Connect API Key ID** field.
* Paste the **Issuer ID** you copied during the previous step into the **App Store Connect Issuer ID** field.
* Paste the **Apple ID** you copied during the previous step into the **App Store App ID** field.
* Upload the **API Key** file that you downloaded in the previous Step
* Click the **Save Configuration** button
## Publish Your App
[Section titled “Publish Your App”](#publish-your-app)
Now, you’re ready to publish your app to the Apple App Store.

1. **Open the Publish dropdown**
Click the  button from the top-right of the Builder to open the Publish dropdown.
2. **Choose Apple App Store**
Click the  button for the **Apple App Store** option.
3. **Start a new publish**
Enter a version name, number, and environment for your publish and then click the  to start the publishing process.

| Name | Description |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Version Name** | A name for this version of your app publish (e.g., “Initial Release”, “Major Update”, “v3”). |
| **Version Number** | The version number assigned to this publish (e.g., “1”, “2.0”, “3.1”). |
| **Environment** | The publish environment to use. Options: **Staging** or **Production**. Environment variable values are managed in [Build Config](/features/build-config#environment-variables). |
Staging vs Production
Use **Staging** when you want to test a release workflow before shipping broadly, and use **Production** when you’re ready for your live App Store release.
Grab a coffee
You can leave and come back to check on the progress of your publish at any time. The publish will continue in the background and you’ll be notified when it’s complete. Visit the [Publishing](/features/publishing) page in the Builder to view the status of your ongoing and completed publishes.
# Web Publishing (Cloud)
> Publish your web app to a custom domain with one click
Draftbit makes it easy to deploy your web app to a test `draftbit.dev` or custom domain with a single click! When deploying your web app through Draftbit, it is hosted using Cloudflare’s serverless [Workers](https://workers.cloudflare.com/) which includes a high-performance global availability network, automatic load balancing, autoscaling, and more. An [SSL certificate](https://www.cloudflare.com/learning/ssl/what-is-an-ssl-certificate/) is automatically generated for your domain to ensure secure communication between your users and your web app.
## App Settings
[Section titled “App Settings”](#app-settings)
Before you start the publishing process, make sure your app’s configuration properties are up to date in **Settings**. At a minimum, we recommend you review and update:
* **App Name**: The name shown on the device home screen after install
* **Slug**: A URL-friendly identifier used in publishing/build processes
* **URL Scheme**: URL scheme for deep linking into your app (e.g., myapp\:// would use ‘myapp’).
* **Description**: A short description of your app
* **App Icon**: Your app’s icon (we recommend uploading a 1024×1024 PNG)
For more details (and the full list of available properties), see [App Configuration](/features/app-configuration).
## Publish Your Web App
[Section titled “Publish Your Web App”](#publish-your-web-app)
During development, you can publish your web app to a test `draftbit.dev` domain *for free* with zero configuration required to share with others for testing and feedback.
When you’re ready to publish your web app to the world, you can set up a [custom domain](#set-up-a-custom-domain) and publish updates with one click!

To publish your app to the web, use the following steps:
1. **Open the Publish dropdown**
Click the  button from the top-right of the Builder to open the Publish dropdown.
2. **Choose Progressive Web App**
Click the  button for the **Progressive Web App** option.
3. **Start a new publish**
Enter a version name, number, and environment for your publish and then click the  to start the publishing process.

| Name | Description |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Version Name** | A name for this version of your web app (e.g., “Initial Release”, “Major Update”, “v3”). |
| **Version Number** | The version number assigned to this publish (e.g., “1”, “2.0”, “3.1”). |
| **Environment** | The publish environment to use. Options: **Staging** or **Production**. Environment variable values are managed in [Build Config](/features/build-config#environment-variables). |
Grab a coffee
You can leave and come back to check on the progress of your publish at any time. The publish will continue in the background and you’ll be notified when it’s complete. Visit the [Publishing](/features/publishing) page in the Builder to view the status of your ongoing and completed publishes.
#### Preview URL
[Section titled “Preview URL”](#preview-url)
By default, your app will be published to a test domain and the preview URL will become available once the publish is complete. The URL looks something like this:
`https://.draftbit.dev`
You can share this link with others to preview your app on the web as a Progressive Web App.
If you’ve configured a [custom domain](#set-up-a-custom-domain), the preview URL will be the same as the custom domain you configured.
## Set up a Custom Domain
[Section titled “Set up a Custom Domain”](#set-up-a-custom-domain)
When you’re ready to publish your web app to the world, you can connect your custom domain and publish updates with one click!
### Prerequisites
[Section titled “Prerequisites”](#prerequisites)
**Custom domain**
You’ll need to have a registered domain name to publish your web app to. You can use a top-level domain name like `myapp.com`, `myapp.org`, `myapp.io`, etc. or a subdomain like `pwa.myapp.com`. Domain names can be purchased from a domain name registrar like [Namecheap](https://www.namecheap.com), [Cloudflare Registrar](https://www.cloudflare.com/products/registrar/), or [Porkbun](https://porkbun.com).
**Access to DNS records**
DNS records are used to tell your domain name where to find your web app. You’ll need the ability to add DNS records to your domain in order to connect your custom domain - specifically, `CNAME/ALIAS` and `TXT` records. This is typically done through your domain registrar’s control panel. Refer to your domain registrar’s documentation for instructions on how to add DNS records.
### Connecting
[Section titled “Connecting”](#connecting)
To get started publishing your web app to a custom domain, head over to the [Publishing](/features/publishing) page in the Builder, switch to the **Configuration** tab, and click the **Custom Domain** option.

#### Environment and Domain
[Section titled “Environment and Domain”](#environment-and-domain)
In this first step, you’ll need to configure the publish environment and domain you want to publish your web app to.

| Name | Description |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Environment** | The publish environment to use. Available options are **Staging** and **Production**. Environment variable values are managed in [Build Config](/features/build-config#environment-variables). |
| **Domain** | The domain to publish your web app to. This should be a domain you own and have access to. |
Once you’ve configured the environment and domain, click the **Save** button to continue.
#### DNS Records
[Section titled “DNS Records”](#dns-records)
In this step, you’ll need to add the DNS records to your domain. This is typically done through your domain registrar’s control panel. Refer to your domain registrar’s documentation for instructions on how to add DNS records.
You’ll create two DNS records (`CNAME/ALIAS` and `TXT`) and each DNS record will have a name and value that must exactly match the unique values provided in the publishing configuration UI.

| Name | Description |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **CNAME/ALIAS Record** | The `CNAME` or `ALIAS` record to add to your domain. This entry is required for your domain to point to Draftbit’s proxy server. Use a `CNAME` entry for subdomains, or an `ALIAS` entry for the root/APEX domain. |
| **TXT Record** | The `TXT` record to add to your domain. This is used to verify that you own the domain and allows Draftbit to generate the [SSL certificate](https://www.cloudflare.com/learning/ssl/what-is-an-ssl-certificate/) for your domain. |
Give it time
While it usually only takes a few minutes, in some cases **it may take up to 24 hours** for the DNS records to propagate through the internet before verification can be completed. If you’re having trouble with your domain verification after 24 hours, please contact support.
#### Domain Verification
[Section titled “Domain Verification”](#domain-verification)
Once you’ve added the DNS records, you’ll need to verify that you own the domain. This is done by clicking the  button.
When the verification is complete and successful, you’ll see  and  badges and the domain will be added to the publishing configuration.

Ready for takeoff
Once you’ve verified your domain, when you publish your web app, it will be published to the custom domain you configured.
If for some reason the verification fails, you’ll see an error message and there will be a link to the failure logs. You’ll need to verify the DNS records and try again. If the issue persists, please contact support.
### Disconnecting
[Section titled “Disconnecting”](#disconnecting)
If you want to disconnect your custom domain, you can do so by clicking the  button from the custom domain configuration modal.
# Tasks
> Track, organize, and start work from a shared task board inside the Builder
The Tasks page gives you a shared place to plan work for an app, assign ownership, and hand individual tasks to an agent when you are ready to start.

## Open Tasks
[Section titled “Open Tasks”](#open-tasks)
Open **Tasks** from the project navigation inside the Builder.
The page opens in a split layout:
* The left side is your task workspace.
* The right side is the **Tasks Agent**, where you can describe tasks to create, break larger work into smaller tasks, or request changes to existing tasks.
## Task workspace
[Section titled “Task workspace”](#task-workspace)
Use the top bar to switch views, search, filter, and create new tasks.
| Control | Description |
| ---------------------- | ------------------------------------------------------------------------ |
| **Search** | Filter tasks by typing into the search field. |
| **Filter** | Filter by status, priority, assignee, or tag. |
| **Sort** | Sort by manual order, priority, due date, created date, or updated date. |
| **Sort direction** | Reverse the current sort order. |
| **Keyboard shortcuts** | Open the shortcuts reference for the Tasks page. |
| **Add Task** | Open the full task creation dialog. |
When filters are active, Draftbit shows removable filter pills below the toolbar so you can clear one filter at a time or reset all of them at once.
## Views
[Section titled “Views”](#views)
### Board view
[Section titled “Board view”](#board-view)
Board view organizes tasks into these working columns:
* **Backlog**
* **Todo**
* **In Progress**
* **In Review**
* **Done**
You can drag tasks between columns to move work forward. If you are using a non-manual sort, drag and drop still helps you move a task into a different status while the active sort controls the order inside each column.
Each column also supports quick task creation. Use the plus button to start a new task, then press **Enter** to create it immediately or **Shift + Enter** to open the full dialog with the title pre-filled.
### List view
[Section titled “List view”](#list-view)
List view is better when you want to scan metadata or update several tasks quickly.
| Column | Description |
| ------------- | ------------------------------------------------------------------------- |
| **Task** | Shows the short task ID and whether the task already has an agent thread. |
| **Title** | Shows the task title and visible tags. |
| **Status** | Update the task status inline. |
| **Priority** | Update the task priority inline. |
| **Assignees** | Shows the assigned team members. |
| **Due Date** | Set or update the due date inline. |
| **Actions** | Start work, open the task, or use the task menu for more actions. |
List view also supports multi-select. Select one or more tasks to apply bulk actions for status, priority, or deletion.
## Create and organize tasks
[Section titled “Create and organize tasks”](#create-and-organize-tasks)
You can create tasks in several ways:
* Click **Add Task** to open the full task dialog.
* Create a task inline from a board column.
* Press **N** anywhere on the Tasks page.
* Ask the **Tasks Agent** to create tasks for you.

The full task dialog lets you set:
| Field | Description |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Title** | A short, descriptive name for the task. |
| **Description** | A longer description written in the markdown editor. Use **Draft with AI** to generate a starting description from the title. |
| **Status** | The current state of the task. Options are **Backlog**, **Todo**, **In Progress**, **In Review**, **Done**, and **Cancelled**. |
| **Priority** | How important the task is. Options are **Low**, **Medium**, **High**, and **Urgent**. |
| **Assignees** | The team members responsible for the task. |
| **Tags** | Labels for grouping or filtering related tasks. |
| **Due date** | An optional date the task should be completed by. |
## Start work with an agent
[Section titled “Start work with an agent”](#start-work-with-an-agent)
Tasks are designed to move cleanly from planning into execution.
From the list view, board view, or task detail page, you can start a task in two ways:
* **Start** opens the app with the selected task attached so you can work in context.
* **Start In Background** launches the task with an agent without taking you away from the Tasks page.
Once a task has an agent thread, the start controls change to **View thread**.
If another thread is already running in the same app, Draftbit disables new start actions until that run finishes.
## Task details
[Section titled “Task details”](#task-details)
Open any task to see the full detail page.
From there, you can:
* Edit the title inline.
* Update status, priority, assignees, tags, and due date.
* Write or revise the description in the markdown editor.
* Use **Draft with AI** to generate a description when you need a starting point.
* Add comments and review agent comments in the same timeline.
* Open the linked agent thread when one exists.
* Delete the task if it is no longer needed.
Use **J** and **K** on the detail page to move to the next or previous task.
## Keyboard shortcuts
[Section titled “Keyboard shortcuts”](#keyboard-shortcuts)
| Shortcut | Description |
| ----------------- | ---------------------------------------------------------- |
| **N** | Create a new task |
| **L** | Switch to list view |
| **B** | Switch to board view |
| **?** | Open the keyboard shortcuts reference |
| **Enter** | Quick create a task from the inline board composer |
| **Shift + Enter** | Open the full create dialog from the inline board composer |
| **1** to **4** | Set task priority from the task context menu |
| **J** | Open the next task from task detail view |
| **K** | Open the previous task from task detail view |
## Tasks Agent
[Section titled “Tasks Agent”](#tasks-agent)
The right-side Tasks Agent panel is useful when you want help shaping work before you start implementation.
Use it to:
* create a first set of tasks from a feature idea
* break a larger feature into smaller tasks
* ask for follow-up task changes as the project evolves
This keeps planning and execution close together. You can define work on the right, organize it on the left, and start the next task when you are ready.
# Themes
> Customize your app's shared theme colors and typography
> Switch to Themes view using the  icon in the [main menu](/intro/building-with-draftbit/builder-overview#main-menu).
The Themes page is where you define the shared visual foundation for your app. Use it to manage app-wide theme values like colors and typography, then review the result directly in the Builder preview as you make changes.

## Theme Modes
[Section titled “Theme Modes”](#theme-modes)
Draftbit lets you configure separate values for your app’s light and dark themes.
* **Light Theme** contains the values used when your app is shown in light mode.
* **Dark Theme** contains the values used when your app is shown in dark mode.
Switch between these modes at the top of the page to edit each theme independently.
Tip
If your app supports both light and dark appearance, review both themes before publishing so text, surfaces, and status colors remain readable in each mode.
## Color Tokens
[Section titled “Color Tokens”](#color-tokens)
The Colors section groups related theme tokens so you can update your palette systematically instead of changing individual components one by one.
| Group | Purpose |
| ------------------ | ---------------------------------------------------------------------- |
| **Base** | Core background and foreground text colors used throughout the app. |
| **Primary** | Your main brand colors for prominent actions and emphasis. |
| **Secondary** | Supporting accent colors for secondary UI treatments. |
| **Tertiary** | Additional accent colors for extended palette needs. |
| **Card & Popover** | Surface colors for layered UI such as cards, sheets, and popovers. |
| **Muted & Accent** | Subtle supporting colors for less prominent UI and accent treatments. |
| **Semantic** | Status and feedback colors for states like success, warning, or error. |
### Editing a Token Group
[Section titled “Editing a Token Group”](#editing-a-token-group)
Expand a color group to reveal the individual tokens inside it. For example, the **Base** group includes values like **Background** and **Foreground**. Update those values to change the shared colors used across your app.
The Themes editor supports token picking from your palette and custom one-off values. Apps imported from Draftbit Classic can also edit their imported v1 themes and palettes here. When you update a palette token, every theme value that references that token updates with it.
## Typography
[Section titled “Typography”](#typography)
Alongside colors, the Themes page is also where you manage shared typography settings for the active theme. These theme-level values help keep text treatment consistent across screens instead of styling each text element from scratch.
Use the Typography tab to edit font families, sizes, weights, and spacing. The font picker includes Google Fonts with live previews and wires the selected font into the right Expo or web configuration for your app.
## Themes vs Component Styles
[Section titled “Themes vs Component Styles”](#themes-vs-component-styles)
The Themes page controls shared, app-level design values. For one-off adjustments on a specific element, use the [Styles tab](/features/ai-app-builder#styles) in the Builder.
A practical way to work is:
1. Set your core palette and typography in Themes.
2. Build screens in the [AI App Builder](/features/ai-app-builder).
3. Fine-tune individual components in the Styles tab only when needed.
This keeps your app visually consistent while still giving you flexibility for screen-specific design decisions.
# Overview
> An introduction to helpful guides for Draftbit
Understanding Navigation
Learn best practices for setting up navigation in your app
[Read the guide →](/guides/understanding-navigation)
Adding Packages
Use Build Config or AI Chat to find, install, and manage packages in your app
[Read the guide →](/guides/adding-packages-with-ai-chat)
Setting Up Android Push Notifications with Expo
Send push notifications on Android using Expo’s push service, Firebase Cloud Messaging (FCM V1), and the AI Agent
[Read the guide →](/guides/setting-up-android-push-notifications)
Setting Up iOS Push Notifications with Expo
Send push notifications on iOS using Expo’s push service, Apple Push Notification service (APNs), and the AI Agent
[Read the guide →](/guides/setting-up-ios-push-notifications)
Connecting to GitHub
Export and sync your app to a GitHub repository so you can version, collaborate on, and extend your code
[Read the guide →](/guides/connecting-to-github)
# Adding Packages
> Use Build Config or AI Chat to add, explore, and manage packages in your Draftbit app
When you build an app with Draftbit, you’re really building an **Expo React Native** app under the hood. That means you can use thousands of open‑source **packages** (pre‑built pieces of code) to add features like icons, maps, analytics, payments, and more—without starting from scratch.
You can manage packages directly from [Build Config](/features/build-config#packages), or you can ask the AI in AI Chat to add and configure packages for you. Use Build Config when you know the dependency you want to add, edit, or remove. Use AI Chat when you want help choosing a package, checking Expo compatibility, or wiring the package into your app.
## What is a package?
[Section titled “What is a package?”](#what-is-a-package)
A **package** is a reusable bundle of code that someone else has written and shared. You install it once and then use it across your app—similar to adding a plugin or extension in other tools.
Some common types of packages:
* **UI & components**: Buttons, icons, date pickers, carousels, maps.
* **Data & APIs**: Tools for calling APIs, managing data, caching, or real‑time updates.
* **Auth & security**: Login flows, OAuth, and other authentication helpers.
* **Expo & device features**: Camera, location, push notifications, file system, etc.
* **Utilities**: Helpers for dates, formatting, validation, and more.
Under the hood, Draftbit uses **NPM packages** (from the Node.js ecosystem) and, because apps are built on **Expo**, many of the best options are **Expo packages** maintained by the Expo team.
## Expo packages vs. other packages
[Section titled “Expo packages vs. other packages”](#expo-packages-vs-other-packages)
Because Draftbit apps run on **Expo React Native**, it’s usually safest to prefer:
* **Expo‑maintained packages** (they often start with `expo-`, like `expo-camera`).
* **React Native packages that are known to work well with Expo**.
These packages:
* Are more likely to “just work” with minimal configuration.
* Are kept up‑to‑date with the latest Expo SDKs.
* Often have simpler installation and setup steps.
Packages that require heavy custom native code or complex build steps may not be a good fit. If you’re unsure, you can ask the AI to **check compatibility with Expo** before installing.
Auto‑linking or Expo plugins required
Most modern React Native/Expo packages support **auto‑linking** (they register themselves automatically) or provide an **Expo config plugin** that Expo uses to configure the native project for you.
When you’re considering a package, ask the AI to help you check:
* Does it support **auto‑linking**?
* Does it have an **Expo config plugin**?
If the answer to **both** is “no”, it’s usually **not a good fit** for a Draftbit/Expo app and you should look for an alternative that does.
## Adding a package directly
[Section titled “Adding a package directly”](#adding-a-package-directly)
Open [Build Config](/features/build-config#packages) and use the **Packages** tab to view, add, edit, or remove npm dependencies in your app.

Packages are split into two sections:
| Section | Use for |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Standard** | Runtime dependencies your app needs when it runs, such as UI libraries, API clients, navigation helpers, camera modules, or storage clients. |
| **Development** | Development-only tooling that is not shipped with production app bundles. |
Most app features should use **Standard** packages. Use **Development** only when the package is needed for build tooling, code generation, linting, testing, or another development-only task.
To add a package directly:
1. **Open Build Config**
In the Builder navigation, open **Build Config** and select the **Packages** tab.
2. **Choose the package section**
Use **Standard** for app runtime dependencies. Use **Development** only for development tooling.
3. **Add the package name and version**
Add a row with the npm package name, such as `expo-camera`, and a version range, such as `~16.0.0` or `^1.2.3`.
4. **Save and test**
After the package is saved and installed, test the app preview. If the package includes native code, create fresh native preview builds before testing on iOS or Android.
You can also edit an existing package version inline or remove a package from the same table.
After adding or removing packages that include native code, create new native preview builds before testing on iOS or Android simulators.
Ask AI before changing native packages
If you are not sure whether a package includes native code or requires Expo configuration, ask AI Chat to check before installing it.
## Asking AI to add a specific package
[Section titled “Asking AI to add a specific package”](#asking-ai-to-add-a-specific-package)
You can tell the AI exactly which package to install. The AI can update Build Config and then add any setup code the package needs. In the [AI Chat](/features/ai-app-builder#ai-chat), try prompts like:
> “Install the `@react-navigation/native` package and set it up for an Expo React Native app.”
> “Add the `expo-camera` package so I can take photos in my app.”
> “Install `@tanstack/react-query` and set it up for managing API data in my app.”
The AI will:
1. **Add the package to Build Config**
It updates your app’s package dependencies so the package is installed.
2. **Set up configuration**
For many packages, the AI can add setup code, providers, config plugins, permissions, or configuration files so it’s ready to use.
3. **Show you how to use it**
You can then ask the AI for examples of how to use the new package on a screen or inside the [Code Editor](/features/code-editor).
If you don’t know the exact package name, that’s okay—just describe what you want to do.
## Getting advice on packages to use
[Section titled “Getting advice on packages to use”](#getting-advice-on-packages-to-use)
You can also ask the AI to **research and recommend a package** for what you’re trying to build. For example:
> “I want to add a calendar picker to my app. Please suggest a good Expo‑compatible package, explain the tradeoffs, and then install the one you recommend.”
> “I need charts for analytics. Find a React Native or Expo‑compatible charting package and set it up for me.”
> “Help me choose a package for handling dates and time zones in an Expo app. Compare at least two options.”
Behind the scenes, the AI can look at:
* **[reactnative.directory](https://reactnative.directory)** – a curated directory of React Native libraries.
* **[npmjs.com](https://www.npmjs.com)** – the main registry where packages are published.
* **GitHub** – where many packages are hosted and documented.
You don’t need to browse these sites yourself, but it can be helpful if you want to see screenshots, issues, or release history. You can always ask:
> “Can you share the GitHub link and main documentation page for the package you just installed?”
## Different package types
[Section titled “Different package types”](#different-package-types)
If a package feels confusing or “too developer‑y”, ask the AI to explain it like a feature:
> “Explain what the `expo-secure-store` package does in simple terms and how it might help my app.”
> “What does `@react-native-async-storage/async-storage` do, and when should I use it?”
Useful ways to ask:
* **“What problem does this package solve?”**
* **“Is this the right package for Expo?”**
* **“What are the pros and cons compared to another option?”**
The AI can also point out when a package:
* Is old or unmaintained.
* Doesn’t work well with the latest Expo SDK.
* Requires extra native configuration that might not be ideal in Draftbit.
## Using an installed package
[Section titled “Using an installed package”](#using-an-installed-package)
Once the AI has installed and set up a package, you can ask it to **wire it into your app**. Examples:
* “Use the `expo-camera` package to add a Take Photo button on my Profile screen.”
* “Use the charting package you installed to show a simple line chart on the Analytics screen.”
* “Use the date library you added to format dates in my Orders list.”
You can also ask the AI to:
* Add example code to the [Code Editor](/features/code-editor).
* Create new screens that use the package.
* Refactor existing screens to use the package instead of hard‑coded logic.
Native vs web behavior
Some packages are designed primarily for **native mobile** and may behave differently (or not work at all) on the **web**. For example, audio or media packages like React Native Track Player can work great in native previews but require **platform‑specific handling** on web (such as falling back to a web audio or video solution).
If you’re targeting web as well as iOS/Android, ask the AI:
* “Does this package support web?”
* “If not, can you add a web‑specific fallback that uses a web‑friendly library or browser API instead?”
## Good prompts for managing packages
[Section titled “Good prompts for managing packages”](#good-prompts-for-managing-packages)
Here are some ready‑to‑use prompts you can copy into AI Chat:
* “Install a popular, well‑maintained Expo‑compatible package for showing icons and set it up. Then update my app to use it on the Home screen.”
* “Find a React Native package for displaying maps that works with Expo, explain your choice, then install and set it up.”
* “List the main packages you’ve installed in my project so far and briefly describe what each one does.”
* “I want to add analytics. Recommend an Expo‑friendly analytics provider, explain the tradeoffs (pricing, features, complexity), and install the package you think is best.”
* “Check whether the `react-native-xyz` package is compatible with Expo and, if not, suggest an alternative that is.”
## Best practices
[Section titled “Best practices”](#best-practices)
* **Prefer Expo‑compatible packages**: Ask the AI directly: “Is this package recommended for Expo?”.
* **Use Build Config as the source of truth**: Check the Packages tab when you want to see what is installed or remove a dependency.
* **Install one thing at a time**: It’s easier to test changes and undo them if needed.
* **Rebuild native previews after native package changes**: Web preview can update quickly, but iOS and Android native previews need a new native build after native dependency changes.
* **Ask for a summary**: After working with packages for a while, ask: “Summarize all the main packages we’ve added and what they’re used for.”
* **Keep an eye on docs**: When in doubt, ask the AI to show you the official docs or GitHub page.
* **Use AI for cleanup**: If something feels messy or unused, ask: “Are there any packages or imports we can remove safely?”
With AI Chat, you can treat packages like **building blocks you ask for by name or by need**—the AI helps you choose, install, and use them so you can stay focused on your app’s experience.
# Connecting to GitHub
> Export and sync your Draftbit AI Builder app to a GitHub repository so you can version, collaborate on, and extend your code with your team.
Draftbit’s GitHub Export lets you push your app’s generated source code straight to a repository you own, so it lives alongside the rest of your engineering workflow. The GitHub Export integration commits your app’s generated source code (React Native, Astro, Vite, or a backend variant, depending on your app) to a repository and branch you choose, whenever you trigger an export.
Why connect to GitHub?
Connecting to GitHub gives you version control (each export that changes your generated code becomes a real commit with a full history — an export with no changes doesn’t create an empty commit), team collaboration (engineers can pull the code and open pull requests using tools they already use), the ability to extend beyond the builder (add custom packages or native modules in your own IDE), and a foundation for CI/CD (wire up your own build, test, and deployment pipelines around the exported code).
## Before you start
[Section titled “Before you start”](#before-you-start)
You’ll need:
* A Draftbit app you’d like to connect, on a workspace with the **Pro** plan or higher — GitHub Export is a Pro-tier feature.
* A GitHub account with access to the destination repository.
* Permission to create a personal access token on that GitHub account (fine-grained tokens are recommended).
* An existing GitHub repository (empty or not) that you have push access to.
Tip
Draftbit accepts either a full repository URL (`https://github.com/org/repo`) or a short `org/repo` slug in the setup form — both are validated before you save.
## Set up the connection
[Section titled “Set up the connection”](#set-up-the-connection)
1. Open your app in the AI Builder at [next.draftbit.com](https://next.draftbit.com).
2. Find the GitHub Export destination. There are two entry points:
* **Export menu** — click **Export** in the top toolbar, then select **Setup** next to the GitHub entry.
* **Publish Destinations** — open **Publishing → Publish Destinations**, alongside App Store Connect, Google Play Console, and Custom Domain.
 
From the Publishing page, click the **Github Export** card to open the **Github Export Integration** dialog, shown below.

3. Create a GitHub personal access token. Draftbit authenticates to your repository with a token scoped to **Contents: Read and Write** on the target repo. If your app’s generated code includes a `.github/workflows` directory, also grant **Workflows: Read and write** — otherwise the export will fail trying to write those files, even to a branch that doesn’t have them yet.
1. In the setup form, click the **here** link under the token field — this opens GitHub’s fine-grained token creation page.
2. Give the token a recognizable name, for example `draftbit-export`.
3. Under **Repository access**, select **Only select repositories** and choose your target repo.
4. Under **Permissions → Repository permissions**, set **Contents** to **Read and write** (and **Workflows** to **Read and write** if your app’s generated code includes a `.github/workflows` directory).
5. Click **Generate token**, then copy it immediately — GitHub only shows it once.
Treat this token like a password
Anyone with it can push code to your repository. Store it in a password manager, not in chat, email, or a plain-text file.
4. Fill in the GitHub Export Integration form with your repository URL, branch name, and access token, then click **Check Access**. This confirms Draftbit can reach and read the repository — it only needs the repository URL and access token to enable, so you can check access before entering a branch name. It doesn’t push anything or confirm write access, so double-check the token was created with **Contents: Read and Write** as described above.
5. Click **Save Configuration** to store your repository, branch, and token. This saves the connection but doesn’t push any code by itself.
6. To push your code, open the **Export** menu in the top toolbar and click **Commit** next to the GitHub entry — this opens the export dialog. In the dialog, select **Github** from the **Destination** dropdown (it resets to blank each time the dialog opens, and **Export** stays disabled until a destination is chosen), then click **Export** to push your code to the configured branch. Larger apps can take a few minutes to push.
Exports overwrite the target branch
Each export replaces the entire contents of the target branch (aside from the `.git` directory) with your app’s freshly generated code. Anything committed directly to that branch outside of Draftbit will be lost on the next export — use a dedicated branch you don’t hand-edit, and merge from it deliberately.
## Field reference
[Section titled “Field reference”](#field-reference)
| Field | What it’s for | Example |
| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- |
| **GitHub Repository URL** (required) | The repository your exported code will be pushed to. A full URL or an `org/repo` slug both work — Draftbit validates it before saving. | `https://github.com/username/repository` |
| **GitHub Branch Name** (required) | The branch that receives each export. Use an existing branch, or a new name Draftbit can create on first push. Not required to check access, only to save. | `main` or `draftbit-export` |
| **GitHub Access Token** (required) | A personal access token with `Contents: Read and Write` permission on the target repository. Entered as a masked field. | `github_pat_••••••••` |
Validation errors for missing fields appear inline as soon as you start filling in the form. **Check Access** only needs the repository URL and access token to enable — the branch name isn’t required until you save. **Save Configuration** stays disabled until all three fields are valid:

## Best practices
[Section titled “Best practices”](#best-practices)
* **Scope your token tightly.** Use a fine-grained token limited to the one repository you’re exporting to, with `Contents: Read and write` enabled (plus `Workflows: Read and write` if your app’s generated code includes a `.github/workflows` directory) — avoid classic tokens with broad, account-wide access.
* **Use a dedicated branch you don’t hand-edit.** Every export overwrites the entire contents of the target branch. Exporting to a branch like `draftbit-export` instead of `main` keeps generated pushes from clobbering code your team edits by hand.
* **Rotate tokens periodically.** Set an expiration when you create the token and regenerate it periodically. Revoke it immediately from GitHub if it’s ever exposed.
* **Verify before you save.** Click **Check Access** first to confirm Draftbit can reach and read the repository — it only needs the repository URL and token, so you can do this before filling in a branch name. It doesn’t verify write access, so also double-check the token has `Contents: Read and Write` before exporting.
## Troubleshooting
[Section titled “Troubleshooting”](#troubleshooting)
| You see this | Here’s what to do |
| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ”Branch name is required” / “GitHub access token is required” | These inline messages appear as soon as you start filling in the form with a field still empty. **Save Configuration** stays disabled until all three fields are valid. **Check Access** only requires the repository URL and access token, so it can be used before a branch name is entered. |
| Check Access fails | Confirm the token hasn’t expired, that it grants `Contents: Read and Write` on the exact repository entered, and that the repository URL or slug is spelled correctly. Note that **Check Access** only recognizes a token typed into the field during the current session — if you’re reopening the dialog to update just the repository or branch, you’ll need to re-enter the token as well before **Check Access** will re-enable. |
| Repository URL rejected | Use either a full HTTPS URL (`https://github.com/org/repo`) or an `org/repo` slug, with or without a trailing `.git` — other formats (like SSH URLs) aren’t accepted. |
| Export seems stuck | Larger apps can take a few minutes to push. GitHub exports don’t appear on the **Activity** tab — check your repository’s commit history on the target branch to confirm the push completed. |
## FAQ
[Section titled “FAQ”](#faq)
**Can I reconfigure the connection later?** Yes — reopen the GitHub Export card from Publish Destinations at any time to update the repository, branch, or token. Note that **Check Access** only recognizes a token entered during that session, so if you’re only updating the repository or branch, you’ll need to re-enter the token as well to re-verify access.
**Does this replace the ZIP export?** No, they’re independent. **Download Project** gives you a one-time ZIP; **GitHub Export** pushes commits to a live repository each time you export.
**What exactly gets exported?** Your app’s generated source code — the same codebase you’d get from a manual ZIP export — pushed as a commit to the branch you configured, unless nothing has changed since your last export, in which case no new commit is created. Each export replaces the branch’s existing contents (aside from `.git`), so use a dedicated branch as described above.
## Related
[Section titled “Related”](#related)
* [Publishing overview](/features/publishing/)
# Setting Up Android Push Notifications with Expo
> Send push notifications on Android using Expo's push service, Firebase Cloud Messaging (FCM V1), and the AI Agent
Push notifications let your app reach people even when it’s closed. There’s more than one way to send them—you could call Firebase Cloud Messaging directly, or use a third-party service like OneSignal—but this guide covers **Expo’s push service**, the most common path. On Android, Expo delivers through Google’s **Firebase Cloud Messaging (FCM V1)**—the current version of Firebase’s messaging API. Most of this guide is code the AI Agent writes for you; the last two steps happen once in a terminal, because they involve an interactive credential setup that can’t be run through the Builder or the AI Agent.
Before you begin, make sure you have:
* Your app in Draftbit with the screen(s) you want notifications on
* Access to the Google account you’ll use for Firebase
* A free [Expo account](https://expo.dev/signup)—step 2 covers creating one
* A few minutes at a terminal with your project exported (steps 6–7)
## 1. Design the UI, then ask the AI Agent to wire it up
[Section titled “1. Design the UI, then ask the AI Agent to wire it up”](#1-design-the-ui-then-ask-the-ai-agent-to-wire-it-up)
Add the permission prompt, a notifications toggle in settings, or wherever the in-app banner should land. Once the screens exist, ask the AI Agent in [AI Chat](/features/ai-app-builder#ai-chat) to connect them using `expo-notifications`, the library that talks to Android’s notification system on your behalf:
> “Add push notification support using expo-notifications. Request permission the first time the user opens the app, register for an Expo push token once permission is granted, and store that token against the signed-in user. Add a listener that shows an in-app banner when a notification arrives while the app is open, and navigates to the relevant screen when the user taps a notification.”
## 2. Create an Expo account
[Section titled “2. Create an Expo account”](#2-create-an-expo-account)
Expo is the service that actually delivers the push—your app sends notifications through it rather than talking to Android directly. Skip this if you already have an account.
1. Go to [expo.dev/signup](https://expo.dev/signup) and sign up with an email or GitHub.
2. Verify your email from the link Expo sends you.
3. Note your **username**—you’ll need it exactly as it appears on your Expo profile in step 5.
## 3. Get your Firebase files
[Section titled “3. Get your Firebase files”](#3-get-your-firebase-files)
Two different files come out of Firebase here, and they’re used in two different places: `google-services.json` goes into your project, while the service account key never does—it’s uploaded straight to Expo’s servers in step 7.
### Register the Android app and download google-services.json
[Section titled “Register the Android app and download google-services.json”](#register-the-android-app-and-download-google-servicesjson)
1. Open the [Firebase console](https://console.firebase.google.com) and select your project, or create one if this app doesn’t have one yet.
2. Click **Add app**.

3. Select the **Android** platform.

4. Enter your app’s package name—it needs to match the `package` value in your app’s `app.config`—and click **Register app**.

5. Click **Download google-services.json**, then **Continue to console**.

Ignore the “app” folder shown here
This step is Firebase’s generic instructions for a native Android Studio project, where the file goes into that project’s own `app` module folder. That’s not the same `app` as anything in your Draftbit project—for a Draftbit app, `google-services.json` goes at the top-level project root instead, which is what step 4 below covers.


### Generate the FCM V1 service account key
[Section titled “Generate the FCM V1 service account key”](#generate-the-fcm-v1-service-account-key)
1. Go to **Project Settings → Service accounts**—it’s a separate tab from Cloud Messaging, not nested under it.
2. Click **Generate new private key**. This downloads the FCM V1 service account key—set it aside for step 7.

Keep the service account key private
The service account key authenticates as your app. Don’t post it anywhere public. Unlike `google-services.json`, it doesn’t go into your project—the only place it needs to live is Expo’s credential store, in step 7.
## 4. Add google-services.json to your project
[Section titled “4. Add google-services.json to your project”](#4-add-google-servicesjson-to-your-project)
Upload `google-services.json` to your project’s assets, then ask the AI Agent to move it where the build expects it:
> “I uploaded google-services.json to the assets folder. Move it to the project root and tell me the exact filename so I can reference it later.”
## 5. Point the project at your Expo account
[Section titled “5. Point the project at your Expo account”](#5-point-the-project-at-your-expo-account)
The build needs to know which Expo account owns it. Ask the AI Agent to set the `owner` field to your Expo username from step 2:
> “Set the owner field in app.config to my Expo username: your-expo-username.”
## 6. Run a first EAS build for Android
[Section titled “6. Run a first EAS build for Android”](#6-run-a-first-eas-build-for-android)
Expo can’t manage push credentials for a project until it has at least one Android build configured—that’s what generates `eas.json` and links your app’s package name to your Expo account. The Builder can’t trigger this part: export your code and run it once from a real terminal.
1. Export your project from Draftbit.
2. Open a terminal in the exported folder and log in: `eas login`
3. Create and link the EAS project to your account: `eas init`
4. Generate the build config: `eas build:configure -p android`—this writes `eas.json`.
5. Kick off the build: `eas build -p android --profile development`
```bash
eas login
eas init
eas build:configure -p android
# ✔ Generated eas.json
eas build -p android --profile development
```
Why this order
Skipping straight to credentials fails with a missing-config error—`eas.json` is what the credentials step reads from, and it only exists after this one.
## 7. Upload the FCM V1 key to Expo’s credential store
[Section titled “7. Upload the FCM V1 key to Expo’s credential store”](#7-upload-the-fcm-v1-key-to-expos-credential-store)
There are two ways to do this—pick whichever you prefer.
### Upload from the Expo dashboard
[Section titled “Upload from the Expo dashboard”](#upload-from-the-expo-dashboard)
No terminal needed for this option.
1. Open your project on [expo.dev](https://expo.dev), go to **Credentials**, and select your Android application identifier.

2. Under **Service credentials**, add the FCM V1 service account key using the file from step 3.

### Or, use the terminal
[Section titled “Or, use the terminal”](#or-use-the-terminal)
This runs as a menu-driven prompt, so stay in the same exported project and terminal from step 6—it isn’t something the Builder or the AI Agent can click through remotely.
1. Start the credentials manager: `eas credentials -p android`
2. Pick any build profile when asked—it doesn’t affect the outcome.
3. Navigate: **Google Service Account → Manage your Google Service Account Key for Push Notifications (FCM V1) → Set up a Google Service Account Key for Push Notifications (FCM V1)**.
4. If it asks whether to reuse an existing key, choose **Upload a new service account key**.
5. Paste the full path to the service account key file from step 3 and hit enter.
```bash
eas credentials -p android
# › Google Service Account
# › Manage your Google Service Account Key for Push Notifications (FCM V1)
# › Set up a Google Service Account Key for Push Notifications (FCM V1)
# ? Path to Google Service Account file: ~/Downloads/your-project-firebase-adminsdk.json
# ✔ Google Service Account Key assigned for FCM V1
```
You’re done with this step once you see `Google Service Account Key assigned … for FCM V1` printed in the terminal.
## 8. Publish again
[Section titled “8. Publish again”](#8-publish-again)
The credential now lives with Expo, not in your exported copy—go back to Draftbit and publish once more so the live build picks it up. From here, a push sent through Expo’s push service reaches real Android devices.
## Troubleshooting
[Section titled “Troubleshooting”](#troubleshooting)
#### ”Missing config” error when running `eas credentials`
[Section titled “”Missing config” error when running eas credentials”](#missing-config-error-when-running-eas-credentials)
You need at least one Android build configured before credentials can be managed. Run `eas build:configure -p android` (step 6) first.
#### `eas credentials` hangs or shows no prompts
[Section titled “eas credentials hangs or shows no prompts”](#eas-credentials-hangs-or-shows-no-prompts)
It’s an interactive-only command and needs a real terminal—it won’t work over a non-interactive shell, CI runner, or the Builder’s own terminal-like surfaces. Run it locally on your machine.
#### Notifications aren’t arriving on a device
[Section titled “Notifications aren’t arriving on a device”](#notifications-arent-arriving-on-a-device)
* Confirm the Google Service Account Key shows as assigned when you re-run `eas credentials -p android`.
* Make sure the device has notification permissions granted and a push token was actually registered—ask the AI Agent to log the token after registration.
* Rebuild and republish after any credential or `app.config` change; existing installs won’t pick up new credentials until the next build.
# Setting Up iOS Push Notifications with Expo
> Send push notifications on iOS using Expo's push service, Apple Push Notification service (APNs), and the AI Agent
Push notifications let your app reach people even when it’s closed. There’s more than one way to send them, but this guide covers **Expo’s push service**, the most common path. On iOS, Expo delivers through **Apple Push Notification service (APNs)**. Most of this guide is code the AI Agent writes for you; the last two steps happen once in a terminal, because they involve an interactive credential setup that can’t be run through the Builder or the AI Agent.
Before you begin, make sure you have:
* Your app in Draftbit with the screen(s) you want notifications on
* An active [Apple Developer Program](https://developer.apple.com/programs/) membership
* A Bundle ID created for your app (see [iOS Publishing (Cloud)](/features/publishing/one-click-publishing/ios-publishing))
* A free [Expo account](https://expo.dev/signup)—step 2 covers creating one
* A few minutes at a terminal with your project exported (steps 6–7)
## 1. Design the UI, then ask the AI Agent to wire it up
[Section titled “1. Design the UI, then ask the AI Agent to wire it up”](#1-design-the-ui-then-ask-the-ai-agent-to-wire-it-up)
Add the permission prompt, a notifications toggle in settings, or wherever the in-app banner should land. Once the screens exist, ask the AI Agent in [AI Chat](/features/ai-app-builder#ai-chat) to connect them using `expo-notifications`, the library that talks to iOS’s notification system on your behalf:
> “Add push notification support using expo-notifications. Request permission the first time the user opens the app, register for an Expo push token once permission is granted, and store that token against the signed-in user. Add a listener that shows an in-app banner when a notification arrives while the app is open, and navigates to the relevant screen when the user taps a notification.”
## 2. Create an Expo account
[Section titled “2. Create an Expo account”](#2-create-an-expo-account)
Expo is the service that actually delivers the push—your app sends notifications through it rather than talking to Apple directly. Skip this if you already have an account, including if you’ve already set this up for Android.
1. Go to [expo.dev/signup](https://expo.dev/signup) and sign up with an email or GitHub.
2. Verify your email from the link Expo sends you.
3. Note your **username**—you’ll need it exactly as it appears on your Expo profile in step 4.
## 3. Enable the Push Notifications capability
[Section titled “3. Enable the Push Notifications capability”](#3-enable-the-push-notifications-capability)
This step must be done manually in the Apple Developer portal—there’s no automatic/terminal-based alternative for this part.
1. Log in to your [Apple Developer](https://developer.apple.com/account) account and select **Identifiers** from **Certificates, IDs & Profiles**.
2. Find and select the **Bundle ID** you created for your app.
3. Scroll to the **Capabilities** list and check the box next to **Push Notifications**.
4. Click **Save**.
## 4. Generate an APNs Auth Key
[Section titled “4. Generate an APNs Auth Key”](#4-generate-an-apns-auth-key)
You have two options here—you don’t need to do both.
### Option A: Let the build process generate it automatically (recommended)
[Section titled “Option A: Let the build process generate it automatically (recommended)”](#option-a-let-the-build-process-generate-it-automatically-recommended)
When you run your local build (see [Run a first EAS build for iOS](#6-run-a-first-eas-build-for-ios) below), the build tool will prompt you to set up push notifications and can generate the APNs key for you automatically, as long as you sign in with your Apple Developer account when prompted. This is the simpler path for most people.
### Option B: Generate it manually yourself first
[Section titled “Option B: Generate it manually yourself first”](#option-b-generate-it-manually-yourself-first)
If you’d rather generate the key yourself ahead of time:
1. Log in to your [Apple Developer](https://developer.apple.com/account) account, select **Certificates, IDs & Profiles**, then **Keys**.
2. Click the **Add button (+)**.
3. Enter a name for the key (e.g. “Draftbit Push Notifications”).
4. Check the box for **Apple Push Notifications service (APNs)**.
5. Click **Continue**, then **Register**.
6. On the confirmation page, click **Download** to save your `.p8` key file.
This file can only be downloaded once
Store it somewhere safe—if you lose it, you’ll need to generate a new key.
7. Note down the **Key ID** shown on this page, and your **Team ID** (found under **Membership Details**). You’ll provide these along with the `.p8` file during the local build if you choose not to let it generate automatically.
## 5. Point the project at your Expo account
[Section titled “5. Point the project at your Expo account”](#5-point-the-project-at-your-expo-account)
The build needs to know which Expo account owns it. Open `app.config.js` in your exported project and add (or update) the `owner` field with your Expo username from step 2:
```js
module.exports = {
owner: "your-expo-username",
// ...your existing config
};
```
If you’re using the AI Agent to make changes locally, you can also just ask it:
> “Set the owner field in app.config to my Expo username: your-expo-username.”
## 6. Run a first EAS build for iOS
[Section titled “6. Run a first EAS build for iOS”](#6-run-a-first-eas-build-for-ios)
Expo can’t manage push credentials for a project until it has at least one iOS build configured. The Builder can’t trigger this part: export your code and run it once from a real terminal.
1. Export your project from Draftbit.
2. Open a terminal in the exported folder and install dependencies: `yarn`
3. Install the EAS CLI if you don’t already have it: `npm i -g eas-cli`
4. Log in to Expo: `eas login`
5. Create and link the EAS project to your account: `eas init`
6. Generate the build config: `eas build:configure -p ios`—this writes `eas.json`.
7. Kick off the build: `eas build -p ios --profile development`
```bash
yarn
npm i -g eas-cli
eas login
eas init
eas build:configure -p ios
# ✔ Generated eas.json
eas build -p ios --profile development
```
Why `--profile development`
This is one of the default build profiles EAS Build creates for you—it’s not related to your app’s runtime environment or config. It’s used here only because this build’s real purpose is to walk through the one-time interactive credential setup below; a development build compiles faster than a full release build. The credential setup works the same way no matter which profile you pick, and the actual App Store build still happens later, through Draftbit’s normal publishing pipeline.
This prompts you to set up your Push Notifications key—either automatically (Option A above) or using the `.p8` file, Key ID, and Team ID you noted down earlier (Option B above).
If you see a dynamic app configuration warning
Draftbit’s exported projects use `app.config.js` instead of a plain `app.json`, and EAS CLI can’t automatically write the Project ID into that kind of file. If the build stops with a message like:
```plaintext
Warning: Your project uses dynamic app configuration, and the EAS project ID
can't automatically be added to it.
To complete the setup process, set "extra.eas.projectId" in your app.config.js
...
Error: build command failed.
```
copy the Project ID from that message (or from the “Existing/Linked project” line earlier in the terminal output—see [Add your Expo Project ID to Draftbit](#7-add-your-expo-project-id-to-draftbit) below), then add it to `app.config.js` yourself:
1. Open `app.config.js` in your exported project in any text editor.
2. Add (or update) an `extra.eas.projectId` field at the root of the exported object:
```js
module.exports = {
// ...your existing config
extra: {
eas: {
projectId: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
},
},
};
```
If an `extra` field already exists, add `eas: { projectId: "..." }` inside it instead of replacing the whole object.
3. Save the file.
If you’re using the AI Agent to make changes locally, you can also just ask it:
> “Add extra.eas.projectId with value \[your ID] to app.config.js.”
Once it’s saved, run `eas build -p ios --profile development` again and it should proceed without the warning.
## 7. Add your Expo Project ID to Draftbit
[Section titled “7. Add your Expo Project ID to Draftbit”](#7-add-your-expo-project-id-to-draftbit)
Your app’s **Expo Project ID** is shared across both platforms—it’s one Project ID per app, not a separate one for iOS vs. Android.
* **If you’ve already set up push notifications for Android first**, this build will simply find and reuse that same existing Project ID—you’ll see a message like `Existing EAS project found for @your-username/your-app-slug (id = ...)`. Use that same ID; there’s no need to generate a new one.
* **If iOS is the first platform you’re setting this up for**, this is the step where the Project ID gets created for the first time—you’d then reuse that same ID later when setting up Android.
Copy the ID from the terminal output, then add it to `app.config.js` in your Draftbit project too, the same way you did locally in step 6: open [Code Editing mode](/features/code-editor) in the builder, edit `app.config.js` directly to add the `extra.eas.projectId` field, and save.
If you’re using the AI Agent to make changes in the builder, you can also just ask it:
> “Add extra.eas.projectId with value \[your ID] to app.config.js.”
This updates the builder’s own copy of `app.config.js`, so future builds and publishes done through Draftbit’s normal cloud pipeline have the Project ID too.
## 8. Publish again
[Section titled “8. Publish again”](#8-publish-again)
The credential now lives with Expo, not in your exported copy—go back to Draftbit and publish once more so the live build picks it up. From here, a push sent through Expo’s push service reaches real iOS devices.
## Retrieve a device’s push token
[Section titled “Retrieve a device’s push token”](#retrieve-a-devices-push-token)
The AI Agent prompt in step 1 already registers each device’s Expo push token—via `expo-notifications`’s `getExpoPushTokenAsync()`—and stores it on the signed-in user’s record. To send a notification to a specific device later, look up that stored token; there’s no separate step needed to fetch it again.
Note
Testing remote push notifications requires a physical device—the iOS Simulator can’t receive real push notifications.
## Troubleshooting
[Section titled “Troubleshooting”](#troubleshooting)
#### ”Missing config” error when running `eas credentials`
[Section titled “”Missing config” error when running eas credentials”](#missing-config-error-when-running-eas-credentials)
You need at least one iOS build configured before credentials can be managed. Run `eas build:configure -p ios` (step 6) first.
#### Notifications aren’t arriving on a device
[Section titled “Notifications aren’t arriving on a device”](#notifications-arent-arriving-on-a-device)
* Confirm the Push Notifications capability shows as enabled on your Bundle ID in the Apple Developer portal.
* Make sure the device has notification permissions granted and a push token was actually registered—ask the AI Agent to log the token after registration.
* Rebuild and republish after any credential or `app.config` change; existing installs won’t pick up new credentials until the next build.
# Understanding Navigation
> Learn best practices for setting up navigation in your app
Navigation is how people move between screens in your app—like going from a Home screen to a Details screen, opening a tab bar at the bottom, or showing a one‑time onboarding flow. In Draftbit, your app runs on Expo + React Native using Expo Router under the hood. You don’t need to code navigation yourself: you describe what you want, and the AI (or presets) creates the right screens and folders.
Good to know
Expo Router uses a simple “file‑based” approach. The way screens and folders are arranged determines your app’s routes (URLs/paths) and navigation hierarchy. You’ll see this in the Screens list and the Preview’s All Routes view.
## Navigation patterns
[Section titled “Navigation patterns”](#navigation-patterns)
* **Stack**: Think of a deck of cards. You push a new screen on top (e.g., from `Home` to `Product Details`) and go back to the previous one.
* **Tabs**: A bar at the bottom (or top) with multiple sections (e.g., Home, Search, Profile). Each tab can have its own stack of screens.
* **Drawers**: A side panel that slides in (often used on Android) with links to key areas.
Most real apps use a combination, typically: Tabs at the bottom; each tab contains a Stack; sometimes there’s a Drawer around everything for power navigation.
## How Expo Router maps to files
[Section titled “How Expo Router maps to files”](#how-expo-router-maps-to-files)
Here’s how structure translates to behavior under the hood:
* **`app/`**: The root of your screens. Each file or folder becomes a route (screen or group).
* **`(tabs)/`**: A “group” that renders a Tab navigator. Screens inside become Tab items.
* **`(stack)/`**: A group that renders a Stack navigator. Screens inside push on top of each other.
* **`_layout.tsx`**: The layout file inside a group that defines the navigator and screen options (titles, icons, etc.).
* **`index.tsx`**: The default screen for a folder (e.g., `app/index.tsx` is your Home route).
* **`[id].tsx`**: A dynamic route for details pages (e.g., `/products/42`).
* **`modal.tsx` or `(modals)/`**: Screens that appear as modals.
You don’t need to write these files yourself; the AI creates and maintains them when you describe the structure you want.
## Recommended structure
[Section titled “Recommended structure”](#recommended-structure)
For a typical consumer app, we recommend this high‑level setup:
**Onboarding & Auth** (optional but common)
* Show once for new users, or when logged out
* Screens: Welcome → Sign up → Log in → Forgot password
**Main Tabs** (core areas of the app)
* Home
* Browse/Search
* Activity/Notifications
* Profile/Account
**Details Screens** (opened from lists/cards)
* Product details, Post details, User profiles, etc.
**Modal Screens** (quick tasks)
* Filters, Create post, Edit profile, Settings
### Route tree
[Section titled “Route tree”](#route-tree)
A simple visual reference to how this looks in a file-based structure that Expo Router understands:
* app
* (auth)
* \_layout.tsx
* welcome.tsx
* login.tsx
* signup.tsx
* (tabs)
* \_layout.tsx
* home
* index.tsx
* \[id].tsx
* search
* index.tsx
* filters.tsx
* activity
* index.tsx
* profile
* index.tsx
* edit-profile.tsx
In the Preview’s All Routes view, you’ll see these sections laid out so you can sanity‑check flow.
## Best practices
[Section titled “Best practices”](#best-practices)
* **Start simple, then expand**: Begin with one or two tabs and a straightforward flow. Add more screens as your content grows.
* **Name screens for people, not code**: Clear names like “Order Details” or “Find Products” help everyone (and the AI) stay aligned.
* **Group related screens**: Keep list → details screens within the same tab/stack. It’s easier to reason about back behavior.
* **Use modals for short tasks**: Quick edits, filters, confirmations, and pickers feel better as modals than full screens.
* **Keep the first tap obvious**: Your `index` (home) screen should explain what to do next—primary CTA, top content, or simple menu.
* **Avoid deep nesting**: If users tap more than 3 levels deep, consider promoting important screens to a tab or using shortcuts.
* **Test with Preview’s All Routes**: Quickly check for missing screens, unexpected paths, or confusing names.
Naming screens
You can customize how a screen’s name appears in the Screens List without changing the actual file name or route. Open the screen, go to the **Config** tab in the Utility Panel, and set a **File Label**. See the [AI App Builder → Config](/features/ai-app-builder#config) section for details.
## Using AI
[Section titled “Using AI”](#using-ai)
You can use plain language to create or change navigation in the [AI Chat](/features/ai-app-builder). Here are some example prompts:
* “Create a 4‑tab layout: Home, Search, Activity, Profile. Each tab should be a stack.”
* “Add a details screen that opens from Home when someone taps an item.”
* “Make a modal called Filters accessible from the Search tab.”
* “Add an onboarding stack with Welcome and Login, before the tabs.”
* “Rename ‘Activity’ to ‘Notifications’ and set the title to ‘Inbox’.”
* “In Profile, add an Edit Profile modal I can open from a button.”
## Common tasks
[Section titled “Common tasks”](#common-tasks)
* **Link a button to another screen**: Select the button, open the Config tab, choose “Navigate to…”, and pick the target screen.
* **Open as a modal**: When linking, choose the modal presentation option if available (or ask the AI to change presentation to modal).
* **Pass data to a details screen**: From a list, link to a details screen and pass the item’s ID (ask the AI to wire this up if unsure).
* **Customize screen titles/icons**: Ask the AI to “Set the Home tab’s icon to a house” or “Change the title of Details to Product.”
* **Reorder tabs**: Ask the AI: “Move Profile to the last tab.”
## Pitfalls
[Section titled “Pitfalls”](#pitfalls)
* **Duplicate or unclear names**: If you have two “Details” screens in different places, rename them to “Product Details” vs “Order Details”.
* **Missing index screens**: Each group should have an index screen so navigation has a default destination.
* **Overusing modals**: Modals are great for quick tasks. For longer reading or multi‑step forms, use regular screens.
* **Too many tabs**: If you have more than 5 tabs, users may miss important areas. Consider tabs + stacks + shortcuts.
## Troubleshooting
[Section titled “Troubleshooting”](#troubleshooting)
* “I can’t find my screen in Preview” → Switch to All Routes view; check naming; confirm the screen is inside the right group.
* “Back behaves strangely” → Ensure the screen lives in the correct stack/tab. Moving it to the right group usually fixes the back path.
* “My details screen is empty” → Make sure you’re passing the item data (or its ID). Ask the AI to wire the parameter into the screen.
* “Tabs not showing” → Confirm you actually have a `(tabs)` group with an `_layout` and at least one child screen.
## Glossary
[Section titled “Glossary”](#glossary)
| Term | Definition |
| ------------- | ------------------------------------------------------------------------------------- |
| Route | A path to a screen (like an address). The combination of folders/files defines it. |
| Stack | A pile of screens—new ones sit on top; back returns to the one below. |
| Tabs | A row of buttons at the bottom (or top) for switching sections. |
| Drawer | A side menu that slides in with navigation links. |
| Layout | A file that defines how screens in a folder work together (e.g., as tabs or a stack). |
| Dynamic route | A screen whose path includes a variable (like `/products/[id]`). |
# Credits
> Learn about how credits work
Credits are the usage currency that powers AI-assisted development. Understanding how they work, the different types available, and how to manage them will help you use the platform effectively.
## Earn Credits
[Section titled “Earn Credits”](#earn-credits)
The **Earn Credits** page in your account is the fastest way to top up your balance outside of buying more or upgrading your plan. Complete approved challenges, leave feedback, or invite other builders to earn bonus credits that drop straight into your account.

The page is split into two tabs:
* **Challenges** — A grid of one-time tasks you can complete to earn credits.
* **Activity** — A history of credits you have already earned and claimed.
When a challenge is approved, the reward shows up in the **Ready to claim** card on the right. Click **Claim Reward** to deposit those credits into your account.
| Challenge | Description |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Social follows** | Quick wins for following Draftbit on X, Instagram, and LinkedIn, or subscribing on YouTube. Each one is worth a fixed credit reward. |
| **Video testimonials** | Record a short video about your experience with Draftbit. Submissions are reviewed before credits are awarded. |
| **Written feedback** | Share detailed feedback or a case study about how you use Draftbit. Reviewed before credits are issued. |
| **Invite a friend** | Earn **10,000 credits** per referral. Credits are issued automatically once a referred customer starts a paid subscription. Copy your unique referral link from the Earn Credits page. |
| **Affiliate program** | Earn cash, not just credits. Join the affiliate program to get paid commission for every customer who signs up through your link. |
Tip
Credits earned this way are added as bonus credits, which are consumed last after your daily and subscription credits.
## How credits work
[Section titled “How credits work”](#how-credits-work)
Every AI interaction consumes credits based on:
* **Model cost** — Different AI models have different pricing tiers
* **Context size** — The amount of information processed (conversation history, files, code)
* **Output generated** — The amount of code or text the AI produces
For detailed strategies on optimizing credit usage, see [Using Credits Efficiently](/intro/best-practices/using-credits-efficiently).
## Using your own provider
[Section titled “Using your own provider”](#using-your-own-provider)
Some plans and gateways let you run threads through your own provider access instead of Draftbit credits. Configure those options in [Agent Config](/features/agent-instructions).
Supported provider paths include OpenRouter API keys, OpenAI API keys, Anthropic API keys, OpenAI subscriptions, Claude subscriptions, and Codex subscriptions.
Threads that use your own key or subscription do not consume Draftbit credits for model usage, but they are still subject to that provider’s authentication, quota, rate limit, and subscription rules. If a provider rejects a request or reaches a usage limit, Draftbit shows the provider-specific message in chat so you know where to recover.
## Usage details
[Section titled “Usage details”](#usage-details)
Thread usage details show credit totals and token breakdowns by model and provider. Use them to understand which runs consumed credits, which runs used your own provider, and how much context or output contributed to the cost.
Bring your own keys
If you connect your own [Provider Keys](/features/agent-instructions#provider-keys-byok) for OpenAI, Anthropic, or OpenRouter, threads run on your key route directly to that provider and **bypass Draftbit credits entirely**. Provider labels are shown in chat and thread history so you always know which threads are billed where.
## Credit types explained
[Section titled “Credit types explained”](#credit-types-explained)
The platform uses three types of credits, each with different rules and renewal behaviors.
### Daily credits
[Section titled “Daily credits”](#daily-credits)
Daily credits are a renewable allowance that resets every 24 hours.
**Key characteristics:**
* **Reset schedule** — Renew at midnight in your account timezone
* **No rollover** — Unused daily credits do not carry forward to the next day
* **Supplementary** — Designed to supplement your subscription credits for light usage
**Best used for:**
* Quick questions in Chat mode
* Small edits and tweaks
* Exploring features without consuming subscription credits
### Subscription credits
[Section titled “Subscription credits”](#subscription-credits)
Subscription credits are your primary credit bucket, tied to your billing plan.
**Key characteristics:**
* **Billing cycle** — Renew on your monthly or annual billing date
* **Plan-based** — Credit amount determined by your subscription tier
* **Primary pool** — Used after daily credits are exhausted
* **30-day grace period** — Subscription credits expire 30 days after the end of the billing period in which they were issued. Within that window you can still spend them even if you’ve moved to a different plan.
**Usage priority:**
1. Daily credits are used first
2. Subscription credits are consumed after daily credits run out
3. Bonus/grant credits are used last (if applicable)
### Bonus & grant credits
[Section titled “Bonus & grant credits”](#bonus--grant-credits)
Bonus and grant credits are awarded through various channels outside your regular subscription.
**How you receive them:**
* **Admin grants** — Platform team awards for specific situations
* **Promotional campaigns** — Special offers and limited-time bonuses
* **Community rewards** — Contributing feedback, bug reports, or community builds
* **Platform issue compensation** — Credits restored when platform issues cause excess usage
**Key characteristics:**
* **No expiration** — Most bonus credits remain available until used
* **Last in priority** — Consumed after daily and subscription credits
* **Stackable** — Multiple grants accumulate in your account
For more on earning bonus credits, see [Earn Credits](#earn-credits).
## Checking your credit balance
[Section titled “Checking your credit balance”](#checking-your-credit-balance)
You can view your current credit balance and usage history in your account dashboard.
**What you’ll see:**
* **Current balance** — Available credits across all types
* **Daily credits** — Remaining credits until next daily reset
* **Subscription credits** — Credits remaining in current billing cycle
* **Bonus credits** — Total accumulated grants and rewards
* **Usage history** — Recent credit consumption by thread and model
* **Breakdown by model and provider** — A per‑model and per‑provider view of where your credits went (visible to all users, not just admins)
**Tip:** Monitor your usage patterns to identify opportunities for optimization. See [Using Credits Efficiently](/intro/best-practices/using-credits-efficiently) for strategies.
## Buying additional credits
[Section titled “Buying additional credits”](#buying-additional-credits)
If you need more credits beyond your current plan, several options are available.
### Purchase extra credits
[Section titled “Purchase extra credits”](#purchase-extra-credits)
You can buy one-time credit bundles that are immediately added to your account.
**How it works:**
* Select a credit bundle size from available options
* Credits are added to your account as bonus credits
* One-time purchase, not recurring
* Credits remain until used (no expiration)
**When to buy extra credits:**
* Temporary spike in usage (major feature development)
* End of billing cycle and running low
* Special project requiring more capacity
### Upgrade your plan tier
[Section titled “Upgrade your plan tier”](#upgrade-your-plan-tier)
Upgrading to a higher subscription tier increases your monthly credit allocation.
**Benefits of upgrading:**
* Higher monthly credit allowance
* Credits renew automatically each billing cycle
* Access to better models (on premium tiers)
* More cost-effective than frequent credit purchases
**Upgrade process:**
1. Review available plan tiers in account settings
2. Compare credit allocations and features
3. Upgrade takes effect immediately
4. Credits are prorated for current billing period
### Custom plans with extra credits
[Section titled “Custom plans with extra credits”](#custom-plans-with-extra-credits)
For teams or users with consistently high usage, custom plans can be configured.
**What’s included:**
* **Custom credit allocations** — Set credit amounts beyond standard tiers
* **Flexible billing** — Monthly or annual options
* **Team features** — Shared credits across team members (if applicable)
**Contact support to discuss:**
* Your typical monthly usage patterns
* Number of team members (if applicable)
* Specific model requirements
* Budget considerations
## When credits seem too high
[Section titled “When credits seem too high”](#when-credits-seem-too-high)
If you notice unexpected credit consumption or believe platform issues caused excess usage, we want to help.
### What to do
[Section titled “What to do”](#what-to-do)
If credits feel unusually high for a task, please share the following information:
**Required details:**
1. **Thread link** — Direct link to the conversation where credits were consumed
2. **Task description** — Brief explanation of what you were trying to accomplish
3. **Model used** — Which AI model was selected (if known)
4. **Preview status** — Whether preview/build was failing or in error loops
5. **Thread length** — Approximate number of messages in the thread
6. **Context size** — Whether large files were attached or referenced
**How to report:**
* Use the in-app support/feedback form
* Email support with “High Credit Usage Review” in subject line
* Include your account email for follow-up
### What we’ll do
[Section titled “What we’ll do”](#what-well-do)
When you report unexpectedly high credit usage, our team will:
**Review your usage:**
* Analyze the specific thread and interactions
* Check for platform-side retry loops or errors
* Identify any system issues that inflated costs
* Compare against typical usage patterns for similar tasks
**Identify platform issues:**
* Determine if platform bugs caused repeated attempts
* Check if preview/build failures triggered unnecessary retries
* Investigate whether system errors led to wasted credits
* Review logs for abnormal AI behavior or loops
**Grant credits if confirmed:**
* If platform issues are confirmed, we’ll restore the affected credits
* Credits are typically issued as bonus/grant credits
* Restoration usually happens within 1-2 business days
* You’ll receive confirmation when credits are added
**Provide guidance:**
* Share specific recommendations for avoiding similar issues
* Suggest workflow improvements for better efficiency
* Point to relevant documentation on credit optimization
* Offer tips for the specific scenario you encountered
Tip
Prevention is the best approach. Review [Using Credits Efficiently](/intro/best-practices/using-credits-efficiently) to learn strategies for keeping credit consumption predictable and avoiding common pitfalls that lead to high usage.
## Credit best practices summary
[Section titled “Credit best practices summary”](#credit-best-practices-summary)
To make the most of your credits:
1. **Use the right model** — Match model capability to task complexity
2. **Start fresh threads** — Avoid long threads that accumulate context
3. **Be specific** — Clear, scoped requests reduce back-and-forth
4. **Monitor usage** — Check your dashboard regularly to spot trends
5. **Optimize workflows** — Learn from high-usage patterns and adjust
For comprehensive strategies, see [Using Credits Efficiently](/intro/best-practices/using-credits-efficiently).
# Profile
> Manage your account profile
On the [Profile](https://next.draftbit.com/account) page you can update your personal information and delete your account. Access it by clicking your profile image in the top menu bar and selecting **Account**.
## Details
[Section titled “Details”](#details)

| Setting | Description |
| ---------------------- | --------------------------------------------------------- |
| **Profile** | Update your name and profile image |
| **Email address** | Update the email addresses associated with your account |
| **Connected accounts** | Manage connected accounts you used to sign in to Draftbit |
## Security
[Section titled “Security”](#security)

| Setting | Description |
| ------------------ | ------------------------------------------------------------------------------------------------- |
| **Active Devices** | A list of the devices currently signed in to your Draftbit account. You can remove them if needed |
| **Delete account** | You can delete your Draftbit account here |
## Invitations
[Section titled “Invitations”](#invitations)
When other users invite you to join one of their workspaces, an invitation will be listed in your account. You can either accept or reject the invitation.

# Composing task prompts
> Write clear, focused requests the AI can act on quickly
After your kickoff prompt sets the foundation, most progress comes from small, focused requests we call **task prompts**. These tell the AI what to add, change, or fix in simple language so you get precise results without long back‑and‑forth. It’s a short instruction—one or two paragraphs or a few bullets—that asks the AI to make one specific change. Think of it like a single checklist item: clear, doable, and easy to verify.
Note
Looking for guidance on the big, kickoff prompt? See the companion doc [Writing your initial prompt](writing-your-initial-prompt)
### Anatomy of a strong task prompt
[Section titled “Anatomy of a strong task prompt”](#anatomy-of-a-strong-task-prompt)
| Element | Purpose | Example |
| ------------------- | ----------------------------------------------------- | ------------------------------------------------------- |
| **Objective** | States exactly *what* to do. | *“Add pull‑to‑refresh to the news feed.”* |
| **Where to change** | Name the screen, page, or area (file if you know it). | *“Settings screen (Profile tab is fine too).”* |
| **Helpful details** | Share anything needed to do it right. | *“The list shows 20 articles and groups by category.”* |
| **Limits & rules** | Style, accessibility, or other must‑follow rules. | *“Match the current styles and support screen readers”* |
## Why effective task prompts matter
[Section titled “Why effective task prompts matter”](#why-effective-task-prompts-matter)
* **Clarity** Clear, specific requests prevent missteps.
* **Speed** Small requests finish faster and are easier to approve.
* **Confidence** It’s easier to check if one change works.
* **Accountability** Each request maps to one visible change you can review.
## Best practices
[Section titled “Best practices”](#best-practices)
1. **One change per prompt** – easier to check and undo if needed.
2. **Point to where** – name the screen or area (file if you know it).
3. **Add just‑enough detail** – include short text, images, or data the AI needs.
4. **Link outside services** – share URLs, accounts, or keys if relevant.
5. **Share limits and rules** – speed, style, accessibility, and security expectations.
6. **Ask for a focused reply** – e.g., “return the updated screen only.”
7. **Say what not to change** – call out files/parts to avoid.
8. **Proofread once** – fix typos and double‑check names.
## Practical examples
[Section titled “Practical examples”](#practical-examples)
| Scenario | Ineffective Prompt | Effective Task Prompt |
| -------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| **Add Dark Mode toggle** | “Add dark mode.” | “Add a Dark Mode switch in Settings. When it’s on, use dark colors and remember my choice the next time I open the app.” |
| **Swipe‑to‑delete in To‑Do app** | “Let users delete tasks by swiping.” | “Let me swipe a to‑do item to show a Delete action. When I tap Delete, remove that task from the list.” |
| **Cache API responses** | “Add caching.” | “Save the articles list for 10 minutes so it loads instantly. Only check online for new articles after 10 minutes.” |
| **Sign‑out flow** | “Add logout.” | “Add a Sign Out button. When I press it, log me out, clear any saved session, and take me back to the login screen.” |
## Quick checklist before you hit **Send**
[Section titled “Quick checklist before you hit Send”](#quick-checklist-before-you-hit-send)
* [ ] **One clear task** – not a bundle of unrelated changes.
* [ ] **Where to change** – name the screen/section (and file if you know it).
* [ ] **What “done” looks like** – one sentence of how you’ll verify it works.
* [ ] **Helpful references** – add any design, data, or screenshots.
* [ ] **Limits & rules** – performance, style, and accessibility expectations.
* [ ] **Out of scope** – call out anything that should not be included.
* [ ] **External services** – mention APIs, accounts, or keys if needed.
* [ ] **Data handling** – say what’s saved and where (local/cloud).
* [ ] **Response format** – ask for a diff or a single updated file.
* [ ] **Quick test step** – a simple way to check it manually.
# Using credits efficiently
> Optimize your credit usage to reduce waste and maximize productivity
Credits are the currency that powers AI-assisted development. Understanding how they’re consumed and how to optimize their use will help you work more efficiently and keep costs predictable.
## How credits are consumed
[Section titled “How credits are consumed”](#how-credits-are-consumed)
Credit consumption is primarily driven by two factors:
1. **Context size** — The amount of information the AI must process, including conversation history, attached files, and code references
2. **Model cost** — Different AI models have different pricing tiers based on their capabilities
Each request consumes credits based on the formula: **input tokens × model rate + output tokens × model rate**. This means that larger contexts (more conversation history, more attached files) and more expensive models will consume more credits per interaction.
### Common credit consumption patterns
[Section titled “Common credit consumption patterns”](#common-credit-consumption-patterns)
Credit usage typically spikes in these scenarios:
* **Long conversation threads** — Each new message in a thread includes all previous context, so threads become progressively more expensive
* **High-end models on routine tasks** — Using advanced models for simple changes wastes credits
* **Broad, unfocused requests** — Vague prompts often require multiple clarification rounds
* **Repeated trial-and-error** — Running the same failed request multiple times without adjusting your approach
* **Large file attachments** — Adding entire large files as context when only specific sections are relevant
## Highest-impact optimizations
[Section titled “Highest-impact optimizations”](#highest-impact-optimizations)
These strategies deliver the most significant credit savings with minimal effort.
### Start fresh threads strategically
[Section titled “Start fresh threads strategically”](#start-fresh-threads-strategically)
Long threads accumulate context exponentially. A 20-message thread might include 100,000+ tokens of history, meaning each new prompt costs significantly more than it would in a fresh thread.
**The cost multiplier effect:**
* Message 1 in a thread: 1x context cost
* Message 10 in a thread: \~5-10x context cost
* Message 20 in a thread: \~15-25x context cost
Beyond cost, long threads also reduce AI effectiveness because the model must reconcile potentially conflicting requirements from earlier in the conversation.
#### When to start a new thread
[Section titled “When to start a new thread”](#when-to-start-a-new-thread)
[Start a new thread](/features/ai-app-builder#ai-chat) when:
* **Topic shifts** — Moving from authentication work to styling work
* **Phase changes** — Completing bug fixes and starting feature development
* **Context becomes stale** — Earlier decisions have been superseded
* **Thread exceeds 15-20 messages** — Even if still on-topic, the context cost becomes significant
* **You’re getting confused responses** — The AI may be trying to honor outdated requirements
#### How to transition effectively
[Section titled “How to transition effectively”](#how-to-transition-effectively)
Tip
You can start a new thread from **any point** in an existing thread by clicking **“Start New Thread From Here”** on the thread summary menu. This lets you branch off efficiently without carrying over all prior context.
The key is creating a clean handoff that preserves essential context without bringing forward unnecessary history:
1. **Write a concise summary** of the current state, decisions made, and what needs to happen next
2. **Start a new thread** and paste the summary as the opening message
3. **Include only relevant context** — Attach specific files or code sections needed for the next phase
**Summary template:**
```markdown
## Context Summary
**Goal:** [What we're trying to accomplish]
**Current State:** [What's been completed, what exists now]
**Key Decisions:** [Important architectural or technical choices made]
**Next Steps:** [Specific tasks to complete]
**Relevant Files:** [List only files that will be actively modified]
```
**Example summary:**
```markdown
## Context Summary
**Goal:** Implement user profile editing feature
**Current State:**
- Profile viewing is complete (ProfileScreen.tsx)
- API endpoints exist for GET /profile and PATCH /profile
- Form validation library (react-hook-form) is configured
**Key Decisions:**
- Using optimistic updates for better UX
- Profile images stored in S3, not database
- Validation happens client-side and server-side
**Next Steps:**
- Add edit mode toggle to ProfileScreen
- Implement form submission with error handling
- Add image upload component
**Relevant Files:**
- src/screens/ProfileScreen.tsx
- src/api/profile.ts
```
This approach typically reduces context size by 70-90% compared to continuing a long thread.
### Match models to task complexity
[Section titled “Match models to task complexity”](#match-models-to-task-complexity)
Model selection is the single biggest lever for controlling credit consumption. Advanced models can cost 5-10x more per token than basic models, so using the right model for each task is critical.
#### Model selection framework
[Section titled “Model selection framework”](#model-selection-framework)
| Task Complexity | Use This Model | Example Tasks |
| --------------- | ------------------ | ---------------------------------------------------------------------------------------------------------------- |
| **Trivial** | Cheapest available | Copy edits, comment updates, simple CSS tweaks, renaming variables |
| **Simple** | Fast/basic model | Styling adjustments, layout changes, adding console logs, minor bug fixes in isolated functions |
| **Moderate** | Mid-tier model | Component creation, API integration, form handling, state management, test writing |
| **Complex** | Advanced model | Architecture decisions, multi-file refactors, complex algorithm implementation, debugging subtle race conditions |
| **High-stakes** | Most capable model | Security-critical code, data migrations, payment processing, authentication systems |
#### Cost-benefit analysis
[Section titled “Cost-benefit analysis”](#cost-benefit-analysis)
Consider a simple styling change that takes 3 interactions to complete:
* **With expensive model:** 3 requests × 2,000 tokens × 10 credits/token = 60,000 credits
* **With basic model:** 3 requests × 2,000 tokens × 1 credit/token = 6,000 credits
That’s a 10x difference for a task where model capability doesn’t materially affect quality.
#### When to upgrade mid-task
[Section titled “When to upgrade mid-task”](#when-to-upgrade-mid-task)
Start with a cheaper model and upgrade if you encounter:
* Multiple failed attempts with simple models
* Requests for complex reasoning or system design
* Need for deep codebase understanding across many files
* Subtle bugs requiring inference across multiple interaction points
### Configure sensible defaults
[Section titled “Configure sensible defaults”](#configure-sensible-defaults)
Your default model determines what gets used for most interactions, so setting it wisely prevents accidental waste.
**Where to configure:** Settings → Agent Config → Default Agent
**Recommended approach:**
1. Set your **default to a mid-tier model** that handles most common tasks well
2. Manually select cheaper models for trivial work
3. Manually select premium models for complex or high-risk work
This configuration prevents the most common waste pattern: accidentally using premium models for routine work because you forgot to change the selection.
### Bring your own provider keys
[Section titled “Bring your own provider keys”](#bring-your-own-provider-keys)
If you already have an OpenAI, Anthropic, or OpenRouter account, connecting your key under [Agent Customization → Defaults](/features/agent-instructions#provider-keys-byok) is the largest single lever for controlling spend. Threads run on your key route directly to the provider and **bypass Draftbit credits entirely** — you keep using whatever provider credits or rate limits you already have. BYOK is available on every plan, including Free.
## Thread management strategies
[Section titled “Thread management strategies”](#thread-management-strategies)
Effective thread management keeps context lean and conversations focused.
### One thread per logical unit of work
[Section titled “One thread per logical unit of work”](#one-thread-per-logical-unit-of-work)
Organize threads by feature, component, or problem domain rather than having one mega-thread for all work.
**Good thread organization:**
> ✓ Thread: User authentication setup\
> ✓ Thread: Profile screen styling\
> ✓ Thread: Push notification integration\
> ✓ Thread: API error handling refactor
**Poor thread organization:**
> ✗ Thread: Monday work\
> ✗ Thread: Fix all bugs\
> ✗ Thread: App improvements
### Splitting threads by work phase
[Section titled “Splitting threads by work phase”](#splitting-threads-by-work-phase)
Even within a single feature, consider splitting threads by phase:
> Thread 1: Design - Architecture planning for notification system\
> Thread 2: Implementation - Build notification infrastructure\
> Thread 3: Integration - Connect notifications to user actions\
> Thread 4: Testing - Debug notification delivery issues
This prevents the planning discussion from bloating the context during implementation.
### When to continue vs. restart
[Section titled “When to continue vs. restart”](#when-to-continue-vs-restart)
**Continue the current thread when:**
* You’re iterating on the immediate output (fixing a bug the AI just introduced)
* Making minor adjustments to what was just generated
* The total thread length is still under 10 messages
**Start a new thread when:**
* The subtask is complete and you’re moving to the next one
* You need to change models (better to start fresh than switch mid-thread)
* The AI seems confused about what you want
* You’ve had 3+ failed attempts and need to reset the approach
## Crafting efficient prompts
[Section titled “Crafting efficient prompts”](#crafting-efficient-prompts)
Better prompts reduce back-and-forth, which directly reduces credit consumption.
### Specificity reduces ambiguity
[Section titled “Specificity reduces ambiguity”](#specificity-reduces-ambiguity)
Vague prompts lead to clarifying questions and multiple attempts. Specific prompts get results on the first try.
**Vague prompts (high credit cost):**
> ❌ “Fix the button”\
> ❌ “Update the styling”\
> ❌ “Make the form better”\
> ❌ “This isn’t working”
**Specific prompts (low credit cost):**
> ✓ “Change the ‘Submit’ button in LoginForm.tsx to use primary color (#2563eb) and increase padding to 12px”
>
> ✓ “Update ProfileHeader.tsx to match the design: avatar should be 80px, name text should be 18px semibold, bio text should be 14px gray”
>
> ✓ “Add client-side email validation to RegistrationForm.tsx using the same validator pattern as LoginForm.tsx”
>
> ✓ “The PaymentButton onClick handler throws ‘undefined is not a function’ when clicking after selecting credit card as payment method”
### Provide structural context
[Section titled “Provide structural context”](#provide-structural-context)
Help the AI understand constraints and requirements upfront.
**Minimal prompt:**
> Add error handling to the API calls
**Context-rich prompt:**
> Add error handling to the user profile API calls in src/api/profile.ts:
>
> * Catch network errors and show toast notification
> * Handle 401 by redirecting to login
> * Handle 403 by showing “insufficient permissions” modal
> * Use the existing ErrorBoundary pattern from src/api/auth.ts
The context-rich version includes:
* **Location** (which file)
* **Requirements** (what errors to handle, how to handle them)
* **Constraints** (reuse existing patterns)
This eliminates clarification rounds.
### Scope requests precisely
[Section titled “Scope requests precisely”](#scope-requests-precisely)
Large, multi-part requests increase cognitive load for the AI and increase the chance of partial success requiring follow-up.
**Too broad:**
> ❌ “Refactor the entire app to use TypeScript”\
> ❌ “Improve performance”\
> ❌ “Update all components to match new design”
**Well-scoped:**
> ✓ “Convert src/components/ProfileCard.tsx from JavaScript to TypeScript, adding proper type definitions for props”
>
> ✓ “Optimize the ProductList component rendering by adding React.memo and useMemo for the filtered products calculation”
>
> ✓ “Update Button.tsx to match the new design system: rounded corners (8px), new color palette (primary: #2563eb), consistent padding (12px 24px)”
If the full change is large, break it into a sequence of scoped requests in separate threads.
### Reference specific code locations
[Section titled “Reference specific code locations”](#reference-specific-code-locations)
Rather than attaching entire files, reference specific functions, components, or line ranges.
**Inefficient:**
> \[Attaches 500-line file]\
> “Fix the bug in this file”
**Efficient:**
> “In UserService.ts, the `updateProfile` method (lines 45-67) doesn’t handle the case where email is unchanged but already exists for another user. Add a check to skip uniqueness validation if email hasn’t changed.”
Use `@` mentions to reference specific files, and describe the location within the file for surgical precision.
### Handle trivial changes manually
[Section titled “Handle trivial changes manually”](#handle-trivial-changes-manually)
For extremely simple changes where you know exactly what to do, doing it manually is often faster and cheaper than explaining it to the AI.
**Consider manual edits for:**
* Changing a color hex code
* Adjusting padding/margin by a few pixels
* Fixing typos in strings
* Reordering imports
* Adding a console.log for debugging
**Use AI for:**
* Changes where you’re unsure of the approach
* Updates that touch multiple related locations
* Refactoring that requires understanding logic flow
* Implementing patterns you’re unfamiliar with
When you need to know *where* or *how* to make a change, use Chat mode to ask for guidance, then implement it yourself. This is often cheaper than Agent mode end-to-end execution.
### Iterative refinement strategy
[Section titled “Iterative refinement strategy”](#iterative-refinement-strategy)
When requests fail or produce incorrect results, don’t repeat the same request. Adjust your approach:
**Failed request checklist:**
1. **Clarify requirements** — Add more specific details about expected behavior
2. **Narrow scope** — Focus on the specific failing piece
3. **Add constraints** — Specify what should NOT change
4. **Provide examples** — Show what correct output looks like
5. **Change models** — Try a more capable model if the task is complex
6. **Start fresh** — Begin a new thread if context is corrupted
**Example progression:**
> **Attempt 1:** “Add form validation”\
> → Result: Generic validation that doesn’t match requirements
>
> **Attempt 2:** “Add form validation to LoginForm.tsx:
>
> * Email must be valid email format
> * Password must be at least 8 characters
> * Show errors below each field, not in a modal
> * Use the same error styling as RegistrationForm.tsx”\
> → Result: Success
## Debugging efficiently
[Section titled “Debugging efficiently”](#debugging-efficiently)
Debugging can be a credit sink if not approached systematically.
### Add instrumentation proactively
[Section titled “Add instrumentation proactively”](#add-instrumentation-proactively)
Rather than multiple rounds of “try this,” “try that,” invest in adding logging and error handling that provides diagnostic information.
**Credit-expensive approach:**
> ❌ “Why isn’t this working?”\
> ❌ “Try adding a console.log here”\
> ❌ “Maybe check if this value is undefined”\
> ❌ “Add another log there”\
> \[5-10 messages of trial and error]
**Credit-efficient approach:**
> ✓ “Add comprehensive error handling and logging to the payment processing flow:
>
> * Log inputs at function entry
> * Log each state transition
> * Catch and log all errors with context
> * Add validation checks with descriptive error messages”\
> \[Get detailed diagnostics in one go]
The investment in instrumentation pays off by reducing guesswork.
### Provide complete error information
[Section titled “Provide complete error information”](#provide-complete-error-information)
When reporting bugs, include everything needed to diagnose:
**Incomplete bug report:**
> ❌ “The app crashes when I click the button”
**Complete bug report:**
> ✓ “The PaymentButton in CheckoutScreen.tsx crashes when clicked AFTER selecting ‘Credit Card’ option. Error: ‘Cannot read property ‘process’ of undefined’ in PaymentService.ts line 34. Stack trace shows it’s happening in handlePayment callback. This started after adding Stripe integration in commit abc123.”
Include:
* **What you did** (exact steps to reproduce)
* **What happened** (specific error message, stack trace)
* **Context** (when did it start, what changed recently)
* **Environment** (if relevant: device, browser, etc.)
### Use rollback strategically
[Section titled “Use rollback strategically”](#use-rollback-strategically)
If a change breaks things and debugging is taking multiple attempts, rolling back can be faster and free.
**When to roll back:**
* After 3+ failed debugging attempts
* When the change introduced multiple new issues
* When you’re no longer confident about the current state
* When starting over would be simpler than fixing forward
**When to debug forward:**
* The fix is obvious from the error
* You’re close to a solution
* Rolling back would lose significant work
* The issue exists in code that wasn’t just changed
Rollback is free and instant—use it as a reset button when debugging becomes inefficient.
### Reproduce issues in isolation
[Section titled “Reproduce issues in isolation”](#reproduce-issues-in-isolation)
If debugging a complex feature, try to isolate the issue in a minimal reproduction.
**Expensive:**
> \[Entire app as context]\
> “Debug why checkout flow breaks”
**Efficient:**
> “Create a minimal test case for the PaymentService.process method that reproduces the ‘undefined’ error when called with a credit card token”
Isolated reproductions reduce context size and make root cause identification faster.
### Preview & build credit awareness
[Section titled “Preview & build credit awareness”](#preview--build-credit-awareness)
When working with preview environments, metro bundlers, or sandboxes, be aware that certain patterns can cause unexpected credit consumption:
**Credits may be consumed when:**
* Agent automatically retries failing tasks
* Preview errors trigger repeated fix attempts
* Metro/sandbox logs are reprocessed in multiple requests
* Build failures cause iterative debugging loops
**Best practices:**
**Refresh/restart preview manually if broken**
* If the preview is in a broken state, manually restart it rather than asking the AI to “fix it again”
* This prevents the AI from reprocessing large log files repeatedly
**Start new thread if logs are stale**
* Build logs and error output accumulate as context
* If you’ve made several attempts and logs are outdated, start a fresh thread with just the current error
* Include only the relevant error section, not the entire build log
**Avoid repeated “fix again” loops in same thread**
* Instead of: “fix it” → “still broken, fix it” → “fix it again” → “try again”
* Do this: analyze the specific error, adjust your approach, start fresh if needed
* After 2-3 failed attempts, either rollback or start a new thread with better diagnostics
**Example of efficient preview debugging:**
> ❌ **Bad approach:**\
> \[Long thread with build logs]\
> “The preview is broken"\
> "Try again"\
> "Fix the error"\
> "Still not working”\
> \[Repeated log reprocessing, high credit cost]
>
> ✓ **Good approach:**\
> \[New thread]\
> “Preview fails with: ‘Module not found: Error: Can’t resolve ’./UserProfile’ in src/screens/Home.tsx line 12’. The file exists at src/components/UserProfile.tsx. Update the import path.”\
> \[Specific error, clear fix, resolved in 1-2 messages]
## Advanced optimization techniques
[Section titled “Advanced optimization techniques”](#advanced-optimization-techniques)
### Selective context attachment
[Section titled “Selective context attachment”](#selective-context-attachment)
Only attach files that will be directly modified or referenced. Avoid attaching entire folders or “just in case” files.
**Ask yourself:**
* Will this file be edited in this request?
* Does the AI need to see this exact code to understand the request?
* Could I describe the relevant pattern instead of showing the file?
**Example:** Instead of attaching `AuthContext.tsx` to show the authentication pattern, write: “Use the same authentication pattern as AuthContext.tsx (token storage, refresh logic, error boundaries).”
### Use mode selection wisely
[Section titled “Use mode selection wisely”](#use-mode-selection-wisely)
Different modes have different context costs:
* **Chat mode** — Lowest cost, read-only, good for questions and guidance
* **Agent mode** — Higher cost, can make changes, best for implementation
* **Debug mode** — Specialized for systematic debugging
Use Chat mode for:
* Asking how to approach a problem
* Getting guidance on where to make changes
* Understanding existing code
* Quick questions
Use Agent mode for:
* Implementing features
* Refactoring code
* Making multi-step changes
### Batch related changes
[Section titled “Batch related changes”](#batch-related-changes)
If you have multiple small, related changes, batch them into a single request rather than making separate requests.
**Inefficient (3 separate requests):**
> ❌ “Change button color to blue”\
> ❌ “Update button text to ‘Submit’”\
> ❌ “Add loading spinner to button”
**Efficient (1 request):**
> ✓ “Update the submit button in LoginForm.tsx:
>
> * Change background color to blue (#2563eb)
> * Update text from ‘Login’ to ‘Submit’
> * Add loading spinner that shows when isLoading prop is true”
This reduces overhead from repeated context loading.
### Monitor your usage patterns
[Section titled “Monitor your usage patterns”](#monitor-your-usage-patterns)
Pay attention to when your credit consumption spikes:
* Which types of requests consume the most credits?
* Which threads grow longest?
* When do you find yourself in extended debugging sessions?
Identifying patterns helps you adjust behavior in high-cost areas.
## Quick reference: Credit-saving checklist
[Section titled “Quick reference: Credit-saving checklist”](#quick-reference-credit-saving-checklist)
Before each request, consider:
* [ ] Is this thread getting long? (>10 messages → consider starting fresh)
* [ ] Am I using the right model for this task complexity?
* [ ] Is my request specific and well-scoped?
* [ ] Have I provided enough context to avoid clarification rounds?
* [ ] Am I attaching only necessary files?
* [ ] Could I do this trivial change manually faster?
* [ ] If this is a retry, have I adjusted my approach?
Following these practices will typically reduce credit consumption by 50-70% compared to unoptimized usage while also improving result quality and reducing frustration.
## Summary
[Section titled “Summary”](#summary)
Efficient credit usage comes down to three core principles:
1. **Keep context lean** — Start fresh threads, attach only necessary files, summarize rather than carry forward everything
2. **Match models to tasks** — Use cheaper models for simple work, reserve premium models for complex challenges
3. **Write precise prompts** — Specific, scoped requests with clear requirements reduce back-and-forth
The goal isn’t to minimize credit usage at all costs—it’s to get maximum value from each credit spent. Sometimes using a premium model or including extra context is the right choice. The key is making those choices consciously rather than accidentally.
# Writing your initial prompt
> Write a clear app prompt the agent can start using right away
When creating a new app project in Draftbit the journey begins with your initial natural‑language prompt. The agent turns that seed into a to‑do list and starts building right away. A clear prompt communicates intent to the AI agent, reducing re‑work and confusion.
Want to start from scratch?
If you’d prefer to build without an initial AI-generated app, choose `Create project without AI`.
## Core principles
[Section titled “Core principles”](#core-principles)
A great initial prompt shines when it does five things well:
* **Clarity** — use specific words instead of vague adjectives.
* **Completeness** — cover goals, users, constraints, and edge cases.
* **Context** — point to existing examples, data, and brand voice.
* **Constraints** — name platforms, legal or policy rules, speed targets, and offline use.
* **Criticality** — separate must‑haves from later ideas so v1 stays realistic.
## What to include
[Section titled “What to include”](#what-to-include)
Begin with a short paragraph that explains the problem and the outcome you want. Then cover these elements so the agent can turn it into a concrete to‑do list:
* **Who it’s for** — who benefits, where they’ll use it, and their comfort with tech.
* **How people use it (step by step)** — the key steps that deliver value.
* **Features (what it should do)** — group related items; say what “done” looks like for must‑haves.
* **Data and connections** — what you store, where it lives, and any outside services.
* **App quality** — speed, accessibility, reliability, and security expectations.
* **How we’ll know it works** — simple measures of success.
* **Unknowns and assumptions** — things that might change scope or feasibility.
* **Links and examples** — designs, docs, data samples, and brand voice.
## Prompting best practices
[Section titled “Prompting best practices”](#prompting-best-practices)
Explain your idea as you would to a thoughtful colleague with no background in the concept. Keep sentences focused, and use short bullet lists when they improve readability:
* **Answer the basic questions** — who, what, why, when, where, how.
* **Describe steps, not just features** — e.g., “A user opens the app, sees an empty dashboard, and is prompted to connect a bank account.”
* **Include examples** — sample data, sketches, or links to docs.
* **Say what’s out of scope** — “Do not include social login in v1.”
* **Use one idea per sentence** — avoid long, complicated sentences.
## Before you click **Start Building**
[Section titled “Before you click Start Building”](#before-you-click-start-building)
Run this quick self‑check:
* [ ] Does every feature map back to the problem statement?
* [ ] Are must‑haves, stretch goals, and exclusions unmistakable?
* [ ] Have edge cases and failure states been acknowledged?
* [ ] Could a new teammate understand and execute without follow‑up meetings?
* [ ] Are data and privacy notes clear (what’s stored and where)?
## Example Prompt
[Section titled “Example Prompt”](#example-prompt)
Below is the bare minimum initial prompt that checks all the boxes, but providing even more details would produce greater results.
```text
Build a simple mobile app for tracking personal expenses.
Audience: Individuals managing monthly budgets; non-technical; iOS and Android.
Core flows:
- Add an expense with amount, category, date, and optional note.
- View a list of expenses filtered by month.
- See a monthly total and category breakdown.
Must-haves (v1):
- Local-only storage (no login).
- Categories: Food, Transport, Rent, Utilities, Other.
- Accessibility: readable text, high contrast.
Out of scope (v1):
- Cloud sync, account creation, or bank integrations.
- Recurring expenses.
Constraints:
- Works offline.
- Launch icons + app name “PennyTrack.”
Success:
- A user can add, view, and understand monthly spend in <30 seconds.
Risks:
- Categories might need customization later.
References:
- [PennyTrack](https://www.pennytrack.app)
- [Figma design](https://www.figma.com/design/1234567890/PennyTrack)
- [API docs](https://api.pennytrack.app)
- [Brand voice](https://www.pennytrack.app/brand-voice)
```
## Bad → Better phrasing
[Section titled “Bad → Better phrasing”](#bad--better-phrasing)
| Bad | Better |
| -------------------- | ----------------------------------------------------------------------------------- |
| Add payments. | Let users pay invoices with Stripe using one-time card payments. |
| Add login. | Email code login only (no social). Limit attempts. Stay signed in for 7 days. |
| Integrate calendar. | Show a monthly calendar of tasks; allow adding and editing tasks by tapping a date. |
| Use AI to summarize. | Summarize each note into 2–3 sentences and include action items if found. |
| Store photos. | Store photos locally on the device (no cloud). Max 10MB per photo. |
| Make it fast. | Screens should load in under 1 second on a mid‑range phone. |
# Builder Overview
> Learn about the Draftbit App Builder
The Draftbit Builder is your workspace for turning app concepts into reality. It combines a Home view, visual editor, live preview, AI agent, code editor, integrations, build configuration, and publishing tools in one place.
To learn more about the different Builder views, follow the links below.

### Main Menu
[Section titled “Main Menu”](#main-menu)
You can access the main areas of the Builder from the project navigation on the left side of the Builder. The **Home** icon opens the default app workspace with the preview, agent, and editor panel available without opening the full screens/components layout.
| Icon | Action | Description |
| ---------------------------------------------------------------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------- |
|  | **[Visual Editor](/features/ai-app-builder/)** | Visually design screens, components, and styles with AI assistance |
|  | **[Preview](/features/ai-app-builder#preview-panel)** | Test and preview your application as you build |
|  | **[Code Editor](/features/code-editor/)** | Edit your code directly using the built-in editor |
|  | **[API\&Data](/features/integrations)** | Manage third-party APIs & data sources for your app |
|  | **[Publishing](/features/publishing/)** | Manage app publishing and deployments to web, iOS, and Android |
|  | **[Agent Config](/features/agent-instructions/)** | Manage agent defaults, provider keys, saved prompts, and instructions |
|  | **[Build Config](/features/build-config/)** | Manage environment variables, packages, and build-time configuration |
|  | **[Themes](/features/themes/)** | Customize shared theme colors and typography for your app |
|  | **[Version History](/features/history/)** | View project activity history and rollback changes |
|  | **[Settings](/features/project-settings/)** | Configure app identity, icons, app configuration, and project actions |
|  | **[Tasks](/features/tasks/)** | Track and manage development tasks at the project level |
|  | **[Project Assets](/features/cloud-storage/)** | Cloud storage for your images, video, audio and other media files at the project level |
|  | **[Project Integrations](/features/integrations)** | Manage third-party service integrations for your app at the project level |
|  | **Project Settings** | Configure project settings and preferences |
### Mobile Builder
[Section titled “Mobile Builder”](#mobile-builder)
On mobile-width screens, the Builder switches from the left project navigation to bottom tabs. The Home view includes **Preview**, **Agent**, **Editor**, and **Account**. The full Visual Editor also includes a **Screens** tab for the screens list and component tree.

### Support Menu
[Section titled “Support Menu”](#support-menu)
The bottom More menu groups helpful resources and secondary controls such as What’s New, Roadmap, Docs, Videos, Sandbox Status, and the light/dark theme switcher.
| Icon | Action | Description |
| ---------------------------------------------------------------------------- | ------------------------------------------------------------------------- | -------------------------------------------------------------------- |
|  | **[Show Preview Logs](https://docs.draftbit.com/features/preview-logs/)** | View build output and errors while working in preview |
|  | **Restart Preview** | Restart the previews |
|  | **More** | Additional resources, settings, and sandbox controls |
|  | **Sandbox Status** | View the current sandbox, repository, and preview status for the app |
|  | **Open in VSCode** | Open your project’s files directly in VSCode |
|  | **[What’s New](https://next.draftbit.com/whats-new)** | View the latest product updates |
|  | **[Roadmap](https://next.draftbit.com/roadmap)** | View and contribute to the platform roadmap |
|  | **[Docs](/)** | Learn about building apps using Draftbit |
|  | **[Videos](https://youtube.com/draftbit)** | Watch video tutorials, office hours, and more |
|  | **Dark/Light Mode** | Switch between a dark and light Builder UI |
### Top Bar
[Section titled “Top Bar”](#top-bar)
The Top Bar runs across the top of the Builder and contains the actions you reach for most often:
| Icon | Action | Description |
| ------------------------------------------------------------------------------------ | ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
|  | **Project / App Switcher** | Switch between apps within the current project, create a new app, or access project settings |
|  | **[Billing](/features/billing/)** | Check your remaining credit balance and top up |
|  | **Undo / Redo** | Step backward or forward through your recent changes |
|  | **Save History** | View and roll back to previous saved versions of your app |
|  | **Recommended Changes** | View flagged issues like preview errors or unconfigured integrations, with quick actions to fix them |
|  | **Live Preview** | Open the QR-code launcher to preview the running app on a real iOS or Android device using the [Draftbit Preview app](/features/preview-app/) |
|  | **Native Builds** | Create native development builds for iOS and Android |
|  | **Get Help** | Open the in-app support chat |
|  | **Export** | Download a zip of your codebase |
|  | **[Publish](/features/publishing/)** | Open the publish popover with Progressive Web App, Apple App Store, Google Play Store, and Share options |
|  | **[Save / Save History](/features/saving-changes/)** | Save and roll back changes |
# Building your App
> An overview of the features in Draftbit
You have a lot of freedom to choose how you approach building apps in Draftbit. You can describe what you want in chat, make direct visual edits, manage integrations and build configuration, or edit code yourself. Most teams use a mix of those workflows as the app matures.
## AI Agent
[Section titled “AI Agent”](#ai-agent)
Working with Draftbit’s AI agent makes building apps easier by letting you describe changes in natural language. The agent can edit files, use connected integrations, inspect preview errors, and explain what changed. Learn more in the [AI App Builder](/features/ai-app-builder).
## Visual Editor
[Section titled “Visual Editor”](#visual-editor)
Use the Visual Editor to work directly with screens, components, styles, and preview devices. You can select elements, inspect component structure, adjust styles, and give the agent targeted context from the canvas.
## Cloud Storage
[Section titled “Cloud Storage”](#cloud-storage)
Each app project in Draftbit gets a dedicated asset area to store app media including images, video, audio, fonts, and text files. Learn more about managing [Assets](/features/cloud-storage).
## Build Config
[Section titled “Build Config”](#build-config)
Use [Build Config](/features/build-config) to manage environment variables, npm packages, and legacy variables for imported apps. This is also where package changes that affect native builds start.
## Code Editor
[Section titled “Code Editor”](#code-editor)
If you have experience coding or are inclined to learn, Draftbit provides code access directly in the Builder. Learn more about working with the [Code Editor](/features/code-editor).
## App Publishing
[Section titled “App Publishing”](#app-publishing)
Once you’ve built your app in Draftbit, you can share it as a public prototype, publish a PWA, build native previews, submit to the Apple App Store or Google Play Store, or export the code. Draftbit offers [one-click publishing](/features/publishing#one-click-publishing) for managed builds and [manual publishing](/features/publishing#manual-publishing) for teams that want full control over deployment.
[Explore more features ](/features)Check out more features available to you in the Builder
# Common Questions
> Get answers to common questions about Draftbit
## Supported Technologies
[Section titled “Supported Technologies”](#supported-technologies)
What browsers does Draftbit support?
Draftbit works well in most modern browsers, however Firefox and Chrome or Chrome-based browsers are recommended. Make sure you are developing in one of these browsers.
Some browser extensions, such as ad blockers, can also interfere with the function of Draftbit. If you are experiencing difficulty, try disabling browser extensions to see if this resolves the issue.
Which software languages are supported by Draftbit?
Currently, Draftbit supports languages like JavaScript/TypeScript, JSX, JSON, and Markdown. PHP, Python, C#, C++, or any other non-web languages, are not supported.
## Using Draftbit
[Section titled “Using Draftbit”](#using-draftbit)
Do I need to know how to code?
No coding experience is required! Our AI handles all the technical aspects. However, if you do know how to code, you have full access to customize the generated code. Take a look at the [Useful Links](/intro/resources/useful-links) for some helpful resources if you’re interested in learning to code!
How do I move my Draftbit v1 app to the new Draftbit?
Select the ‘Import’ tab from the top menu on the Dashboard then locate the app you want to import. Please note that you must be signed in to the same account as your original Draftbit Classic account.
Can I open an existing GitHub repo in Draftbit?
Draftbit supports importing apps from Draftbit Classic and starting new apps based on React Native/Expo. Opening arbitrary existing GitHub repos directly in Draftbit is not currently supported.
What platforms will my app work on?
Your app will work on iOS, Android, and web browsers. We use React Native and Expo to ensure your app runs smoothly across all platforms from a single codebase.
Can I use my own data and APIs?
Absolutely! You can connect any [REST](/features/integrations#rest-api-connectors) or [GraphQL](/features/integrations#graphql-api-connectors) endpoint and have the agent call it as a tool, or use one of the [MCP Integrations](/features/integrations#mcp-integrations) for popular services like Supabase, Xano, Directus, Stripe, and more.
Can I use my own AI provider keys?
Yes. You can connect API keys for OpenAI, Anthropic, and OpenRouter under [Agent Customization → Defaults](/features/agent-instructions#provider-keys-byok). Threads that run on your own key route directly to the provider and bypass Draftbit credits entirely. This is available on every plan, including Free.
How do I download my app project?
You can export a .zip of your codebase from the ‘Publish’ menu in the top-right of the Builder.
## Privacy & Security
[Section titled “Privacy & Security”](#privacy--security)
Is my code and data secure?
Yes, Draftbit takes your privacy and security seriously. Your code and sensitive data are protected through multiple layers of security:
* **Your code is never used to train AI models** - We respect your intellectual property and maintain strict data separation
* **Your app code belongs to you** - You retain full ownership and rights to all code created in Draftbit
* **Modern encryption** - Sensitive data like API keys and credentials are stored using industry-standard encryption protocols
* **Secure infrastructure** - Our platform is built on secure, enterprise-grade infrastructure with regular security audits
Who owns the code I create in Draftbit?
You do! All code created in Draftbit belongs entirely to you. Draftbit provides the tools and platform, but you retain full ownership and intellectual property rights to your applications and code.
How are my API keys and sensitive data protected?
Your sensitive data is protected using modern encryption standards:
* API keys and credentials are encrypted at rest using AES-256 encryption
* Data transmission is secured with TLS/SSL encryption
* Access controls ensure only you can view your sensitive information
* We follow industry best practices for data security and privacy
## General Help
[Section titled “General Help”](#general-help)
I’m stuck, what can I do?
First thing you can try is asking the AI for help. If that fails you may find help in our [Community](https://community.draftbit.com) or via [Support Chat](mailto:help@draftbit.com).
We also have a dedicated team of developers — [Draftbit Experts](https://draftbit.com/services/?utm_source=docs\&utm_medium=referral\&utm_campaign=owned-site-acquisition\&utm_content=common-questions-experts) — who can provide hands-on assistance with your project. For plans and pricing, visit [Draftbit Experts](https://draftbit.com/services/?utm_source=docs\&utm_medium=referral\&utm_campaign=owned-site-acquisition\&utm_content=common-questions-experts).
# Creating a New App
> Create a new app in Draftbit
Creating an app project is the first step in building a new app in Draftbit. Get started by clicking the  button on the Dashboard.

Want to start from scratch?
The create flow nudges you to write a reasonably detailed prompt before continuing. If you’d rather skip the prompt and start with an empty project, use the inline **Start with a blank app** option below the prompt box.
#### Provide Details
[Section titled “Provide Details”](#provide-details)
1. **Your App Idea**
Describe your app idea as a story about your app. Include things about your app like who the users will be and whether they’ll need to sign in, what kind of data you’ll need to store, and much more. Will you send push notifications or emails? Does the app require special calculations or business logic? This is where you really want to give the AI as much information about your app as possible.
**Check out the [Writing your initial prompt](/intro/best-practices/writing-your-initial-prompt) doc for helpful info.**
2. **Attach Images**
Here you can upload any design images you have so that AI can incorporate them into it’s work when scaffolding the initial version of your app.
3. **Project Name**
Give your project a name that helps you and your teammates easily identify it in your workspace.
4. **App Category**
Choose a category that your app mostly closely aligns with. This will help the AI understand the type of app you’re trying to build.
5. **Backend and Starter UI**
For mobile apps, choose a Starter UI when prompted so the first build starts from a visual foundation. If your app needs a backend, enable **Auto-create Supabase** during creation so the agent can build against a database, auth, and storage from the beginning.
6. **Click ‘Start Building’**
The AI will analyze your description and create a detailed plan for your app, including screens, features, and data structure. You’ll then see your app being built in real-time, and you can make adjustments as needed.
#### Continue Building
[Section titled “Continue Building”](#continue-building)
After the AI has built the initial version of your app it’ll take you into [the Builder](/features/ai-app-builder) where you can continue chatting with the AI to build your app. Take a look at the [Composing task prompts](/intro/best-practices/composing-task-prompts) doc for helpful advice on getting the most our of your interactions with the AI.
## Quick Start Templates
[Section titled “Quick Start Templates”](#quick-start-templates)

Get started from the Starter UI picker or a pre-built prompt for different types of apps. Starter UIs include polished screen previews so you can choose a visual foundation before the first build begins.
## Common Questions
[Section titled “Common Questions”](#common-questions)
**How long does it take to build an app?**
The initial app generation takes 2-5 minutes. After that, you can continue refining and adding features at your own pace. Most users have a working prototype within 30 minutes.
**Can I use my own data and APIs?**
Absolutely! You can connect to any REST API, GraphQL endpoint, or database. We also provide built-in integrations with popular services like Firebase, Supabase, and Airtable.
[Still have questions? ](/intro/building-with-draftbit/common-questions)Find more answers to common questions about Draftbit
# Getting Started
> Start by understanding the concepts and tools involved in building apps
This document is a deep-dive intended to help you understand the concepts and tools involved in building an app, especially if you’re coming from a non-technical background. While you can dive right into Draftbit and start building immediately, this guide covers important concepts and preparation steps that will make your app development journey much smoother and more successful.
Go at your own pace
You don’t need to complete this guide before you start building—think of it as your reference for understanding what goes into creating a complete app. The more preparation you do upfront, the more successful you’ll be, but feel free to [skip ahead to creating your first app](/intro/building-with-draftbit/creating-a-new-app) or [jump straight into Draftbit](https://next.draftbit.com) and refer back to these sections as needed.
## Define your app concept
[Section titled “Define your app concept”](#define-your-app-concept)
Before you touch any development tools, you need absolute clarity about what you’re building and why. This isn’t just about having a “good idea”—it’s about understanding your app’s purpose, audience, and scope in enough detail that you can make informed decisions throughout the building process.
### Define the problem
[Section titled “Define the problem”](#define-the-problem)
Start by articulating the specific problem your app solves in concrete terms. Avoid vague statements like “people need better organization.” Instead, dig deeper: “Freelance graphic designers struggle to track project deadlines, client communications, and invoice statuses across multiple platforms, leading to missed deadlines and delayed payments.” This level of specificity helps you understand exactly what features your app needs to include.
Next, explain how your app makes this problem disappear or become manageable. Your solution should be simple enough to explain to someone unfamiliar with the problem in under 30 seconds. If you can’t do this clearly, your concept likely needs more refinement before you start building.
### Identify your target users
[Section titled “Identify your target users”](#identify-your-target-users)
Understanding who will use your app is crucial for making design and feature decisions. Create detailed profiles of your ideal users, including their technical comfort level, the devices they typically use, their daily routines, and their pain points. For example, if you’re building a budgeting app for college students, consider that they likely use smartphones primarily, have limited income, may not have credit cards, and probably check social media multiple times per day.
This user research will guide everything from your app’s visual design to its navigation structure. An app for senior citizens will have very different design requirements than one for teenage gamers, and understanding these differences upfront prevents costly redesigns later.
### Map out essential user flows
[Section titled “Map out essential user flows”](#map-out-essential-user-flows)
Think through the complete journey your users will take in your app, from first opening it to achieving their primary goal. Break this down into specific screens and actions. For a meal planning app, this might include: signing up with email, setting dietary preferences, browsing recipe recommendations, adding meals to a weekly calendar, generating a grocery list, and sharing recipes with family members.
Document these flows in simple language, focusing on what the user sees and does at each step. This exercise naturally reveals what screens you’ll need to build and helps you prioritize features for your initial release. It also helps you spot potential usability issues before you start building.
### Plan your feature scope
[Section titled “Plan your feature scope”](#plan-your-feature-scope)
One of the biggest mistakes new app builders make is trying to include every possible feature in their first version. Instead, identify the 3-5 core features that must work perfectly for your app to solve its primary problem. Everything else can wait for future updates.
Use the “MoSCoW” method to categorize features: Must have (core functionality), Should have (important but not critical), Could have (nice additions), and Won’t have (explicitly out of scope for version 1). This framework helps you resist feature creep and ship faster.
### Choose your platforms
[Section titled “Choose your platforms”](#choose-your-platforms)
Deciding whether to launch on iOS, Android, web, or all three affects your development timeline, costs, and user acquisition strategy. Each platform has distinct characteristics that may favor your specific app type and audience.
Web apps (Progressive Web Apps or PWAs) are often the best starting point for new developers because they don’t require app store approval, can be updated instantly, work across all devices, and don’t require users to download anything. They’re perfect for testing your concept and gathering user feedback quickly.
iOS apps reach users who typically have higher spending power and engagement rates, but require a $99/year Apple Developer Program membership and must pass App Store review. Android apps reach a larger global audience and have more lenient review processes, but require managing more device variations and screen sizes.
Consider your target audience’s preferences, your budget for developer accounts, and your timeline for launch when making this decision. Many successful apps start with one platform and expand after proving their concept.
### Use planning tools
[Section titled “Use planning tools”](#use-planning-tools)
Modern planning tools can help you organize your thoughts and create professional documentation for your app concept. [Notion](https://notion.so) excels at creating comprehensive project wikis where you can document user research, feature requirements, and development progress in one searchable location. [Airtable](https://airtable.com) works well for tracking features, user feedback, and development tasks with its spreadsheet-database hybrid approach.
For visual brainstorming and user journey mapping, [Miro](https://miro.com) provides infinite whiteboards where you can create mind maps, user flow diagrams, and collaborate with others in real-time. [FigJam](https://figma.com/figjam/) offers similar capabilities with tight integration to Figma for when you’re ready to create actual designs.
If you want to think through your business model, try the [Lean Canvas](https://leanstack.com/lean-canvas) framework, which helps you document your assumptions about customers, problems, solutions, and revenue streams on a single page. This exercise often reveals important considerations you hadn’t thought of.
For those using Draftbit’s AI features, check out our guides on [Writing your initial prompt](/intro/best-practices/writing-your-initial-prompt) and [Composing task prompts](/intro/best-practices/composing-task-prompts) to get better results from AI assistance.
## Set realistic milestones
[Section titled “Set realistic milestones”](#set-realistic-milestones)
One of the most common mistakes in app development is underestimating the time and effort required to create a polished, successful app. Setting realistic expectations and breaking your project into achievable milestones helps maintain momentum and reduces the risk of abandoning your project when it takes longer than expected.
### Start with an MVP
[Section titled “Start with an MVP”](#start-with-an-mvp)
Your MVP (Minimum Viable Product) should be the simplest version of your app that still solves the core problem for your target users. This isn’t about cutting corners or accepting poor quality—it’s about focusing intensely on the most essential features and polishing them to perfection.
Define your MVP by identifying the smallest set of features that would make a user say “this is useful” rather than “this might be useful someday.” For a fitness tracking app, the MVP might include manual workout logging and basic progress charts, while advanced features like social sharing, nutrition tracking, and workout recommendations can wait for later versions.
The biggest threat to finishing your app is scope creep—the gradual addition of features that seem important but aren’t essential to your core value proposition. Every time you think “it would be nice if the app also did X,” write it down in a “future features” list instead of adding it to your current development plan. Staying disciplined about your MVP boundaries is often the difference between shipping a successful app and getting stuck in endless development.
Building an MVP first offers several advantages: you can test your core assumptions with real users sooner, you’ll ship something rather than getting stuck in endless development, you can gather user feedback to guide future development, and you’ll learn valuable lessons about app development without over-investing in unproven features.
### Plan development phases
[Section titled “Plan development phases”](#plan-development-phases)
Break your app development into distinct phases, each ending with something you can test and evaluate. This phased approach makes the project feel less overwhelming and provides natural checkpoints for gathering feedback and adjusting your direction.
Phase 1 might focus on core functionality without any advanced features. Phase 2 could add user accounts and data persistence. Phase 3 might introduce social features or integrations. Each phase should add meaningful value while building toward your complete vision.
Document what you’ll build in each phase and what you explicitly won’t build until later phases. This documentation helps you resist scope creep and communicate progress to stakeholders or team members.
### Estimate development time
[Section titled “Estimate development time”](#estimate-development-time)
App development almost always takes longer than initial estimates, especially for first-time builders. Even with Draftbit’s visual development tools, you’ll need time for planning, building, testing, refining, and preparing for launch.
Factor in time for activities beyond just building screens: setting up your backend, creating content, testing on multiple devices, preparing app store assets, responding to user feedback, and iterating based on what you learn.
A simple app with basic CRUD (Create, Read, Update, Delete) functionality might take 2-4 weeks to build in Draftbit, while a complex app with real-time features, payment processing, and social elements could take 2-3 months or more.
### Define success metrics
[Section titled “Define success metrics”](#define-success-metrics)
Establish clear, measurable goals for your app’s success that go beyond just “lots of users.” Specific metrics might include user retention rates (what percentage of users return after their first week?), feature usage (are users actually using the main features you built?), or business metrics (revenue, support tickets, user satisfaction scores).
Choose metrics that align with your app’s purpose and your users’ success. A productivity app might measure daily active users and task completion rates, while a social app might focus on user engagement and content creation rates.
Set realistic targets based on industry benchmarks and your app’s scope. A 10% week-1 retention rate might be excellent for some app categories but poor for others. Research typical performance in your app’s category to set appropriate expectations.
### Plan for feedback
[Section titled “Plan for feedback”](#plan-for-feedback)
Build feedback collection into your app from the beginning, whether through simple rating prompts, feedback forms, or analytics that show how users actually navigate your app. User behavior often differs significantly from what you expect during planning.
Plan regular review cycles where you evaluate your progress, user feedback, and key metrics to decide what to work on next. This might be weekly during active development or monthly once your app is launched.
Be prepared to pivot or make significant changes based on what you learn from real users. Some of the most successful apps look very different from their creators’ original visions because they adapted based on user feedback and behavior.
## Create wireframes and designs
[Section titled “Create wireframes and designs”](#create-wireframes-and-designs)
Visual planning might seem like an extra step, but even rough wireframes will save you hours of indecision and backtracking once you start building. You don’t need to be a designer or create pixel-perfect mockups—you just need clarity about your app’s structure and flow.
### Start with wireframes
[Section titled “Start with wireframes”](#start-with-wireframes)
Begin by sketching the basic layout of each screen using simple boxes, lines, and placeholder text. Focus entirely on layout, navigation, and content hierarchy rather than colors, fonts, or visual details. These wireframes should answer questions like: Where does the navigation menu go? How do users get from the home screen to their profile? What information appears on each screen?
You can create wireframes with simple tools like pen and paper, [Balsamiq](https://balsamiq.com) (designed specifically for rough wireframes), or even basic shapes in [Google Slides](https://slides.google.com) or [PowerPoint](https://www.microsoft.com/en-us/microsoft-365/powerpoint). The goal is speed and clarity, not beauty.
Create one wireframe for each major screen in your user flows, then walk through them as if you’re a user trying to complete key tasks. This exercise often reveals missing screens, confusing navigation, or logical gaps in your user experience.
### Choose design tools
[Section titled “Choose design tools”](#choose-design-tools)
When you’re ready to create higher-fidelity designs, choose tools that match your skills and collaboration needs. [Figma](https://www.figma.com) has become the industry standard for digital design because it works in any web browser, makes collaboration effortless, includes a vast library of templates and UI kits, and offers powerful features like auto-layout and component systems. Its free tier is generous enough for most small projects.
[Sketch](https://www.sketch.com) remains popular among Mac users and offers excellent plugin ecosystem, but it’s desktop-only and doesn’t have built-in collaboration features. [Adobe XD](https://www.adobe.com/products/xd.html) integrates well with other Adobe products and includes prototyping features, making it a good choice if you’re already in the Adobe ecosystem.
For beginners, [Canva](https://www.canva.com) now includes basic app mockup templates that can help you visualize your app’s look and feel without learning complex design software. While not as powerful as dedicated design tools, it’s approachable for non-designers.
### Create a design system
[Section titled “Create a design system”](#create-a-design-system)
Before you start designing individual screens, establish the basic visual guidelines that will keep your app looking cohesive. This doesn’t need to be a formal brand guide—just clear decisions about colors, fonts, spacing, and button styles that you’ll use consistently throughout your app.
Choose a primary color that reflects your app’s personality and purpose, plus one or two accent colors for highlights and calls-to-action. Select neutral colors for text, backgrounds, and borders. Keep your palette simple—most successful apps use fewer than six colors total.
Pick fonts that are readable on mobile devices and match your app’s tone. [Google Fonts](https://fonts.google.com) offers hundreds of free options that work well in apps. Generally, choose one font for headings and either the same font or a complementary one for body text.
Define a spacing system using multiples of 4 or 8 pixels (like 8px, 16px, 24px, 32px) to create visual rhythm and consistency. This system will translate perfectly to Draftbit’s Nativewind styling, which uses similar spacing conventions.
### Design for mobile first
[Section titled “Design for mobile first”](#design-for-mobile-first)
Even if you’re planning to launch on web initially, design your screens for mobile devices first. Mobile constraints force you to prioritize content and create cleaner, more focused interfaces. You can always adapt these designs for larger screens later, but starting with desktop designs often leads to cluttered mobile experiences.
Consider how people actually use mobile devices: with their thumbs, often one-handed, frequently while distracted or in motion. Make buttons large enough to tap easily (at least 44 pixels), keep important content in the top two-thirds of the screen, and avoid relying on hover states or right-click interactions.
Test your wireframes and designs on actual devices when possible. Colors and sizes that look perfect on your laptop screen might be too small or hard to read on a phone in bright sunlight.
## Understand app architecture
[Section titled “Understand app architecture”](#understand-app-architecture)
If you’re new to app development, understanding the different components that make up a complete app system will help you make better decisions and communicate more effectively with developers, designers, and service providers. Think of building an app like building a house—you need a solid foundation (backend), beautiful and functional rooms (frontend), and utilities that connect everything (APIs, databases, authentication).
### Frontend (user interface)
[Section titled “Frontend (user interface)”](#frontend-user-interface)
The frontend is your app’s user interface—everything users see and interact with on their devices. In Draftbit, your frontend is built using React Native and Expo, which means you’re creating a truly native mobile app that can access device features like cameras, location services, and push notifications, while also being able to run on the web.
React Native works by translating your app’s interface into the native components of each platform. When you create a button in your Draftbit app, it becomes an actual iOS button on iPhones and an actual Android button on Android devices, ensuring your app feels natural and performant on every platform.
The frontend handles user interactions, displays data from your backend, manages navigation between screens, validates form inputs, and provides feedback to users. It’s also responsible for maintaining application state—remembering what the user was doing when they switch between screens or temporarily lose internet connection.
### Backend (server and data)
[Section titled “Backend (server and data)”](#backend-server-and-data)
The backend is the server-side system that powers your app’s functionality behind the scenes. It’s where your app’s data lives, where business logic gets processed, and where integrations with third-party services happen. Users never see the backend directly, but it’s essential for any app that stores data, has user accounts, or provides personalized experiences.
Your backend typically includes several components working together: a database to store information, authentication systems to manage user accounts and security, APIs that define how your frontend communicates with the backend, file storage for images and documents, and serverless functions for custom business logic.
Think of your backend as a restaurant’s kitchen: customers (your app users) never see it, but it’s where all the food (data) gets prepared and organized before being served. A well-designed backend can handle many customers simultaneously while keeping everything organized and secure.
### Database storage
[Section titled “Database storage”](#database-storage)
The database is your app’s long-term memory, storing everything from user profiles to content, settings, and transaction records. Choosing the right type of database depends on your app’s needs, but most modern apps use either SQL databases (like PostgreSQL) for structured data with complex relationships, or NoSQL databases (like MongoDB) for flexible, document-based storage.
For beginners, SQL databases are often easier to understand because they organize data in tables with clear relationships, much like spreadsheets. NoSQL databases offer more flexibility but can be harder to structure properly without experience.
When planning your database, think about what information your app needs to remember: user profiles, content they create, their preferences and settings, relationships between users, and any business data specific to your app’s purpose. Sketch out how these pieces of information relate to each other—this will help you structure your database efficiently.
### APIs and communication
[Section titled “APIs and communication”](#apis-and-communication)
APIs (Application Programming Interfaces) are the communication channels between your app’s frontend and backend. They define what requests your app can make (like “get user profile” or “save new post”) and what format the responses will take. Think of APIs as a menu in a restaurant—they tell you what you can order and how it will be served.
Most modern apps use REST APIs, which organize endpoints around resources (like users, posts, or orders) and use standard HTTP methods (GET to retrieve data, POST to create new data, PUT to update existing data, DELETE to remove data). GraphQL is an alternative that allows more flexible queries but has a steeper learning curve.
Good API design makes your app faster and more reliable by minimizing unnecessary data transfer and providing consistent, predictable responses. When working with external services like payment processors or email providers, you’ll integrate with their APIs to add functionality without building everything from scratch.
### User authentication
[Section titled “User authentication”](#user-authentication)
Authentication systems handle user registration, login, password security, and session management. This is one of the most critical aspects of your app’s security, so it’s usually better to use established services rather than building your own from scratch.
Modern authentication systems support multiple login methods: traditional email and password, social logins (Google, Apple, Facebook), passwordless options (magic links sent via email), and two-factor authentication for enhanced security. Consider your users’ preferences and technical comfort when choosing which options to offer.
User roles and permissions determine what different types of users can see and do in your app. A basic app might just distinguish between regular users and administrators, while a complex platform might have dozens of different permission levels. Plan these roles early, as they affect how you design both your database and your user interface.
### File storage
[Section titled “File storage”](#file-storage)
If your app allows users to upload photos, documents, or other files, you’ll need a system for storing and serving these files efficiently. This includes handling different file types and sizes, creating thumbnails for images, ensuring files are backed up and secure, and delivering them quickly to users around the world.
Modern file storage services like [AWS S3](https://aws.amazon.com/s3/), [Google Cloud Storage](https://cloud.google.com/storage), or [Cloudinary](https://cloudinary.com) handle the technical complexity of file management while providing features like automatic image optimization, content delivery networks (CDNs) for fast global access, and secure upload directly from your app.
Plan for how much storage you’ll need and what types of files your app will support. Consider file size limits, acceptable formats, and whether you need features like image editing or video processing.
### Serverless functions
[Section titled “Serverless functions”](#serverless-functions)
Serverless functions are small pieces of code that run in response to specific events, like when a user signs up, makes a purchase, or needs to send an email. They’re called “serverless” because you don’t need to manage servers—the cloud provider handles all the infrastructure automatically.
These functions are perfect for tasks that don’t fit neatly into your main app logic: sending welcome emails, processing payments, generating reports, integrating with third-party services, or running scheduled tasks like backup operations.
Popular serverless platforms include [Vercel Functions](https://vercel.com/docs/functions), [Netlify Functions](https://www.netlify.com/products/functions/), [AWS Lambda](https://aws.amazon.com/lambda/), and [Supabase Edge Functions](https://supabase.com/docs/guides/functions). Many backend-as-a-service platforms include serverless functions as part of their offering.
### Choose a backend platform
[Section titled “Choose a backend platform”](#choose-a-backend-platform)
For most new app builders, using a Backend-as-a-Service (BaaS) platform is much faster and more reliable than building a custom backend from scratch. These platforms provide databases, authentication, file storage, and serverless functions in one integrated package, letting you focus on your app’s unique features rather than infrastructure management.
**Supabase** is an excellent choice if you’re comfortable with SQL databases or want to learn them. Built on [PostgreSQL](https://www.postgresql.org), it provides a powerful database with built-in authentication, real-time subscriptions, file storage, and edge functions. Supabase’s dashboard makes it easy to design database tables, set up user authentication, and manage your app’s data through a web interface. Their Row Level Security (RLS) feature automatically protects user data based on rules you define, making your app secure by default. Supabase also offers generous free tiers and transparent pricing as you scale.
**Xano** takes a visual, no-code approach to backend development, making it ideal if you prefer designing systems graphically rather than writing code or SQL queries. Xano’s visual API builder lets you create complex business logic using flowcharts and drag-and-drop interfaces. It includes database design tools, authentication systems, and integrations with popular services like [Stripe](https://stripe.com) for payments. While more expensive than some alternatives, Xano can significantly speed up development for non-technical builders.
Other options include **[Firebase](https://firebase.google.com)** (Google’s platform with excellent real-time features) and **[AWS Amplify](https://aws.amazon.com/amplify/)** (powerful but complex). Choose based on your technical comfort level, budget, and specific feature requirements.
## Know the tech stack
[Section titled “Know the tech stack”](#know-the-tech-stack)
Understanding the technologies that power Draftbit apps helps you make better design and development decisions, troubleshoot issues more effectively, and extend your app’s capabilities when needed. Don’t worry—you don’t need to become an expert in these technologies, but knowing their strengths and purposes will make you a more effective app builder.
### React Native
[Section titled “React Native”](#react-native)
React Native is the foundation that makes Draftbit apps possible. Created by Facebook (now Meta) and used by companies like Instagram, Airbnb, and Shopify, React Native lets developers build truly native mobile apps using web technologies like [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript) and [React](https://react.dev).
Unlike web apps that run in a browser or hybrid apps that wrap web content in a native container, React Native apps compile to actual native code. This means your Draftbit app will have the same performance, look, and feel as apps built with platform-specific tools like Swift for iOS or Kotlin for Android.
React Native’s “learn once, write anywhere” philosophy means you can build for iOS, Android, and web from a single codebase. This dramatically reduces development time and maintenance overhead compared to building separate native apps for each platform.
The React Native ecosystem includes thousands of community-built packages for adding functionality like maps, payment processing, social authentication, and device sensors. When you need to extend your Draftbit app beyond the built-in components, you can often find existing solutions rather than building from scratch.
### Expo platform
[Section titled “Expo platform”](#expo-platform)
Expo is a comprehensive toolset and runtime that sits on top of React Native, providing a standardized development environment and extensive set of pre-built components and APIs. Think of Expo as a curated collection of tools and libraries that eliminates much of the complexity typically involved in React Native development.
The Expo SDK includes a vast library of modules for accessing device features like cameras, sensors, file systems, and notifications. These modules are designed to work consistently across iOS, Android, and web platforms, so you don’t need to write platform-specific code or manage native dependencies yourself.
Expo also provides a standardized project structure and configuration system that simplifies the development workflow. Instead of dealing with complex native build configurations, you work within Expo’s managed environment where the toolchain handles platform-specific implementations automatically.
For Draftbit users, this means your apps benefit from Expo’s extensive ecosystem of tested, maintained components without requiring deep knowledge of native iOS or Android development. The result is faster development cycles and more reliable cross-platform functionality.
### Nativewind styling
[Section titled “Nativewind styling”](#nativewind-styling)
Nativewind brings the popular [Tailwind CSS](https://tailwindcss.com) utility framework to React Native, providing a fast, consistent approach to styling your Draftbit apps. If you’ve used Tailwind CSS for web development, you’ll feel right at home with Nativewind’s class-based styling system.
Utility-first CSS means that instead of writing custom CSS for each component, you compose styles using small, single-purpose utility classes. For example, instead of creating a custom “button” style, you might use classes like `bg-blue-500 text-white px-4 py-2 rounded-lg` to create a blue button with white text, padding, and rounded corners.
This approach has several advantages for app development: it’s faster than writing custom styles, creates more consistent designs, makes it easier to maintain and update styles across your entire app, and provides excellent performance because unused styles are automatically removed from your final app bundle.
Nativewind’s classes are designed to be responsive and work well on different screen sizes. You can easily create layouts that adapt to phones, tablets, and desktop screens using responsive prefixes like `sm:`, `md:`, and `lg:`.
The utility system also makes it easy to implement dark mode, accessibility features, and platform-specific styling. Nativewind handles the differences between iOS, Android, and web platforms automatically, so your styles work consistently everywhere.
### Integrated tooling
[Section titled “Integrated tooling”](#integrated-tooling)
What makes Draftbit special isn’t just these individual technologies, but how they work together seamlessly. Draftbit’s visual builder generates clean React Native code styled with Nativewind utilities. The AI assistant understands these technologies and can help you implement complex features using best practices.
When you export your Draftbit project, you get a standard Expo React Native app that you can continue developing with any React Native tools and libraries. This means you’re never locked into Draftbit’s platform—you can always take your code and continue development elsewhere if needed.
This technology stack is battle-tested by thousands of production apps and backed by strong communities and extensive documentation. When you need help or want to learn more, you’ll find abundant resources, tutorials, and community support for each component.
## Gather your assets
[Section titled “Gather your assets”](#gather-your-assets)
Having your content, images, and other assets prepared before you start building keeps you in a productive flow and helps you make realistic design decisions. Nothing slows down development like stopping to search for the right image or writing placeholder text that you forget to replace later.
### Brand and visual assets
[Section titled “Brand and visual assets”](#brand-and-visual-assets)
Your app’s visual identity starts with your app name, which should be memorable, easy to spell, and available as a domain name and social media handles. Check trademark databases to ensure you’re not infringing on existing brands, especially if you plan to commercialize your app.
Create or commission a professional app icon that works at various sizes, from large promotional images down to tiny notification icons. Your icon should be simple enough to recognize at 16x16 pixels but distinctive enough to stand out among thousands of other apps. Design your icon as a vector graphic first (in Illustrator, Figma, or Sketch) so you can export it at any size without quality loss.
Develop a simple color palette that reflects your app’s purpose and personality. Limit yourself to 2-3 primary colors plus neutral grays and whites. Test your colors for accessibility by ensuring sufficient contrast between text and backgrounds—tools like [WebAIM’s Contrast Checker](https://webaim.org/resources/contrastchecker/) can help verify your combinations meet accessibility standards.
Choose fonts that match your app’s tone and are highly readable on mobile devices. [Google Fonts](https://fonts.google.com) provides hundreds of free, high-quality typefaces that work well in apps. Generally, select one font family for headings and either the same family or a complementary one for body text. Avoid using more than two font families in a single app.
### Content and copywriting
[Section titled “Content and copywriting”](#content-and-copywriting)
Plan your app’s text content carefully, as clear, helpful copy can make the difference between user success and frustration. Start with user-facing content like onboarding instructions, button labels, form field labels, error messages, and empty state descriptions.
Write in your users’ language, avoiding technical jargon unless your audience expects it. Keep sentences short and actionable, especially for buttons and calls-to-action. Instead of generic labels like “Submit” or “OK,” use specific language like “Create Account” or “Save Changes” that clearly describes what will happen.
Error messages deserve special attention because they appear when users are already frustrated. Write helpful error messages that explain what went wrong and how to fix it. Instead of “Error 400: Bad Request,” write “Please enter a valid email address” or “Your password must be at least 8 characters long.”
Plan empty states—the screens users see before they’ve added any content. These moments are opportunities to educate users about your app’s benefits and guide them toward their first successful action. Include clear instructions and maybe a sample or template to get them started.
### Images and media
[Section titled “Images and media”](#images-and-media)
Collect and optimize all images you’ll need in your app, including photos, illustrations, icons, and graphics. Optimize images for mobile devices by balancing file size with visual quality—large images slow down your app and consume users’ data allowances.
Use modern image formats like WebP when possible, which provide better compression than JPEG while maintaining quality. For simple graphics and icons, consider SVG format, which stays crisp at any size and has small file sizes.
Plan for different screen densities by preparing images at multiple resolutions. Mobile devices have varying pixel densities, so you’ll typically need images at 1x, 2x, and 3x resolutions to look sharp on all devices.
Include alt text descriptions for all images to make your app accessible to users with visual impairments. Alt text should describe the image’s content and purpose, not just its appearance.
### API docs and test data
[Section titled “API docs and test data”](#api-docs-and-test-data)
If your app connects to external services or your own backend, document all the API endpoints, authentication methods, and data formats you’ll be working with. This documentation becomes essential when setting up data connections in Draftbit.
Create test data that represents realistic scenarios your users will encounter. This includes user profiles with various combinations of information, sample content in different lengths and formats, and edge cases like users with very long names or empty profiles.
Set up test accounts for any third-party services you’ll integrate, such as payment processors, email services, or social media platforms. Having these accounts ready with test credentials saves time during development and lets you verify integrations work correctly.
### Security and credentials
[Section titled “Security and credentials”](#security-and-credentials)
Plan how you’ll manage API keys, database credentials, and other sensitive information. Never hardcode these values directly in your app—use environment variables and secure credential management systems instead.
Create separate sets of credentials for development, testing, and production environments. This separation prevents accidentally affecting real users with test data and lets you experiment safely during development.
Document which credentials your app needs and where to find them. This documentation helps when you’re setting up deployments or when team members need access to the same services.
### Legal and compliance
[Section titled “Legal and compliance”](#legal-and-compliance)
Draft your app’s Privacy Policy and Terms of Service, which are required by app stores and many third-party services. While you can start with templates from services like [Termly](https://termly.io) or [Privacy Policy Generator](https://www.privacypolicygenerator.info), customize them to accurately reflect your app’s data collection and usage practices.
If your app targets users in specific regions, research relevant data protection regulations like [GDPR](https://gdpr.eu/what-is-gdpr/) (Europe), [CCPA](https://oag.ca.gov/privacy/ccpa) (California), or other local privacy laws. These regulations affect how you collect, store, and process user data.
Consider your app’s content rating and target age group, as these affect app store approval and marketing restrictions. Apps targeting children have additional privacy and safety requirements that must be addressed during development.
## Prepare for publishing
[Section titled “Prepare for publishing”](#prepare-for-publishing)
If you plan to distribute your app through Apple’s App Store or Google Play Store, you’ll need developer accounts and should understand the submission process before you start building. Getting these accounts set up early prevents delays when you’re ready to launch.
### Apple Developer Program
[Section titled “Apple Developer Program”](#apple-developer-program)
Publishing iOS apps requires membership in the Apple Developer Program, which costs $99 per year for individuals or $299 per year for organizations. This membership allows you to test your app on real iOS devices, access beta versions of iOS for testing, and distribute your app through the App Store or TestFlight for beta testing.
**Get started:** Enroll in the [Apple Developer Program](https://developer.apple.com/programs/enroll/) to begin the registration process.
The enrollment process can take several days to complete, especially for organizations, which may need to provide business verification documents and [D-U-N-S numbers](https://www.dnb.com/duns-number.html). Apple requires that the legal entity name on your developer account matches your business registration exactly, so ensure your paperwork is in order before applying.
Once enrolled, you’ll need to create App IDs, provisioning profiles, and certificates for code signing. Draftbit’s publishing tools can help automate much of this process, but understanding the basics helps you troubleshoot issues when they arise.
Apple’s App Store has strict review guidelines covering content, functionality, design, and business models. Review the complete [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) early to avoid rejection. Common rejection reasons include incomplete functionality, poor user interface design, inappropriate content, and apps that replicate existing Apple features without adding significant value.
### Google Play Console
[Section titled “Google Play Console”](#google-play-console)
Publishing Android apps requires a Google Play Console account, which has a one-time registration fee of $25. This account lets you upload app bundles, manage store listings, track user reviews and analytics, and distribute your app to billions of Android devices worldwide.
**Get started:** Sign up for the [Google Play Console](https://play.google.com/console/signup) and complete the registration process.
Google’s review process is generally faster and more lenient than Apple’s, but they still enforce policies around content, functionality, and user safety. Review the [Google Play Policy Center](https://support.google.com/googleplay/android-developer/topic/9877467) to understand their requirements. Google Play Protect scans all apps for malware and policy violations, both during review and after publication.
One advantage of Android publishing is the ability to release apps to smaller groups of users first through internal testing, closed testing, or open testing tracks. This staged rollout approach lets you catch issues and gather feedback before making your app available to everyone.
Google Play Console also provides detailed analytics about your app’s performance, user engagement, crash reports, and revenue (if you’re selling your app or offering in-app purchases). These insights are valuable for improving your app over time.
### Web deployment
[Section titled “Web deployment”](#web-deployment)
Web apps (PWAs) don’t require app store approval and can be deployed immediately to any web hosting service. However, if you want your app to have a professional appearance and be easily discoverable, you should register a custom domain name.
Choose a domain that’s easy to remember, spell, and type on mobile devices. Avoid numbers, hyphens, and confusing spellings. Consider registering multiple extensions (.com, .app, .io) to protect your brand, though .com remains the most trusted and memorable for most users.
Popular domain registrars include [Namecheap](https://www.namecheap.com), [Google Domains](https://domains.google.com), and [Cloudflare](https://www.cloudflare.com). Many also provide DNS management and SSL certificates, which you’ll need for a professional web app deployment.
For hosting, services like [Vercel](https://vercel.com), [Netlify](https://www.netlify.com), and [Cloudflare Pages](https://pages.cloudflare.com) offer excellent performance, automatic SSL certificates, and seamless integration with code repositories for automatic deployments.
### Prepare store assets
[Section titled “Prepare store assets”](#prepare-store-assets)
Both Apple and Google require specific assets for your app store listings: app icons in multiple sizes, screenshots for different device types, promotional graphics, and descriptive text. Preparing these assets before you submit saves time and reduces the chance of rejection.
App icons should be simple, recognizable at small sizes, and consistent with your brand identity. Apple requires icons without rounded corners or shadows (they add these automatically), while Google allows more decorative elements. Create your icon in vector format first, then export to the required pixel dimensions.
Screenshots should showcase your app’s key features and benefits clearly. Both stores allow you to add text overlays to explain functionality, which is especially helpful for complex apps. Take screenshots on the largest devices first (iPhone Pro Max, large Android phones), then crop or adapt for smaller sizes.
Write compelling app descriptions that clearly explain what your app does, who it’s for, and why users should download it. Use keywords that your target audience might search for, but avoid keyword stuffing, which both stores penalize. Focus on benefits rather than features—explain how your app improves users’ lives rather than just listing what it can do.
For more on publishing, see the [Publishing overview](/features/publishing).
## Your next steps
[Section titled “Your next steps”](#your-next-steps)
With all this preparation in place, you’re ready to begin building your app with confidence. Start by setting up your backend in Supabase or Xano and gathering the API credentials you’ll need for your Draftbit project. This backend setup often takes longer than expected, so tackling it early prevents delays later.
Create your wireframes and gather your brand assets while your backend is being set up. Having these visual guides ready makes the building process much faster and helps you make consistent design decisions.
If you’re planning to publish on mobile app stores, begin the developer account enrollment process now. Both Apple and Google accounts can take several days to approve, and you don’t want publishing delays when your app is ready to launch.
Finally, open Draftbit and start building your first screen. Begin with the most important user flow in your app—usually the main functionality that solves your users’ primary problem. Build this flow completely before moving on to secondary features.
Remember that building a successful app is an iterative process. Your first version won’t be perfect, and that’s completely normal. Focus on creating something valuable for your users, ship it, gather feedback, and improve continuously. The goal isn’t perfection—it’s progress toward solving real problems for real people.
The preparation you’ve done following this guide puts you ahead of most first-time app builders. You have clarity about what you’re building, understand the technology involved, and have realistic expectations about the development process. Now it’s time to bring your app to life.
# Importing an existing app
> Import your original Draftbit app into the new Builder
If you have an existing app built using the original ‘Classic’ Draftbit, you can import your app into the new [AI-powered app builder](/features/ai-app-builder). Select the  tab from the menu on the [Dashboard](https://next.draftbit.com/dashboard) then select the app you’d like to import.

Expo Router
The app that you’re importing needs to have Expo Router enabled. If your app doesn’t have Expo Router already enabled, you’ll see an  button to enable it before you can start to import process.
Once you locate the app you’d like to import, click the  button to start the import process.
Your app code will be generated and packaged-up along with any image assets you have, then downloaded into your workspace. Once your app is imported, you can work on it using the [AI app builder](/features/ai-app-builder) or in the [code editor](/features/code-editor).
The import process can take several minutes depending on the size of the app you are importing. You can navigate away and come back to check on progress.
# Importing from GitHub
> Import an existing codebase into Draftbit from a GitHub repository or zip file
If you already have a codebase somewhere else, you don’t have to start over in Draftbit. You can import it directly from a GitHub repository or from a zip file, then keep building on it with the [AI-powered app builder](/features/ai-app-builder).
## Start the import
[Section titled “Start the import”](#start-the-import)
From the [Dashboard](https://next.draftbit.com/dashboard), click **Create New Project**, then select the **Import** option.

Choose where your code lives:
* **Private GitHub Repo** — connect your GitHub account to import a private repository.
* **Public GitHub Repo** — paste the URL of any public repository.
* **Upload a zip file** — upload your project as a zip archive.
Monorepos are supported too — just point Draftbit at the app’s folder in the next step.
What can be imported
* JavaScript or TypeScript apps with a `package.json` file.
* Expo mobile apps, Vite web apps, and Astro sites get the full Draftbit experience.
* Other JavaScript frameworks, like Next.js, Remix, or SvelteKit, import with your setup preserved.
What can’t be imported
* Native iOS (Swift) and Android (Kotlin or Java) apps.
* Flutter, React Native for Windows or macOS, and other non-JavaScript stacks.
* Projects without a `package.json`, or repos with several apps and no folder chosen.
## Locate the repository
[Section titled “Locate the repository”](#locate-the-repository)
Paste the repository address. Draftbit checks that it holds an app it can import before you continue.

Open **Advanced options** if you need to import from a specific branch, or from a subfolder of the repository (useful for monorepos).

## Name your app and choose how to import it
[Section titled “Name your app and choose how to import it”](#name-your-app-and-choose-how-to-import-it)
Once your repository passes the checks, name the project and app, then choose how Draftbit should bring it in:

* **Import & migrate to Draftbit conventions** — an agent rewrites your code to fit Draftbit’s conventions, which unlocks the full builder. You approve the migration plan before anything changes. This option is only available when your app is detected as **Expo, Vite, or Astro** — Draftbit doesn’t yet have an automated migration path for other frameworks.
* **Import & preserve existing setup** — your files stay exactly as they are. You still get chat, code editing, and preview, but without the full builder feature set.
* **Connect directly to repo** — work from your own repository without importing it. *(Coming soon.)*
## Review and import
[Section titled “Review and import”](#review-and-import)
Check the details before importing — the source, repository, branch, detected framework, and import method. You can go back and change any of them.

Click **Import app** to start. Draftbit fetches your code, creates the app, and sets up your workspace — this usually takes under a minute.

## Running the migration
[Section titled “Running the migration”](#running-the-migration)
If you chose **Import & migrate to Draftbit conventions**, you’ll be walked through a short setup wizard once the import finishes (naming, AI Gateway routing, agent defaults) before reaching the migration step:

Click **Migrate my project** to kick off the agent — it plans the migration, then works through it step by step, aligning routing, styling, and config, and fixing type and lint errors. You can keep chatting with it while the migration runs. Or click **Skip** to hold off on migrating for now and keep working with the app as imported.
If you chose **Import & preserve existing setup**, your project skips this step entirely and keeps its original structure.
# Useful Links
> Links to useful resources
## Expo
[Section titled “Expo”](#expo)
* [Expo Documentation](https://docs.expo.dev/)
* [Expo CLI](https://docs.expo.dev/workflow/expo-cli/)
* [Expo SDK](https://docs.expo.dev/versions/latest/)
## React Native
[Section titled “React Native”](#react-native)
* [React Native Documentation](https://reactnative.dev/docs/getting-started)
* [React Native CLI Quickstart](https://reactnative.dev/docs/environment-setup)
* [React Native Components](https://reactnative.dev/docs/components-and-apis)
* [React Native Community GitHub](https://github.com/react-native-community)
* [Awesome React Native (Curated List)](https://github.com/jondot/awesome-react-native)
## Nativewind
[Section titled “Nativewind”](#nativewind)
* [NativeWind Documentation](https://www.nativewind.dev/)
* [NativeWind GitHub Repository](https://github.com/marklawlor/nativewind)
* [NativeWind Installation Guide](https://www.nativewind.dev/quick-starts/expo)
* [NativeWind Recipes](https://www.nativewind.dev/recipes)
* [NativeWind Troubleshooting](https://www.nativewind.dev/troubleshooting)
## Free Courses
[Section titled “Free Courses”](#free-courses)
* [React Native with Expo (Codecademy)](https://www.codecademy.com/learn/learn-react-native-expo)
# Common Issues
> Quick fixes for the most frequently reported problems
This page collects fixes for issues we hear about most often. If you don’t see your problem here, ask in the in‑app support chat or post in the [Community](https://community.draftbit.com).
## Preview won’t load or is stuck
[Section titled “Preview won’t load or is stuck”](#preview-wont-load-or-is-stuck)
The preview sandbox can occasionally enter a stuck state, especially after large changes or package additions.
* Click **Restart Preview** in the preview toolbar before asking the agent to “fix it again.” Restarting is usually faster — and free — compared to letting the agent retry.
* If the preview reports `running (with errors)`, expand the [Logs](/features/preview-logs) panel to see which file failed. Errors there are often a quick syntax or import fix.
* If you’ve just added or removed a package, you may need a [new native build](/features/publishing#native-previews) to pick it up.
If the Builder offers a static preview fallback, use it to inspect the last working state while the agent fixes the live preview.
## Agent runs in a fix-it loop
[Section titled “Agent runs in a fix-it loop”](#agent-runs-in-a-fix-it-loop)
If you find yourself sending “fix it” → “still broken” → “try again,” you’re likely paying for the same context to be re‑processed.
* Stop, read the most recent error in [Logs](/features/preview-logs) or the chat output, and send a single targeted message describing the actual error.
* If the thread has more than \~15 messages, [start a fresh thread](/features/ai-app-builder#ai-chat) with a short summary of the current state plus the specific error.
* See [Using Credits Efficiently](/intro/best-practices/using-credits-efficiently#preview--build-credit-awareness) for the full playbook.
## ”Module not found” or import errors
[Section titled “”Module not found” or import errors”](#module-not-found-or-import-errors)
Most often this means a file was moved or renamed, or a package wasn’t installed.
* For a missing package, ask the agent to add it — it will install via `npm` and update `app.json` if needed. See the [Adding Packages with AI Chat](/guides/adding-packages-with-ai-chat) guide.
* For a missing file, check the path in the import. Imports are case‑sensitive — `./userProfile` and `./UserProfile` are different files on the build server even if they look the same on macOS.
## Save is blocked due to syntax errors
[Section titled “Save is blocked due to syntax errors”](#save-is-blocked-due-to-syntax-errors)
The [Code Editor](/features/code-editor#syntax-validation-on-save) checks every file for syntax errors before saving. If save is blocked, look for the inline diagnostic in the gutter and fix the highlighted line, then save again.
## Environment variable is not available in code
[Section titled “Environment variable is not available in code”](#environment-variable-is-not-available-in-code)
Open [Build Config](/features/build-config) and verify:
* the variable name matches exactly, including capitalization
* plain text Expo variables use the `EXPO_PUBLIC_` prefix
* the value is enabled for the environment you are previewing or publishing
* sensitive variables are only used from build-time configuration files, not runtime app code
After changing variables that affect builds, restart the preview or create a new native preview build.
## Agent stopped because credits ran out
[Section titled “Agent stopped because credits ran out”](#agent-stopped-because-credits-ran-out)
Open your account credit page to review your balance and usage. You can buy more credits, upgrade your plan, earn bonus credits, or switch eligible threads to a connected BYOK provider or subscription.
If you are using your own API key or subscription, check the provider message in chat. Draftbit shows provider-specific usage-limit and authentication errors when the issue comes from OpenAI, Anthropic, OpenRouter, Claude, or Codex.
## Native build fails on iOS or Android
[Section titled “Native build fails on iOS or Android”](#native-build-fails-on-ios-or-android)
* Confirm your publishing config is complete on the [Publishing](/features/publishing) page (App Store Connect / Play Console credentials, signing key).
* If credentials look corrupted (e.g., signing key error after a key rotation), use the **Reset credentials** action on the publishing config to regenerate certificates or re‑upload the signing key.
* If a build started but never finished, check the build log on the **Publishing** page for the actual error.
* If generated mobile publishing credentials are broken, use the reset options in the publishing configuration and publish again.
## Integration says connected but the agent cannot use it
[Section titled “Integration says connected but the agent cannot use it”](#integration-says-connected-but-the-agent-cannot-use-it)
Open [Integrations](/features/integrations) and check the integration status. If the connection is not ready, reconnect or reauthenticate it.
For MCP integrations, make sure any required upstream service settings are enabled. For example, Xano MCP connections require realtime resources on the Xano instance.
## App preview works but the published app is broken
[Section titled “App preview works but the published app is broken”](#app-preview-works-but-the-published-app-is-broken)
The published app uses the values in [App Config](/features/app-configuration) (bundle identifier, scheme, icons, splash, etc.), not the project Settings. If a setting only shows up after publishing, double-check **App Config**.
## Browser issues in the Builder itself
[Section titled “Browser issues in the Builder itself”](#browser-issues-in-the-builder-itself)
* Use Chrome, a Chromium-based browser, or Firefox. Safari has known compatibility limitations.
* Disable ad-blockers or privacy extensions for `draftbit.com` if the Builder fails to load assets or the agent can’t reach the sandbox.
* If a screen is blank, do a hard reload (`Cmd/Ctrl + Shift + R`) and check the browser console for errors.
## Still stuck?
[Section titled “Still stuck?”](#still-stuck)
* Open in‑app support chat from the **Get Help** button in the top bar.
* For credit-related issues, see [When credits seem too high](/intro/account/credits#when-credits-seem-too-high).
* For known platform limits, see [Known Limitations](/intro/troubleshooting/known-limitations).
# Known Limitations
> Capabilities and constraints to be aware of in the current Draftbit release
These are the constraints we hear about most often. Many of them are temporary and being actively worked on — check the [Updates](https://next.draftbit.com/whats-new) page for the latest.
## Platform support
[Section titled “Platform support”](#platform-support)
* Apps build for **iOS, Android, and the web** from a single React Native + [Expo](https://docs.expo.dev/) codebase. Desktop‑native targets (macOS, Windows, Linux) are not supported.
* The Builder UI itself is supported in modern Chromium browsers and Firefox. Safari and embedded webviews may work but are not officially supported.
## Importing existing projects
[Section titled “Importing existing projects”](#importing-existing-projects)
* You can import apps from [Draftbit Classic](https://draftbit.com) (v1) and start new apps based on React Native / Expo.
* Importing an arbitrary GitHub repo is **not supported** — projects need to start in Draftbit. See the [Common Questions](/intro/building-with-draftbit/common-questions) page for the latest on this.
## Code editor
[Section titled “Code editor”](#code-editor)
* The [Code Editor](/features/code-editor) supports JavaScript, TypeScript, JSX, JSON, and Markdown. Other languages (PHP, Python, C#, native iOS/Android source, etc.) aren’t recognized for autocomplete or linting.
* Manual code edits are gated to paid plans. The Free plan can browse and view code but not save edits.
## AI agents and models
[Section titled “AI agents and models”](#ai-agents-and-models)
* The default agents are **Claude Code** (Anthropic) and **Codex** (OpenAI). Google Gemini is on the roadmap.
* If you connect [your own provider keys](/features/agent-instructions#provider-keys-byok), model availability follows what your account allows on that provider — Draftbit doesn’t impose a separate model gate.
* When you use your own API key or subscription, your provider’s usage limits, rate limits, model availability, and authentication rules still apply.
## Credits and billing
[Section titled “Credits and billing”](#credits-and-billing)
* Daily and subscription credits do **not** roll over once they expire. Subscription credits have a 30‑day grace period after the end of the billing cycle in which they were issued. See [Credits](/intro/account/credits) for full rules.
* Bonus and grant credits don’t expire but are spent last.
## Publishing
[Section titled “Publishing”](#publishing)
* One-click iOS and Android publishing requires complete credentials in the [Publishing](/features/publishing) configuration. Without them you can still export your code and publish manually.
* Custom domains for [web publishing](/features/publishing/one-click-publishing/web-publishing) are supported, but the registrar must allow CNAME or `A` records pointing to Draftbit. Some registrars restrict this on entry-level plans.
* Native iOS and Android previews need a new native preview build when you add, remove, or change packages that include native code.
* Apple and Google still control app review, policy decisions, account requirements, tester setup, and public release timing.
## Build Config
[Section titled “Build Config”](#build-config)
* Sensitive values in [Build Config](/features/build-config) are intended for build-time configuration and server-side tooling. They are not exposed to compiled app runtime code.
* Use plain text `EXPO_PUBLIC_` variables only for values that are safe to include in the app bundle.
## Integrations
[Section titled “Integrations”](#integrations)
* The MCP and REST API connectors only run while a chat thread is active. They are not a substitute for backend services your published app can talk to directly — for that, configure your app to call the same endpoints over the network.
* A handful of MCP integrations are still labeled **Coming Soon** on the [Integrations](/features/integrations) page (Firebase, Figma at the time of writing). These will move to GA when their connectors stabilize.
* MCP, REST, GraphQL, Supabase, Canva, and publishing integrations can fail when the upstream service is down, credentials expire, required permissions are missing, or the external API changes.
## Imported Draftbit Classic apps
[Section titled “Imported Draftbit Classic apps”](#imported-draftbit-classic-apps)
Imported apps can include legacy variables, REST services, theme structures, or signing assumptions from the original project. Draftbit exposes tools for managing these pieces, but complex apps may need manual cleanup before previewing or publishing reliably.
## Collaboration
[Section titled “Collaboration”](#collaboration)
* Real-time collaboration shows live presence avatars in the top bar, but multi-user editing of the same screen at the same time can produce conflicts. We try to surface them clearly when they happen — when in doubt, save your changes first and reload.
## Reporting a limitation we should fix
[Section titled “Reporting a limitation we should fix”](#reporting-a-limitation-we-should-fix)
If you hit something that feels like a missing feature rather than a bug, the fastest path is the in‑app support chat (**Get Help** in the top bar) or the [Roadmap](https://next.draftbit.com/roadmap), where you can upvote items so we know what to prioritize.