# AI App Store Reviewer Source: https://docs.rork.com/ai-app-store-reviewer Rork reads your iOS build against the App Store Review Guidelines before Apple does, and reports each rejection risk with its guideline number, the evidence behind it, and a suggested fix.

The whole flow: open More → App Store → App Review, press Run, and read the report.

Apple's review takes days, and a rejection costs you another round trip. The **AI App Store Reviewer** reads the build you are about to submit and tells you what a reviewer is likely to flag, before you send it. It checks five areas at once, the same five sections the App Store Review Guidelines use:
Safety Guideline 1.x
Performance Guideline 2.x
Business Guideline 3.x
Design Guideline 4.x
Legal Guideline 5.x
The reviewer is advisory. It never blocks a submission and it never promises an approval. Apple makes the final decision, and Apple's own review still takes days. ## What you need * A paid Rork subscription of any tier. Credits do not substitute for a subscription here. * Editor access to the project. Viewers can open the panel and read past reports, but cannot start a review. * An iOS app in the project: a Swift app, or an older Expo project. Android and web apps are not reviewed. ## Run a review In your project, open **More → App Store** and stay on the **App Review** tab. It is the first tab. The reviewer does not live in the publish menu. Under the title you see the app name and the build being reviewed, for example `Current build src_62bb`. Before the first run the panel lists the five areas it covers. AI App Store Reviewer panel showing Check this build for App Review risks with Safety, Performance, Business, Design and Legal All five areas are checked at the same time. **Run** becomes **Stop**, which cancels the review. You can leave the tab and come back while it works. Review running with a spinner next to Safety, Performance, Business, Design and Legal When the run ends, the header switches to the build it looked at, for example `Reviewed build src_62bb`, and how long ago the review finished. Report showing no rejection risks found, zero rejections, zero warnings and five passed areas ## Read the report The report has one row per review area, not one row per rule. Each row ends as **Passed**, a warning, a rejection, or **Fixed**. Above the rows you get the counts and a status line: | Status line | What it means | | - | - | | **Rejection risks found** | At least one finding looks likely to get the app rejected. | | **Warnings need review** | No rejection risk, but something is worth checking. | | **No rejection risks found** | Nothing was flagged. | Press a row to open it. Inside you get the guideline number, what was found, the evidence behind it, sometimes the file it lives in, and the suggested fix. Once the report is saved, the panel also shows an estimated outcome: **Likely to pass**, **Likely rejection**, or **Outcome uncertain**. Next to it the panel says "Apple makes the final decision." Treat the estimate as a prediction about your build, not a verdict. A clean report does not guarantee approval, and a rejection risk does not stop you from submitting. ## Fix what the review found Findings are not fixed for you. Ask Rork in chat to fix them, one finding at a time, and name the guideline: > The App Review report flagged guideline 5.1.1: the app has no way to delete an account. Add an in-app account deletion flow. You can also ask Rork in chat to run the review for you. A review started from chat asks you what to do when it finds something: **Cancel**, or **Fix warnings** when there are warnings, or **Done** when there are none. **Fix warnings** lets Rork edit the app and check it again in the same turn. While that review waits for your answer, the App Store panel says the review is running in chat and asks you to answer there. A review started with the **Run** button reports and stops. It changes no code and asks you nothing. After Rork changes the app, run the review again so the report matches the code you are about to submit. ## Previous reviews and new builds Rork keeps the last four reports. The newest one is the report in the panel, and the older ones sit under **Previous reviews** below it. Each entry shows the build it reviewed, its counts, and when it ran. Open one to see its findings again. When the code changes after a review, the panel adds a **New build available** badge next to the build id. The saved report now describes an older build, so run the review again before you submit. ## Limits * Up to 40 reviews per day, counted across the account that pays for the project. * Six review runs per chat turn. After that the agent says so and asks you to finish the remaining fixes, then start a fresh review from the App Store panel. * Only iOS apps are reviewed. In a project with only Android or web apps, the panel asks you to add an app instead of showing a report. * The reviewer reads your project source, plus your App Store Connect readiness data when the app is connected to App Store Connect. Without that connection, the review is based on the source alone. * The reviewer does not submit your app. Submitting is still a separate step. ## Troubleshooting The tab lives in **More → App Store**, not in the publish menu. The message says "App Store reviews require a paid Rork subscription". Any tier works, on the account that pays for the project. Buying credits does not unlock it. The most common cause is access: you need editor rights on the project, not viewer. Ask the project owner to change your role, then try again. It stays disabled while the panel loads, while a review runs, and when the project has no build to review yet. Wait a moment, reload the page, and try again. "Add an Expo or Swift app to this project before running an App Store review" means the project has no iOS app. Add a Swift app: an existing Expo app is reviewed too, but Expo is no longer offered for new apps, see [What happened to Expo?](/expo). Press **Stop**, then **Run** again. If the run ended badly, the panel shows "Review could not complete" with the reason above the report. If it keeps failing, contact support with the project link and the time of the run. The message says "Daily App Store preflight review limit reached." The count resets each day. ## Next steps Everything else to prepare before you submit. Timing, what slows a review down, and expedited review. Generate the screenshots your listing needs. Take the reviewed build to App Store Connect. # Build a native Android app with Rork Source: https://docs.rork.com/android/rork-android Rork writes native Android apps in Kotlin with Jetpack Compose, runs them on a cloud Android emulator next to the chat, signs the App Bundle for you, and sends the release to Google Play. A Rork Android project with the build summary in the chat and the finished plant care app running in the emulator An Android app in Rork is a **native Android app**. Rork writes it in **Kotlin** with **Jetpack Compose**, the stack a native Android team would use by hand. It is not a website in a shell, and it is not an iPhone app converted at runtime. You describe the app, Rork builds it, and you watch it run on a cloud Android emulator next to the chat. When it is ready, Rork signs the Android App Bundle and sends the release to Google Play. ## Watch an iPhone app become an Android app Follow an existing iPhone project through Android generation, preview it in the emulator, and open the Google Play setup. For the release steps after the video, see [Publish to Google Play](/submitting-to-play-store/creating-the-aab-file). ## Start an Android app Pick the platform before you send your first message. On [rork.com](https://rork.com?utm_source=docs\&utm_medium=referral\&utm_campaign=docs-cta\&utm_content=android-start), open the platform picker under the prompt box and choose **For Android**. The picker describes it as **Native Android with Kotlin + Compose**. The Rork platform picker open, with For iPhone, For Android, and For web, and a note that you can add another platform later The picker says it plainly: **you can add another platform later**. One project can hold an Android app, an iPhone app, and a web app at the same time. See [Convert your app between iOS, Android, and web](/import/convert-between-platforms). Then describe the product, not the technology: ``` A plant care app that reminds me to water each plant and tracks how each one is doing ``` ## Answer the questions about the look Rork does not start writing Kotlin straight away. It asks a few short questions first, and each answer is a picture, not a word. You can also type your own answer in **Other**. Rork asking what the first screen of the plant care app should show, with four answers to choose from Answer them, then press **Submit**. Skip this step by writing the look into your first prompt instead. ## Approve the design, then build Next Rork draws the screens and shows them in **Design mode**. Nothing is built yet, so this is the cheap moment to change your mind. Ask for a different screen in chat, or press **Build** to turn the design into a working Android app. Design mode showing four proposed screens for a plant care app and a Review design card with View Design and Build buttons ## Run the app on an Android emulator Rork runs your Kotlin app on a **cloud Android emulator** in your browser. It is the real app on a real Android system, not a picture, so you tap through it while you build.

Recorded in the emulator with the Record button.

Android's own permission dialogs show up, which is the clearest sign that the app is native:
The plant care app in the emulator showing the Android system dialog asking to allow notifications

Android's own permission dialog, on first launch.

The emulator does not run all the time. It waits behind a **Turn on emulator** button, and it tells you what it costs while it runs:
The emulator panel reading Turn on emulator, 0.1 build credits per minute while running, and no simulator credits used in this project yet

The emulator waits until you start it.

The panel says **0.1 build credits/min while running**, so press **Stop emulator** when you finish a testing round. It also tells you how much emulator time this project has used so far. See [Build credits vs cloud credits](/billing/build-credits-vs-cloud-credits). The controls above the emulator do this: The emulator toolbar with record, screenshot, home, settings and element select buttons, a Share button, and a Live indicator with restart and stop | Control | What it does | | - | - | | **Record** | Records the preview and attaches it to the chat. This is how you show the agent a bug that only happens in motion. | | **Screenshot** | Attaches a screenshot to the chat. | | **Home** | Presses the Android home button. | | **Emulator settings** | Switches the system between **Light** and **Dark**, and changes **Text size**. | | **Select an element** | Point at a part of the screen, then write what to change about it. The agent gets the exact element. | | **Share** | Takes a screenshot and wraps it in a phone mockup you can post. | | **Restart** | Restarts the emulator, which is what you press when the instance is gone. | | **Stop emulator** | Shuts it down and stops the per-minute cost. | The emulator settings popover with a Light and Dark appearance switch and a Text size field Use **Emulator settings** before you publish. Dark mode and large text are where Android layouts break, and both are one click here. Changing the text size reloads the current screen. An emulator instance does not live forever. If the connection is gone, press **Restart**. Your app and your project are untouched. Only the running machine is gone. The emulator has no physical camera. Camera code still builds, and the camera works on a real phone. See [Test on your own phone](#test-on-your-own-phone). ## Test on your own phone The emulator covers most testing. When you want the app in your own hand, Rork builds the APK for you, so there is no terminal and no build service: 1. Open **Publish**, then open the Google Play section. 2. Press **Download APK**. 3. Open the `.apk` file on your Android phone and install it. Android asks you to allow installs from your browser or file manager the first time. The full walkthrough, including testing through Google Play, is in [How to test Android apps on your Android device](/submitting-to-play-store/apk-file). ## Publish to Google Play Rork builds and signs the release for you. What Rork cannot do is be you: the developer account and the store listing belong to your Google account. Open **Publish** in the project. The Google Play section says what it does, and shows whether a release build exists yet: The Publish menu showing a Google Play section that generates an Android App Bundle, a No release build yet status, and an Upload to Google Play button Google charges a **one-time \$25 registration fee**, and the identity checks take days. Start this early. See [Create your Google Play developer account](/store-guides/google-play-developer-account). Google's API cannot create the first app record for you, so the listing has to exist in Play Console before Rork can publish to it. When Rork needs it, the panel says **Create Play Console app**: "Create the app listing, then Rork can check access again." Use **Copy package name** so the listing matches your build. Press **Upload to Google Play**. The dialog names the app it will build for, one app per bundle: "This AAB contains this Kotlin app only." It also names the account it will publish with. Until you connect one it says **Connect Google Play**: "Connect the Google account that manages this Play Console app." The Upload to Google Play dialog naming the Kotlin Android target, saying it is ready to build the Android App Bundle, showing a connected Google account, and offering Build AAB for Play Press **Build AAB for Play**. Rork builds a release Android App Bundle and signs it with a persistent upload key that belongs to your project. The dialog reads "Building Android App Bundle. This can take a few minutes. You can close this window." When the bundle is ready the button becomes **Send to Google Play**, and Rork uploads it to your internal testing track. **Download AAB for Play Console** gives you the signed file to upload by hand instead. **Download APK** gives you a file you can install on your own phone. A release lands in **internal testing** first, which is visible only to the testers you list. Rork says so plainly when the upload finishes: "Version 1 is in internal testing. It isn’t public yet." ## Ask the agent to promote the release Google Play work is not limited to the buttons. The agent can drive the Play tracks from chat: ``` Promote this release to closed testing ``` ``` Promote this to production at 5% of users ``` It handles internal testing, closed testing, open testing, production, and a staged rollout you can increase, halt, resume, or complete. Two limits are worth knowing: there is no rollback, so a bad release is halted or replaced by a corrective one, and custom testing tracks are not supported yet. Internal testing does **not** satisfy Google's 12-testers-for-14-days rule. That has to be a closed test. See [Create your Google Play developer account](/store-guides/google-play-developer-account). **Do not ask the agent to add signing keys, keystores, or SHA-1 fingerprints to the project.** Google Play ties your app to the key used for the first upload. Rork manages that key for you, and changing signing files can make Google Play reject every later upload. If Play Console reports a signing key mismatch, contact support with your project link instead of regenerating anything. For app updates, make the change in Rork and press **Rebuild AAB**, then send the new build to Google Play. The step-by-step version, with the Play Console screens, is in [How to publish your Rork app to Google Play Store](/submitting-to-play-store/creating-the-aab-file). ## Add an Android app to a project you already have Any project can grow an Android app. Click **+** above the preview and pick **Android (Kotlin)**: The add platform menu above the preview, offering Android (Kotlin) as a native Android app and Web as a responsive web app You can also use **Project Settings → Add new app**, or just ask: ``` Add a native Android app to this project ``` The agent recreates your screens, navigation, data flows, and design as an Android app. Both apps then live in one project, with **two codebases**: Swift for iPhone, Kotlin for Android. They share the chat and the backend, and they publish from the same **Publish** menu. ## What a Rork Android app can do Android hands an app the device directly, and so does Rork: * Screens in Jetpack Compose: bottom navigation, lists, forms, Material controls, and system-style settings * The camera, sensors, local storage, home screen widgets, and Android permission prompts * Work that keeps running in the background * Accounts, data, and push notifications from the same backend as your other apps, see [Backend](/backend/index) * A real Android Studio project you can export to GitHub, see [How to sync your project with GitHub](/tutorials/how-to-connect-github) ## What an Android app cannot do An Android app is Android only. These are the limits that matter: * It does not run on iPhone. Add an iPhone app to the same project if you need both. * The cloud emulator has no physical camera. The camera works on a real phone. * Rork cannot create the first app listing in Play Console. You create that listing once. * Custom testing tracks are not supported yet. * There is no rollback. Halt a bad production release, or send a corrective one. * Internal testing does not satisfy Google's 12-testers-for-14-days rule. If you also need an iPhone app or a web app, add that platform to the same project. See [Convert your app between iOS, Android, and web](/import/convert-between-platforms). ## FAQ No. A Rork Android app is a Kotlin codebase built with Jetpack Compose. It is not a browser app in a shell, and it is not an iOS app. No. Rork signs the bundle with a persistent upload key for the project. There is no `.jks` file, no key alias, and no keystore password for you to store, rotate, or lose. Any paid plan. The **Free** plan designs an Android app but does not build one. See [Plans & Subscriptions](/introduction/subscriptions). **0.1 build credits per minute while it runs**, and nothing when it is off. The panel shows how much this project has used. See [Build credits vs cloud credits](/billing/build-credits-vs-cloud-credits). Yes. **Download AAB for Play Console** gives you the signed file, and you upload it in Play Console as usual. Google requires it. A personal developer account created after 13 November 2023 needs a closed test with at least 12 testers opted in continuously for 14 days before it gets production access. See [Create your Google Play developer account](/store-guides/google-play-developer-account). Yes. An Android app is Android only, but you can add an iPhone app or a web app to the same project and share one backend between them. See [Convert your app between iOS, Android, and web](/import/convert-between-platforms). Yes. Add a native Android app to the same project and the agent rebuilds your screens in Kotlin. Your Expo app stays where it is. See [What happened to Expo?](/expo). ## Next steps The matching Swift guide, from the first prompt to the App Store. What each platform is good at, and how to choose. Install the app before anyone else sees it. The account, the checks, and the 12-tester rule. Accounts, data, files, and push notifications. # App Store screenshots Source: https://docs.rork.com/appstore-screenshots/app-store-screenshots This guide walks through how to create high-quality App Store screenshots, the tools you can use, and what Apple expects when you upload them ## Why App Store Screenshots Matter App Store screenshots are one of the biggest drivers of installs. Most users decide whether to download an app based on the first few screenshots they see, so clarity, layout, and correct sizing are critical. ## Apple Required Screenshot Sizes Apple requires **separate screenshots for iPhone and iPad** if your app supports both. ### iPhone Screenshot Sizes (Portrait) You must upload screenshots that match at least one of Apple's supported device sizes. The most common approach is to use the **largest size**, which Apple accepts for all smaller phones. * **6.7-inch display (recommended)** * **1290 × 2796 px** * Aspect ratio: **9:16** (Using this size covers iPhone 14 Pro Max, 15 Pro Max, and newer large devices.) ### iPad Screenshot Sizes (Portrait) If your app supports iPad, Apple requires iPad screenshots. * **12.9-inch iPad** * **2048 × 2732 px** * Aspect ratio: **4:3** This size is accepted for all supported iPad models. ## Screenshot Strategy Before designing: * Screenshot 1: Core value proposition * Screenshot 2–3: Main features * Screenshot 4–5: Differentiation, results, or use cases * Keep text minimal and readable on small screens ## Tools You Can Use ### Canva (Recommended) Canva makes App Store screenshots easy and fast. **Steps** 1. Open Canva 2. Search **"App Store Screenshot"** 3. Choose: * iPhone (9:16) template * iPad (4:3) template 4. Add your app screenshots and text 5. Export as PNG You can also manually create canvases using Apple's required dimensions. ### Screenshots Pro A dedicated tool for App Store assets. Best for: * Device frames * Consistent layouts * Batch exporting iPhone and iPad screenshots ### Other Tools * **iOS Simulator** – best for capturing raw screenshots * **Figma** – full design control * **Preview / Screenshot tools** – quick captures, not final design ## Capturing Screenshots ### iPhone * Use iOS Simulator * Choose a **6.7-inch Pro Max** device * Capture in portrait mode ### iPad * Use iPad Simulator * Choose **12.9-inch iPad** * Capture in portrait unless your app is landscape-only ## Export Guidelines * Format: **PNG** * No compression * Keep text within safe margins * High contrast and readable fonts ## Common Mistakes * Wrong dimensions or aspect ratio * Missing iPad screenshots when iPad is supported * Text too small to read * Overcrowded designs ## Summary Apple requires: * **iPhone screenshots:** 1290 × 2796 px (9:16) * **iPad screenshots:** 2048 × 2732 px (4:3) Capture clean UI, design with tools like Canva or Screenshots Pro, and upload both iPhone and iPad screenshots to ensure App Store compliance and higher conversion. # App Review guide Source: https://docs.rork.com/appstore-submission-checklist/app-review-guide This guide explains how Apple's App Store review process works, how long it usually takes, what can slow it down, and how to request an expedited review when timing matters. Every app and every update submitted to the App Store goes through Apple's review process. Apple checks that your app: * Functions correctly * Matches its App Store listing * Follows App Store Review Guidelines * Handles permissions and user data properly * Does not crash or block core flows This applies to: * First-time submissions * Version updates * Subscription or pricing changes that require a new build ## How Long App Review Takes ### Typical Review Timelines **First-time app submission** * **24–72 hours** **App updates** * **12–48 hours** **Metadata-only changes** * Can be approved in **a few hours** * Sometimes same-day In most cases, apps are reviewed within **1–2 days**. ## Review Statuses You'll See in App Store Connect * **Prepare for Submission** – Build and metadata setup * **Waiting for Review** – App is in Apple's queue * **In Review** – App is actively being reviewed * **Pending Developer Release** – Approved, waiting for manual release * **Ready for Sale** – App is live * **Rejected** – Changes are required ## Common Reasons Reviews Take Longer * Missing or unclear permission descriptions * App crashes or blank screens * Login required without test credentials * iPad support is enabled, but not properly handled * Features mentioned in screenshots but not working * App hangs on loading or requires unavailable backend services *** ## If Your App Is Rejected Rejections are common and expected, especially on first submissions. **What to do** 1. Read the rejection message carefully 2. Fix only what Apple mentions 3. Upload a new build or update metadata 4. Resubmit Most apps are approved after **one follow-up submission**. ## How to Get Approved Faster (Best Practices) * Test on a real device * Make sure all buttons and flows work * Avoid placeholder text or broken screens * Add clear permission explanations (camera, photos, microphone, etc.) * If login is required, provide demo credentials * Ensure your app works on iPhone and iPad if both are enabled ## Expediting App Reviews Apple allows developers to **request an expedited review** in limited situations. ### When Expedited Review Is Appropriate * Critical bug fixes affecting users * Security or data issues * Time-sensitive launches or events * The app is blocked due to a major issue Expedited reviews are **not guaranteed**, but they are often approved if the reason is valid. ### How to Request an Expedited Review 1. Go to **App Store Connect** 2. Select your app 3. Open the submitted version 4. Click **Request Expedited Review** 5. Provide a clear explanation ### What to Say in the Request Keep it short and specific. Example reasons: * "This build fixes a critical crash affecting all users." * "This update resolves a blocking login issue." * "This app supports a time-sensitive event." Avoid vague reasons like "we want it faster." *** ### Expedited Review Timing If approved: * Review often happens within **24 hours** * Sometimes same-day If denied: * The app remains in the normal review queue ## After Approval Once approved, you can: * Release immediately * Schedule a release * Use phased rollout Most apps appear on the App Store within **a few hours** after release. ## Summary * Most app reviews take **1–2 days** * Delays are usually caused by crashes, permissions, or missing info * Rejections are normal and fixable * Expedited reviews are available for valid, time-sensitive cases * Once approved, your app can be live the same day Planning around the review process helps avoid launch delays and surprises. # Main App Store rejection reasons Source: https://docs.rork.com/appstore-submission-checklist/whats-next-after-the-apps-finished These are the most common reasons for App Store rejections (add dos and don'ts)\ Most common rejection reasons: * Permission problems in `Info.plist` * Subscription issues * iPad Screenshots ## Info.plist permission issues Image This happens when your app asks for permission from the user's phone, but they don't specify the exact reason why. Image The code above would be rejected by Apple. It does not properly explain the need for each permission. Image The above code shows a thorough description of why each permission is needed. ## How do I fix this issue? Typically, Rork already explains the purpose of each permission. However, if this issue occurs, open `Info.plist` in the iOS app folder and correct the permission descriptions, or ask the agent in chat to rewrite them.\ \ For more guidance, you can refer to the Rork agent. ## Subscription issues Image When adding a paywall or in-app purchases to your app, you need to have your privacy policy, terms and conditions, and your EULA both in your App store description and visible in your paywall **How to create policies?**\ \ If you are using a hard paywall, you must mention that all features are blocked by a paywall in your App Store description, otherwise apple will also reject you. Image ## Ipad Screenshots You can't just submit photos of an iPhone screenshot just stretched to the size of an iPad; Apple will reject you. Image This will be rejected because they're not real iPad screenshots; they're just stretched iPhone screenshots. Image Will be accepted because it's a real screenshot of an iPad ## What if I don't have access to an iPad? You can go to [Xcode](/how-to-set-up-xcode/how-to-set-up-xcoe) and launch an iPad simulator, then take the screenshots. # How to add a Firebase backend to Rork Source: https://docs.rork.com/backend/firebase This guide will help you create a backend with Firebase for your Rork project. This includes authentication for users and also custom database schemas for functionalities in your app. **Most apps do not need a backend.** This is complex work, and it can break a working project. Read [Do you need a backend for your app?](/backend/index) first. If you do need one and would rather not run it yourself, [Rork Cloud](/backend/rork-cloud) gives you a database and server functions inside Rork, with no second account. This guide will help you use Firebase to build your backend. By the end of this guide, you will be able to sign users in with their email, establish all the backend databases for your app to fully function, and build out any functions needed to make your app personalized for the users. ### **Create a Firebase account** * Go to [Firebase](https://console.firebase.google.com/) and log in with your Google account. You may have to answer a few questions before you can create your first project. This takes just a few minutes. * **Create a new Firebase project (choose a name).**\ Feel free to skip the Gemini AI assistance and Analytics part for now. You can always add those in later. The Firebase console asking for a project name when you create a new project * **Register your app.**\ After you have a Firebase project, you can register your app within that project. * You should see an "**Add App**" button followed by a set of Platforms. Choose the platform that matches your app: **iOS** for an iPhone (Swift) app, **Android** for an Android (Kotlin) app, **Web** for a web app. Firebase then gives you a config: a `GoogleService-Info.plist` file for iOS, a `google-services.json` file for Android, or a `firebaseConfig` object for web. Hand that config to the agent in chat and it wires the SDK into your app. The screenshots below follow the **Web** option. The Add App row in Firebase, with the iOS, Android, and Web platform buttons * Enter your app's nickname. This is internal and won't be seen by the public. The Register app step in Firebase, asking for an app nickname * Click the Register app. * You will be shown your config. Please check the next steps in **Collect Your Config** on what to do. ### Collect Your Config On that same page, after registering your app, you will see the config and SDK instructions. We are basically going to tell our Rork project editor to add these in. The Firebase SDK setup screen showing the firebaseConfig object to copy Please copy the second window that has the firebaseConfig item in it and then return to the Rork editor. **In the Rork editor, please type the following:** ``` Please install firebase package and setup the init config. Please also setup Firebase Auth and Firebase Database: {PASTE YOUR ACTUAL COPIED CONFIG FROM ABOVE HERE} ``` The Rork chat with the Firebase config pasted into the prompt The rest of this guide builds **VibeVoice**, a voice-only social app. In the screenshots the agent calls the same project SPEEK, which was its earlier name. Your own project keeps your name. ## Creating the Backend Data Schema This is probably going to be the most challenging part of this whole process if you have never done this, but you can also use AI (inside Rork) to help you out. You need to figure out the data schema needed for your application to work, and the functions that it should be able to do as well. Just like with SQL, you still need to define which objects your app needs, but Firebase uses NoSQL instead of tables. This means: * You will create collections (like tables) * Each user or post will be a document * A document contains fields * You can also have subcollections nested inside documents **You can ask Rork the following:** > Please list out all of the data schema collections required for our application to work. I will be using this list to create my Firestore collections and security rules. Rork answering with a list of Firestore collections and their fields ### Create Your First Database We need to enable the Firestore Database in order to be able to store information on the cloud. Click on **Firestore Database** on the left-hand panel inside your Firebase project. Create a database and pick a region closest to your users. You cannot change this later, and this does affect the speed of your backend. **Once in, add the security rules Rork told you to add. Go to the Rules tab and paste them in.** The Rules tab of Firestore Database, where the security rules are pasted Now that you know what your objects and security rules are, we can build our Firestore collections. Unlike Supabase, Firebase does **not** require SQL or table creation ahead of time. Firestore builds collections “just-in-time” when your app writes to them. So, we can ask Rork to do all the work for us now. Before we get to that, though, we must set up our Auth so users can sign up and have a user id attached to them. ### Set up authentication in the Firebase dashboard (e.g., email/password, OAuth providers) Before we connect your data schema to Firestore, we need to make sure users can actually sign up and sign in. Firebase Authentication is the simplest part of this whole backend setup and requires no databases or SQL. ### **Enable Email + Password Authentication** 1. In your Firebase dashboard, go to **Authentication** and press **Get Started**. 2. Click the **Sign-in method** tab. 3. Enable **Email/Password**. 4. (Optional) Turn off email verification to make development easier. 5. (Optional) Enable Google, Apple, or phone number if you want those later. These are highly popular asks from most users to add in. Firebase saves these settings automatically, so now we can just ask Rork to enable it. ### Integrating Auth into Rork Now that authentication is enabled, Rork can generate all the login and signup logic directly inside your project. In your Rork editor, ask: ``` Please integrate Firebase Authentication into this project. I want email+password sign up, sign in, sign out, and proper session handling. Use: - createUserWithEmailAndPassword - signInWithEmailAndPassword - onAuthStateChanged for sessions After sign up, please also create a user document in Firestore inside the "users" collection. ``` Rork will generate: * a signup function * a login function * an auth state listener * The code to create the initial user document in Firestore * navigation updates for logged-in vs logged-out users This gives your app a fully working authentication system. ## Ask Rork to Apply Your Schema and Build Your Functions Now that authentication is working and your Firebase Security Rules are in place, the final step is to give Rork your app’s schema so it can generate all of the backend functionality your project needs. This step is where your backend becomes *real*. Rork will build: * Firestore collection/document structures * create/read/update/delete functions * queries (feed, user posts, lists, etc.) * any subcollection logic (comments, likes, followers, etc.) * Firebase Storage upload helpers (if your schema includes images/audio/video) * fully typed helper functions your app can call To do this, open the Rork editor and send the following message: ``` I have added the Firebase Security Rules. Please apply the schema from before that you stated to the project and generate all helper functions required for it, including create, read, update, delete, queries, and any subcollection or media upload functionality needed. ``` Rork will read your schema and build out everything needed for your backend to function.\ If it misses a relationship or a field, simply update your schema and re-run the request. Once this step is complete, your app is fully wired up to Firebase. The authentication, Firestore, and all your app’s backend functions will now work end-to-end! ### Test and make sure your database updates with functions in your app Now that you have everything connected, you should see your updates change the database tables and also persist! Congrats on building a backend! # Do You Need a Backend for Your App? Source: https://docs.rork.com/backend/index Learn exactly when your Rork project requires backend setup and when you can skip it entirely. This guide helps you avoid building a backend for no reason. ### After building your app in Rork, use this documentation to decide if your app needs a backend or can stay local only. ## **Summary** Rork builds the **frontend** of your app: the screens people see and touch, on iPhone, on Android, and on the web. A **backend** is the part they never see. It stores data, keeps accounts, and enforces rules. Not every app needs one. By the end of this page you will know which category your idea falls into, and what to do next. **You need:** * A Rork project * A general idea of what your app does *** ## **1. What Counts as “No Backend.”** ### Local-Only Apps (Everything Stays on the Device) These are apps that store all their data on the user's phone.\ No sync needed. No logins required. No sharing implemented. **Examples:** * Todo lists * Notes apps * Journals * Habit trackers * Mood logs * Calculators * Timers * Unit converters * Offline flashcards * Photo filters/AI Gen * Utility widgets Rork can build and store the data for all of these with **no backend at all**, using the device's own storage: the local store on the phone, and a secure store for anything sensitive. As long as the data never leaves the device, local storage is enough. If your app is not saving data yet, ask in chat: ``` Make sure the data is stored on the device and survives a restart ``` *** ### Tools With Temporary / Non-Persistent Data These apps don’t care about storing long-term state at all. **Examples:** * Playground apps (drawing, sandbox) * Local mini-games * One-off AI generators that do not keep the result * Fun tools that make something but do not need to remember it If nothing needs to persist after the app closes, then no backend is needed to store or manipulate anything. Most simple applications built on Rork will behave like this by default. *** ### AI Apps That Only Call an External API If your app just sends a prompt to GPT and returns the response: **You do not need a backend.** You’re just making requests to OpenAI or another AI provider. Backend becomes optional only when: * You want the user history * You want personalization * You want usage tracking This extends to any external API. As long as you do not need to store this data, then feel free to use any API without a backend. *** ## **2. Apps That Always Need a Backend** ### Apps With Accounts or Login If the user “has an account,” you need: * Authentication * Restoring user data * Sync across devices **Examples:** * Social apps * Productivity apps with cloud sync * Finance apps * Any multi-device workflow *** ### Apps That Sync Across Devices A user writes a note on their phone and expects it on their laptop.\ That requires: * Database * Cloud sync * Persistent storage A backend is required. *** ### Apps With Sharing, Collaboration, or Multiplayer If more than one person can see, edit, or comment on the same thing: * Messaging * Friends lists * Comments * Posts * Social Feeds * Real-time collaboration * Matchmaking like Dating apps All of this needs a backend. *** ### Apps That Store Files If your app handles: * Images * Videos * PDFs * Audio recordings …and these files need to persist across different devices, you need to use a backend. Local storage will not cut it for cross-device or sharable content. *** ### Apps With Security or Access Rules If the app enforces any rule between users: * Blocking * Moderation * Rate limiting * Anti-spam Client-only apps can’t enforce rules. A backend would be required. *** ## **3. Gray-Zone Apps (Optional Backend)** ### Local-First Apps With Optional Sync Later Some apps work great without a backend, then add cloud features later. **Examples:** * Journal → adds cloud backup * Notes app → adds multi-device sync * Offline photo editor → adds “share to cloud.” You can ship v1 with no backend and add sync when you grow. *** ### AI Apps With Memory or Personalization You can choose: * **Local-only memory** → no backend * **Cloud memory across devices** → backend * **Personalized models** → backend Your v1 can be simple with local storage; once you have users, you can move to a more secure and advanced system, such as cloud or Personalized. ## Decided that you need one? You have three routes. **Rork Cloud** is the shortest, because it lives inside Rork and there is no second account to manage. A managed backend inside Rork: Postgres, server functions, and AI models. No separate account. ⏱️ *1 hour* Your own Postgres project, with auth and storage. Good if you want to own the database. ⏱️ *1 hour* Google's NoSQL option, with Firestore, auth, and storage. # What is Rork Cloud Source: https://docs.rork.com/backend/rork-cloud Why use Rork's built-in backend instead of setting up your own, what it costs, and what to expect. Rork Cloud is currently in **beta**. It is free to use while in beta, and your data is never deleted, even if your subscription ends. Rork Cloud is a backend that Rork creates and hosts for your app, so you do not have to set one up or configure it yourself. When your app needs to store data, the agent shows a **"Create Rork Cloud"** confirmation in the chat. After you confirm, Rork provisions the backend in the background and connects it to your app automatically. The walkthrough shows backend setup and the database panel, then introduces AI Cloud and the related documentation. This is the card you will see in the chat:
Create Rork Cloud?
Create a hosted backend before adding database tables, RLS policies, or Edge Functions.
Postgres
RLS
Edge Functions
Cancel Connect my Supabase Create Rork Cloud
Connect a Supabase project from your own org and bill compute directly to Supabase.
**Create Rork Cloud** sets up the managed backend for you. **Connect my Supabase** is the same card's path for bringing your own Supabase project instead. ## What you get * **No extra sign-ups.** Your Rork account is all you need. Rork manages everything for you, and you can ask the Rork agent in chat for anything you need, at any time. * A **database** for accounts, shared data, and anything that must sync across devices and users. * **Secure access rules** so each user can only read and write their own data. * **Server-side functions** for logic that should not run on the user's device, such as private API keys, payments, and webhooks. ## Rork Cloud or your own Supabase? Both work with Rork the same way, so pick based on what you want to own: * **Never built a backend before?** Use Rork Cloud. Rork creates and hosts it for you, and there is nothing to set up or pay for while it is in beta. * **Already comfortable with Supabase?** Connect your own Supabase project and do everything there, under your own account. Supabase bills you directly on [their pricing](https://supabase.com/pricing). You are not locked in either way: you can start on Rork Cloud and [transfer to your own Supabase later](#transfer-to-your-own-supabase). Connect your own Supabase project to your Rork app. Connect your own Firebase project to your Rork app. ## How to add it There are two ways to get a backend: * **Just ask in chat.** Say *"Add a database to my app"* or *"Add a backend"* and Rork takes care of the rest. * **From the project panel.** Click **More** (the last icon in the top toolbar), open **Database**, and press **Add a database**. The Database section under More with the Add a database button ## See what your app is storing Once your backend exists, the **Database** tab under **More** shows your tables and row counts, so you can always see what is inside. The Database tab under More showing the app's tables with row counts If you want a friendlier view than raw tables, ask Rork in chat to build one, for example: *"Build me a web admin panel where I can browse and edit my app's users and orders."* ## Transfer to your own Supabase If you later want the backend to belong to you and be managed by you, press **Transfer to your Supabase** at the top of the **Database** tab. The whole backend moves into your Supabase organization, with your data. The project's URL, data, and keys stay the same, so your published app keeps working with zero changes. The Managed by Rork card in the Database tab with the Transfer to your Supabase button Two things to know: * The transfer is one-way: Rork cannot take the project back afterwards. * Billing moves to you: from then on you pay Supabase directly for this project, on [Supabase's pricing](https://supabase.com/pricing). ## What it costs **Rork Cloud is free while it is in beta.** The database, access rules, and server-side functions do not cost anything to run right now. Two related costs are separate from the backend itself: * **AI features inside your app** (in-app chat, image generation, voice, and similar) run on **Cloud credits**, pay as you go. See [Build credits vs Cloud credits](/billing/build-credits-vs-cloud-credits). * **After a transfer to your own Supabase**, Supabase bills you directly for the project. ## What to expect * **It is a real, production backend.** It runs your app's live data for real users, not a sandbox. * **Changes are live right away.** There is no separate preview step, so be careful with actions that delete or overwrite data. * **Your code is yours.** On a paid plan you own all generated code and can export it any time through the GitHub integration, with two-way sync. See [Code Export](/faq/code-export). * **You can add accounts and social sign in.** Follow [Add accounts and sign-in to your app](/integrations/backend/how-to-set-up-oauth). ## If you cancel or stop paying * **Your data is not deleted.** Rork does not delete your app's data, even if your subscription ends. * **Your app keeps working.** If you cancel your Rork subscription, your app and its backend keep running. Keep in mind that Rork Cloud is still in beta, so these details may be refined as it matures. ## When you may not need it * Prototypes that only store data on one device can use local storage. * Logic, webhooks, or private keys can use server-side functions without a full database. If you are not sure whether your app needs a backend at all, read [Do You Need a Backend for Your App?](/backend/index). # How to add a Supabase backend to Rork Source: https://docs.rork.com/backend/supabase This guide will help you create a Supabase backend for your Rork project. This includes authentication for users and also custom database schemas for functionalities in your app. ## The easiest way: just ask in chat You can skip the manual setup below entirely. In your project chat, ask Rork: > Add a backend to my app or, if you specifically want Supabase under your own account: > Add a Supabase backend to my app Rork walks you through connecting it. If the backend runs under your own Supabase account, Supabase bills you directly for it on [their pricing](https://supabase.com/pricing). If you would rather have Rork host the backend for you, see [What is Rork Cloud](/backend/rork-cloud). ## Watch the Supabase connection walkthrough Create a Supabase project, authorize Rork, and connect the app to its database. ## Manual setup ### First, go to Supabase and click new project Image Second, copy the Publishable key and the Project link Image Then, paste them into Rork with the prompt "Connect Supabase." Image Rork will then instruct you on how to set it up Image If you want to implement Auth, check out our YouTube tutorial: