# 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:
SafetyGuideline 1.x
PerformanceGuideline 2.x
BusinessGuideline 3.x
DesignGuideline 4.x
LegalGuideline 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.
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.
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.
## 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.
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 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**.
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.
## 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:
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 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:
| 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. |
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:
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."
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)**:
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
This happens when your app asks for permission from the user's phone, but they don't specify the exact reason why.
The code above would be rejected by Apple. It does not properly explain the need for each permission.
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
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.
## Ipad Screenshots
You can't just submit photos of an iPhone screenshot just stretched to the size of an iPad; Apple will reject you.
This will be rejected because they're not real iPad screenshots; they're just stretched iPhone screenshots.
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.
* **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.
* Enter your app's nickname. This is internal and won't be seen by the public.
* 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.
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 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.
### 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.**
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**.
## 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.
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.
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
Second, copy the Publishable key and the Project link
Then, paste them into Rork with the prompt "Connect Supabase."
Rork will then instruct you on how to set it up
If you want to implement Auth, check out our YouTube tutorial:
Or if you want to implement an api via edge function, read our guide:
[How to add an api to your app?](/features-apis/apis/how-to-connect-an-api-to-your-project)
# Build credits vs Cloud credits
Source: https://docs.rork.com/billing/build-credits-vs-cloud-credits
Rork has two separate balances: build credits for creating your app with the agent, and Cloud credits for the AI and cloud features your finished app uses.
Build credits and Cloud credits are billed and topped up separately, so it helps to know which one a charge belongs to:
* **Build credits** pay for building your app inside Rork.
* **Cloud credits** pay for the AI and cloud features your app uses while it runs, including for your own users once the app is live.
## At a glance
| | Build credits | Cloud credits |
| - | - | - |
| **Pay for** | Building your app in Rork | AI and cloud features your app uses while it runs |
| **Shown as** | Credits | US dollars |
| **Comes from** | Your plan, plus top-ups on Max | \$1 free to start, then funds you add |
| **Drops when** | You prompt, build, and publish | Your app, or its users, use a cloud feature |
| **Top up in** | Billing, Build Credits tab | Billing, Cloud Credits tab |
## Where to find them
It is in the top-right corner of Rork.
**Credits** is your build credit balance. **Cloud Credits** is your dollar balance.
Click **Billing** in the same menu. The tabs on the left are **Build Credits**, **Cloud Credits**, **Payments**, and **Purchases**.
The same menu has shortcuts to upgrade your subscription, buy Cloud Credits, and open Billing.
## Build credits
Build credits are spent while you create and edit your app in Rork. They cover:
* AI chat messages with the agent.
* Builds and previews started from the editor.
* Asset generation while building (images, audio, 3D, and similar).
* Publishing and platform work.
They are tied to your plan and subscription, so how many you get and how usage is counted depends on your plan. This is the balance that drops as you keep prompting and building. See [Subscriptions](/introduction/subscriptions) to compare plans.
The Build Credits tab in billing shows your remaining balance, subscription versus usage credits, and your current plan. On Max plans you can also top up credits as you go:
## Cloud credits (Rork AI Cloud)
Cloud credits are a separate balance that your finished app spends at runtime through Rork AI Cloud. They are not part of your plan: you enable Rork AI Cloud for a project, and Rork gives you a one-time **\$1 in Cloud credits** for free so you can try adding AI to your app and run a few tests. The balance is shown in USD, and it drops only when your app actually uses a cloud feature.
Cloud features that draw from this balance include:
* Backend functions.
* AI features like chat, images, and voice.
* Web search.
* Media and 3D generation.
The Cloud Credits tab in billing shows the USD balance and an **Add funds** section. It also has a toggle to use Rork Cloud and a summary of recent cloud usage by your app:
Before relying on AI features, make sure **Use Cloud Credits** is turned on for the project, like in the panel above. If it is off, the app stays on legacy features only and will not use Rork AI Cloud.
### Add funds
Use the avatar menu, or click **Buy Cloud Credits** in the same menu.
The toggle sits at the top of the tab.
Choose a preset or type your own. You can add from \$5 to \$200 at a time.
The balance updates a moment after the payment goes through.
### See where the money went
Cloud Usage breaks that spend down so you can see where it went: by AI model and by project over the last 30 days.
## Keep your app running
So your app's cloud features do not stop mid-use, set up one or more of these:
* **Low-balance email.** Rork emails you when the balance drops below a level you choose. The default is \$5. Set it to \$0 to turn the email off.
* **Auto top-up.** Rork charges your saved card and adds funds when the balance drops below that same level. You choose how much to add each time, from \$5 to \$200.
* **Monthly spending limit.** After your first paid top-up, the Cloud Credits tab shows this limit. Automatic top-ups stop before they go over it.
Rork may also show a project notification when Cloud credits are running low or run out, with a quick link to add credits.
Auto top-up needs a saved card. Rork saves your card with your first paid top-up.
Find **Auto top-up cloud credits**.
Set **When the balance drops below** and **Top up by**.
Rork confirms that the settings are saved.
## What you can build with AI features
Every example below runs through Rork AI Cloud, so it uses Cloud credits when people use your app. Describe the feature in chat. You can name a model, or let the agent choose one.
*"Build a fitness coach app. Users chat with an AI coach about their week and get a simple plan."*
*"Build an app where users upload a selfie and get four graduation photos."* Follow the full tutorial.
*"Build a language tutor. The user speaks, and the app answers out loud."*
*"Build a trip planner that checks the web for current opening hours and prices."*
*"Build an app that turns a product photo into a short video clip."*
The more your users use these features, the more Cloud credits your app spends. The price table at the end of this page shows what each model costs.
## Free on-device AI on iPhone
Some AI features do not need Cloud credits at all. On iPhone, Apple's **Foundation Models** framework lets a Swift app talk to Apple's own language model, which runs on the phone. Apple describes this AI inference as [free of cost](https://www.apple.com/newsroom/2025/09/apples-foundation-models-framework-unlocks-new-intelligent-app-experiences/).
This means:
* **It is free for you.** No Cloud credits and no per-request charge.
* **It is free for your users.** They do not pay for each request.
* **It works offline** and keeps the user's data on the device.
iOS 27 makes this better. Apple rebuilt the on-device model for iOS 27: it is better at logic and tool calling, and it can read images that you put in the prompt. See [What's new in the Foundation Models framework](https://developer.apple.com/videos/play/wwdc2026/241/) from WWDC26.
Building the app still uses build credits. Only the AI requests that run on the phone are free.
### What to expect
* **It needs a supported iPhone.** The user needs an Apple Intelligence-compatible iPhone (iPhone 15 Pro or newer) with Apple Intelligence turned on. Your app still installs on other iPhones, but the AI feature will not be available there.
* **The model is small.** It is good at short tasks: sorting, pulling out names and dates, short summaries, rewriting short text, and filling in forms. For complex reasoning, long writing, or realistic images, use Rork AI Cloud.
* **Rork adds it to Swift iPhone apps.** It is not available in web apps or React Native apps. See [Swift vs React Native](/swift-vs-react-native/whats-the-difference) to pick the right type.
| | On-device (Apple) | Cloud AI (Rork AI Cloud) |
| - | - | - |
| **Cost to you** | Free | Cloud credits |
| **Cost to your users** | Free | Free for them, you pay with Cloud credits |
| **Internet needed** | No | Yes |
| **Quality** | Good for short, simple tasks | Best available models |
| **Works on** | Apple Intelligence iPhones | Any device |
A good setup for many apps: use the on-device model when the phone supports it, and fall back to Rork AI Cloud when it does not. You can ask for this in chat:
> Add a feature that sorts a pasted receipt into categories. Use the on-device Apple model when the iPhone supports it. Otherwise use Rork AI Cloud.
## If a charge looks wrong
First check whether it was build activity (inside the editor) or cloud usage (your running app). On-device AI never creates a charge. Then collect the project link, the approximate time, and the action, and contact support so the usage can be reviewed.
## Available AI models
These are the AI models you can use in your app. You don't have to pick one up front: just tell Rork what you want to build. You can name a specific model, or let the agent choose the best one for the task.
Prices are per 1 million tokens. Image, video, audio, and embedding models are billed differently, so their token prices show as a dash.
# What is Rork's Backend Capabilities?
Source: https://docs.rork.com/building-complex-apps/backend/what-is-rork-toolkit
Rork provides an optional backend infrastructure for applications requiring server-side functionality. Currently in its beta phase, if you run into any issues, please reach out to Support.
### **Overview**
The backend enables developers to implement custom server logic, API endpoints, and database operations within their Rork applications.
### **Capabilities**
* **API Endpoints**: define custom routes for client-server communication
* **Server-Side Logic**: execute secure operations outside the client application
* **Database Integration**: persistent data storage and retrieval
* **Protected Routes**: authentication and authorization support
### **Technical Stack**
| **Component** | **Technology** |
| :- | :- |
| Server Framework | Hono |
| API Layer | tRPC |
### **When to Use**
A backend is recommended for:
* Social applications with user-to-user interactions
* Multiplayer or real-time collaborative features
* Applications requiring shared or centralized data storage
**A backend is not required for:**
* Single-user applications
* Local data storage use cases
* Applications utilizing only built-in AI features
### **AI Capabilities**
To add AI capabilities to your application, use the **Rork Toolkit**. The Toolkit provides pre-built AI features including text generation, image creation, voice-to-text, and intelligent assistants, with no backend configuration required.
## What's inside the Rork Toolkit?
| **Feature** | **Model** | **Provider** |
| :- | :- | :- |
| **AI Assistant (Chat/Agent)** | Claude Sonnet 4.5 | Anthropic |
| **Text Generation** | GPT-5 Chat | OpenAI |
| **Data Extraction (generateObject)** | GPT-4.1 | OpenAI |
| **Image Generation** | GPT-Image-1.5 (DALL-E) | OpenAI |
| **Image Editing** | Gemini 2.5 Flash Image | Google |
| **Voice to Text** | Whisper-1 | OpenAI |
| **Tool Result Summarization** | Gemini 2.5 Flash | Google |
The models are accessed through these toolkit SDK functions:
* Uses Anthropic Claude Sonnet 4.5 for chat and agentic workflows
* Uses OpenAI GPT-5 for text generation
* Uses OpenAI GPT-4.1 for structured data extraction
* Image generation uses OpenAI DALL-E
* Image editing uses Gemini 2.5 Flash Image
* Speech-to-text uses OpenAI Whisper-1
**What you can build with the Rork Toolkit**
The Rork Toolkit lets you build full AI-powered apps from one toolkit: chat agents, content generators, data extractors, image and voice features, and multimodal workflows. It’s everything you need to create smart, production-ready AI experiences without managing multiple models or providers.
# Share a project and work together
Source: https://docs.rork.com/collaborate/share-a-project
Invite people to view or edit your Rork project, leave comments for each other, see who is online, and clone a project into a fresh copy you can change freely.
A Rork project can hold more than one person. You invite a co-founder, a designer, or a client, and they open the same chat and the same live preview that you see.
There are two ways to bring somebody in, and they are not the same thing:
* **Invite** them into your project. One project, one chat, everyone edits the same app.
* **Clone** the project. They get their own copy, and your version keeps working exactly as it did.
## Invite someone to your project
Press the invite button in the project header, next to **Publish**.
You have two routes:
* **By email.** Type the address, choose the role, press **Invite**. Rork emails them a link titled "You're invited to collaborate on a Rork project." That invite expires after 7 days.
* **By link.** Press **Create** under **Create invite link**. Anyone who opens that link can join, so treat it like a password. Links last a year.
Whoever accepts has to sign in to Rork first. After that they land straight in the project.
## Editor or Viewer
Rork has exactly two roles.
| | Editor | Viewer |
| - | - | - |
| Read the chat and the preview | Yes | Yes |
| Send messages to the agent | Yes | No |
| Edit code and secrets | Yes | No |
| Publish and submit to the stores | Yes | No |
| Invite other people | Yes | No |
| Leave comments | Yes | Yes |
| Clone the project | Yes | Yes |
A viewer sees a note in the composer instead of a send button: "You have view-only access to this project". Give clients and stakeholders **Viewer**, and give teammates **Editor**.
To change somebody later, open the invite dialog and use their row: **Set as Editor**, **Set as Viewer**, or **Remove**. If you were invited and want out, the same menu offers **Leave project**.
Collaborators spend the project owner's credits. The dialog says so: "Collaborators will use credits from the project owner's workspace". Every message an editor sends comes out of your balance, so invite editors deliberately. See [Build credits vs Cloud credits](/billing/build-credits-vs-cloud-credits).
## See who is in the project
The project header shows a row of avatars: the owner first, then the collaborators. A green ring means that person is in the project right now, and a dimmed avatar means they are away. Hover an avatar to see who it is and whether they are the owner or a collaborator.
Two people can work in the same project at the same time. Only one message runs at a time, so agree who is driving before you both start typing.
## Leave notes for each other
Once a project has collaborators, the header gains a **Comments** button. The panel is titled **Comments**, with the line "Leave notes for your collaborators".
Use comments for the things that are not instructions to the agent: "the price on the pricing card is wrong", "client approved the hero". Comments live beside the project, not inside the chat, so they do not confuse the agent.
Comments do not send an email or a push notification. Tell your teammate where to look, or check the panel when you open the project.
## Clone a project
Cloning makes an independent copy. Use it to try a risky direction, to start a second app from a good base, or to hand someone a version they can break.
Open the **⋯** menu in the project header and choose **Clone project**.
What the copy contains:
* All the code, and the chat history behind it
* The assets: generated images, video, audio, and 3D models
* Your environment variables, except the keys Rork manages itself, which it mints fresh
What the copy does not share:
* Nothing you do in the copy touches the original, and nothing in the original reaches the copy
* A published web address stays with the original project. Publish the copy separately to give it one
Anyone with access to a project can clone it, viewers included. A clone always belongs to the person who made it.
## Find projects other people shared with you
Open the sidebar on [rork.com](https://rork.com) and use **Shared with you**. It lists the projects you were invited to, separately from **My Projects**.
## Are my projects private?
Yes. Every Rork project is private. The project address only opens for the owner and the people invited, and a stranger with the URL gets nothing.
Publishing is a separate decision. A published web app is public on purpose, and it does not expose your chat, your code, or your secrets. See [Rork Web](/web/rork-web).
## FAQ
No. They need a Rork account. The work runs on the project owner's credits.
Yes, invite them as **Viewer**. To show the app rather than the project, publish it to the web and send that address instead.
Open the invite dialog and press **Remove** on their row. An invite link you no longer want can be deleted the same way.
An editor can, yes. Every version stays in the chat, so ask them which answer they reverted to. See [Undo a change and go back a version](/features/undo-and-history).
Not in one project. One agent runs one message at a time. Split the work into two projects, or take turns and keep the other person on Viewer.
Clone is the practical route today: they clone it, and their copy is theirs. For a real ownership transfer, write to [team@rorkai.com](mailto:team@rorkai.com).
## Next steps
Go back to any earlier version of the project.
Who can see your API keys, and who cannot.
Give a developer the code in a normal repository.
Whose balance pays for a collaborator's messages.
# How to tell if your app idea is good
Source: https://docs.rork.com/elements-of-a-good-idea/how-to-tell-if-your-idea-is-good
Most app ideas fail before code. Not because the tech is hard, but because the idea itself does not create real pull. This guide helps you decide if an idea is worth building before you spend weeks shipping.
## Evaluating App Ideas
This document explains how to evaluate whether an app idea is worth building before investing time and resources. It is based on guidance from Y Combinator and common early-stage startup failure patterns.
## Purpose
To help builders determine whether an idea has real user demand, a clear problem definition, and a realistic path to value.
## Core Principle
A strong app idea solves a real problem that the builder personally experiences, for a clearly defined group of users, in a way that creates urgency. Ideas that lack personal pain, specificity, or urgency are unlikely to succeed.
## Solve a Problem You Personally Experience
Y Combinator consistently advises founders to build products that solve their own problems.
Building from personal experience provides the following advantages:
* First-hand understanding of the problem
* Faster iteration without guessing user needs
* Higher long-term commitment to the project
### Evaluation Questions
* Have you personally encountered this problem multiple times?
* Have you attempted to solve it manually or with workarounds?
* Would losing access to this solution be frustrating?
If most answers are negative, reconsider the idea.
## Identify and Avoid Tarpit Ideas
Tarpit ideas appear attractive but are structurally difficult to succeed with, especially for small teams.
### Common Tarpit Categories
* Social networks for a niche
* Marketplaces without an existing supply base
* General-purpose productivity tools
* "Uber for X" local service concepts
* Broad AI tools with no specific user or use case
### Risks of Tarpit Ideas
* High competition and weak differentiation
* Slow or nonexistent early traction
* Heavy dependence on scale and marketing
### Heuristic
If the idea can be summarized as "X for Y," apply extra scrutiny.
## Prioritize Pain Over Novelty
Successful products address painful problems rather than novel or interesting ideas.
### Weak Indicators
* The idea sounds interesting, but non-essential
* Users describe it as "nice to have"
* There is no evidence of users searching for solutions
### Strong Indicators
* Users complain about the problem regularly
* Existing solutions are expensive or inadequate
* Users actively search for workarounds
If users are not already seeking a solution, the problem may not be significant.
## Evaluate Problem Frequency and Intensity
Problems with high value typically score high on frequency, intensity, or both.
### Frequency
How often does the problem occur?
### Intensity
How severe is the problem when it occurs?
Problems with low frequency and low intensity are unlikely to support a product.
## Define a Specific Target User
A clear user definition is required for validation and product focus.
### Poor Definitions
* Everyone
* All creators
* Small businesses
* Anyone with a smartphone
### Effective Definitions
* College students tracking daily calories
* Solo founders managing paid ads
* Developers rejected by app review processes
* Athletes preparing for competition
If the user cannot be visualized concretely, the idea is too broad.
## Motivation Check
Consider whether the idea would still be worth building without immediate monetization.
### Question
If the product could not generate revenue, would you still want to build it?
A positive answer indicates intrinsic motivation and higher resilience.
## Early Validation Signals
Positive indicators may include:
* Explaining the idea naturally without prompting
* Users expressing surprise that the product does not already exist
* Requests for early access
* Clear intuition about which features are unnecessary
These signals suggest authentic demand.
## Warning Signs
Indicators that an idea may be weak:
* Reliance on pitch decks to explain value
* Assumptions of viral growth without evidence
* Inability to name a first user
* Avoidance of early shipping
Perfectionism often masks uncertainty about value.
## Short Validation Process
Before committing significant effort:
1. Build a minimal version with limited features
2. Share it with a small group of target users
3. Ask only the following:
* Would you use this?
* When would you use it?
* What would stop you from using it?
Ambiguous or hesitant responses should be taken seriously.
## Conclusion
Strong app ideas tend to feel simple, obvious, and narrowly focused. Weak ideas often rely on scale, vision, or novelty rather than immediate usefulness. Builders should prioritize real problems, specific users, and fast validation over ambition alone.
# What happened to Expo?
Source: https://docs.rork.com/expo
Rork used to build Expo (React Native) apps. Internal benchmarks showed the agent writes better Swift apps, so we switched. Existing Expo projects keep working.
You can no longer create Expo (React Native) projects in Rork. New apps are **native iPhone (Swift)**, **native Android (Kotlin)**, or **web**. If you already have an Expo project, it keeps working: you can build it, publish it, and export the code to GitHub as before.
## Why we switched
On our internal benchmarks, the agent wrote better Swift apps than React Native apps. That is why we switched.
New iPhone apps are **Swift**. New Android apps are **Kotlin**. New web apps are **React**. Expo is still a real native stack, and many production apps ship that way.
## Two native apps, one project
React Native shares one JavaScript codebase across iOS and Android. That is a real engineering advantage.
Rork does not keep that model. An iPhone app and an Android app are two separate native apps. What stays shared is the product around them.
Build for one platform first, then add the next one. Click **+** above the preview and pick the platform:
The agent recreates your screens, navigation, data flows, and design in the new app. Both apps then live in **one project**, with:
* **Two codebases.** Swift for iPhone, Kotlin for Android. They are not one shared file.
* **One hosted backend.** If the project has Rork Cloud or Supabase, both apps talk to the same database.
* **One chat and one context.** The agent knows your whole product, so "add dark mode to both iOS and Android" can update each app.
* **One place to publish.** App Store, Google Play, and the web, from the same **Publish** menu.
The two apps can still drift. A Swift change is not the same file as a Kotlin change. The agent is how you keep them in sync. That is different from one shared React Native codebase.
## I already have an Expo project
It keeps working: you can build it, publish it, and sync it to GitHub as before.
We strongly recommend moving it to Swift. Open your Expo project and look at the panel next to the preview. Rork offers to rebuild the app in SwiftUI for you:
Click **Add iOS app** and the agent recreates your screens, navigation, data flows, and design as a native iPhone app in Swift. Your Expo app stays untouched in the same project, so nothing is lost if you want to compare them.
For Android, add the native app the same way: click **+** above the preview and pick **Android (Kotlin)**, or ask in chat:
```
Add a native Android app to this project
```
Both new apps live in the same project as your Expo app, sharing the backend and the chat, so you can move over one platform at a time.
Not sure which platform to start with? See [iPhone, Android, or web: what's the difference](/swift-vs-react-native/whats-the-difference), and [Convert your app between iOS, Android, and web](/import/convert-between-platforms) for every path between platforms.
# Billing
Source: https://docs.rork.com/faq/billing
Frequently Asked Questions about billing with Rork
## Billing
### How much does it cost?
Rork has a **Free** plan for designing your app, **Rork Pro** at **\$20/month** (100 credits), and **Rork Max** from **\$200/month** (1,000 credits and up). In India there is also **Rork Start** at **₹649/month** (40 credits).\
See [Plans & Subscriptions](/introduction/subscriptions) for what each plan includes.
### I hit my credit limit. What should I do?
Upgrade to a higher plan, or wait for your monthly reset.\
**Paid plans reset on the monthly anniversary of your first purchase.** The **Free** plan resets at the start of each calendar month.
***
## Need more help?
Still have questions?\
📩 [Contact Support](mailto:support@rork.com)
# Code Export
Source: https://docs.rork.com/faq/code-export
Frequently Asked Questions about code export with Rork
### Can I export the code?
Yes. Paid users own all generated code.\
Download it via GitHub!
### How can I export the code?
Subscribe to a paid plan, sign in with GitHub, and export through the Rork GitHub integration.
### How can I make changes locally and import them back to Rork?
Rork’s GitHub integration is **two-way sync**, so you can edit locally and import changes back to Rork.
***
## Need more help?
Still have questions?\
📩 [Contact Support](mailto:support@rork.com)
# Collaboration
Source: https://docs.rork.com/faq/collaboration
Frequently Asked Questions about collaboration with Rork
## Collaboration
### Can I collaborate with others?
Yes. Press the invite button in the project header, add your teammate's email, and pick **Editor** or **Viewer**. You can also create an invite link instead.
Full guide: [Share a project and work together](/collaborate/share-a-project).
### Who pays for a collaborator's messages?
The project owner. Everything an editor sends comes out of the owner's credits.
***
## Need more help?
Still have questions?\
📩 [Contact Support](mailto:support@rork.com)
# General
Source: https://docs.rork.com/faq/general
General FAQ questions for Rork
## How does Rork work?
Describe your app idea in plain English, and Rork generates a working app: a native iPhone app in Swift, a native Android app in Kotlin, or a web app in React. You test it right in the browser, in the iOS simulator or the Android emulator, and you can install an iPhone app on your own device. The browser preview is a great way to see how your app feels quickly, but the details may vary, and not all native features are available in the browser.
### Do I need coding experience to make my app?
Rork makes apps in minutes just from prompts. Anyone with a vision can simply describe what they want to see and bring it to life.
### Can I use Rork for professional purposes?
Yes, you can use Rork for professional purposes. We have users creating apps for Radio shows, Hospital management, and building consumer businesses from their apps.
***
## Need more help?
Still have questions?\
📩 [Contact Support](mailto:support@rork.com)
# Overview
Source: https://docs.rork.com/faq/index
FAQ master list.
# Frequently Asked Questions
We have compiled a large list of questions and answers based on frequently asked questions. Here are the main sections for those questions.
* [General](/faq/general)
* [Technical](/faq/technical)
* [Integrations](/faq/integrations)
* [Publishing](/faq/publishing)
* [Code Export](/faq/code-export)
* [Collaboration](/faq/collaboration)
* [Billing](/faq/billing)
* [Support](/faq/support)
# Integrations
Source: https://docs.rork.com/faq/integrations
Frequently Asked Questions about Integrations with Rork
### Can I integrate Rork with a database like Supabase or Firebase?
Yes. Ask Rork in chat and it connects the backend for you.\
See [How to add a Supabase backend to Rork](/backend/supabase) and [How to add a Firebase backend to Rork](/backend/firebase). If you would rather not run a backend yourself, use [Rork Cloud](/backend/rork-cloud).
### What is Rork Cloud? Does it have a database?
Yes. **Rork Cloud** is a managed backend inside Rork, with a Postgres database, server-side functions, and hosted AI models.\
You can browse your tables in the project, and you can move to your own Supabase project later.\
See [What is Rork Cloud](/backend/rork-cloud).
### How can I build apps that use AI features like chat, voice, or image generation?
Rork Cloud gives your app AI models without your own provider keys, so paid users do not manage an OpenAI account to ship an AI feature.\
You can also bring your own key and store it as a server-side secret. See [API keys and environment variables](/features/secrets).
### Can I integrate Rork with business tools like Google Sheets, Airtable, Notion, or my own API?
Yes. Just ask Rork to integrate with the service you want.\
It will ask for your API key and might need API documentation for accuracy.
### Can I import Figma files into Rork?
Copy your Figma screens as images and paste them into the Rork chat, or drag exported Figma images in in bulk.\
Rork reads the design from the picture and builds from it. There is no direct Figma connection today.
### How can I add payments with Stripe, RevenueCat, Superwall, or Adapty?
The easiest way to integrate payments into Rork is by adding RevenueCat.\
Rork recommends **RevenueCat** for in-app purchases and subscriptions. Connect it from the Monetization panel, and the agent adds the SDK to your app.\
👉 [How to add a paywall with RevenueCat](/payment-guides/revenuecat-copied-1)
### How can I add authentication to my app?
For most apps, local data storage is enough.\
For **Sign in with Google** and **Sign in with Apple**, use **Rork Auth**. It needs no backend and no OAuth setup: just ask the agent for it.\
For email and password, magic links, or phone codes, use **Supabase Auth** instead. A project uses one of the two models, not both.\
See [Add accounts and sign-in to your app](/integrations/backend/how-to-set-up-oauth).
### How can I add push notifications to my app?
Ask the agent for notifications and it wires them into your native app.\
For push notifications on Android, that means **Firebase Cloud Messaging (FCM)**; on iPhone it is Apple Push Notification service. Rork Cloud also offers push, see [Rork Cloud](/backend/rork-cloud).
***
## Need more help?
Still have questions?\
📩 [Contact Support](mailto:support@rork.com)
# Publishing
Source: https://docs.rork.com/faq/publishing
Frequently Asked Questions about publishing with Rork
## Publishing
Not sure which route to take? Start with the [publishing overview](/introduction/deploy-your-app).
### How can I share my app before it is in a store?
Publish the web app in your project and share its `.rork.app` link. Anyone can open it in a browser, with no App Store, no TestFlight, and no install. See [Rork Web](/web/rork-web).\
For an iPhone app, send testers a TestFlight link after your first submission. See [TestFlight and testers](/store-guides/testflight-beta-testers).
### How can I publish to App Store or TestFlight?
Use Rork’s built-in publishing feature: **Publish → App Store → Submit to App Store**.\
You’ll need an **Apple Developer Account**. Rork builds and uploads the app on its own machines, so no Mac, Xcode, or extra build account is needed.\
You finish the store listing (product page, pricing, screenshots) in App Store Connect.
### How can I publish to Google Play or download an .apk file?
Open **Publish → Google Play → Upload to Google Play**. Rork builds an Android App Bundle (AAB), signs it with a stable upload key, and can send it to your internal testing track.\
You create the app record in Google Play Console yourself, and you send releases for review there.\
The same build gives you an **APK download** when you want to install the app on a phone by hand.
### How can I publish to the web?
One click: **Publish → Publish to web**. Rork hosts the app at `your-app.rork.app`, and you can change the subdomain in the same panel. After the first publish you can buy a domain or connect one you own. See [Domains](/web/rork-web#domains).
***
## Need more help?
Still have questions?\
📩 [Contact Support](mailto:support@rork.com)
# Support
Source: https://docs.rork.com/faq/support
Frequently Asked Questions about support with Rork
### Do you have priority support?
**Rork Max** users get priority chat support.\
**Rork Pro** users get email support.\
On the **Free** plan there is no included support channel, but you can still write to [support@rork.com](mailto:support@rork.com).
### Rork broke my app. What should I do?
Go back a version. **Undo** sits under the last answer, and **Revert** sits under every earlier answer, so you can return to any point in the chat. Going back costs no credits.\
See [Undo a change and go back a version](/features/undo-and-history).
### Rork got in an error loop, what should I do?
Stop adding messages on top of broken work. Revert to the last answer that worked, then ask for the change again in smaller steps.\
See [How to get out of an error loop](/introduction/introduction/agent-loops).
***
## Need more help?
Still have questions?\
📩 [Contact Support](mailto:support@rork.com)
# Technical
Source: https://docs.rork.com/faq/technical
Frequently Asked Questions about technical building with Rork
## Are Rork apps actually native iOS/Android apps? Or is it just web apps?
They are real native apps. Rork writes **SwiftUI** for iPhone and **Kotlin + Compose** for Android: the same languages Apple and Google use for their own apps. New projects are Swift, Kotlin, or web. They are not a website wrapped in a web view.
Native code is designed for performance, precision, and polish. It delivers smooth animations, responsive interfaces, and immediate access to the latest platform features, from widgets and Live Activities on iOS to Material You theming and background work on Android.
Rork also builds **web apps** in React when the product belongs in a browser. Those are web apps by design, and you publish them to your own address instead of an app store. See [iPhone, Android, or web: what's the difference](/swift-vs-react-native/whats-the-difference).
### Can I use Rork to build production-ready apps?
Yes. Rork supports apps ranging from 0 users to 100k users.
### Does it work on iOS and Android?
Yes. An iPhone app and an Android app are two separate native apps, and one Rork project can hold both. Ask for the second platform at any time and the agent rebuilds your screens and flows in it. See [Convert your app between iOS, Android, and web](/import/convert-between-platforms).
### I have an older Expo (React Native) project. Does it still work?
Yes. Rork no longer creates Expo projects, but the ones you already have keep working: you can build them, publish them, and export the code to GitHub. If you want Swift or Kotlin instead, ask the agent to add a native iPhone or Android app to the project. See [What happened to Expo?](/expo).
***
## Need more help?
Still have questions?\
📩 [Contact Support](mailto:support@rork.com)
# Connecting an API to Rork
Source: https://docs.rork.com/features-apis/apis/how-to-connect-an-api-to-your-project
API's are great because they essentially allow your apps to do anything without you needing to do it.
## **Two main ways to connect an API to Rork**
\
**Environment Variables:**\
Environment Variables are Rorks native support for API's without needing to connect to a backend like Supabase. It allows the users to just enter in thier api keys and get instant access to the api.
All you have to do is click add variable, enter a name for the key describing your api, then add a value, which is your api key.\
\
After that prompt Rork to use the edge function.
Tip: attach documentation from the api provider for the best results
\
\
**Supaabase Edge Function:**\
\
Connect Supabase:\
Provide Rork with the prompt saying connect "Supabase to the app" and including the Project URL and Public Anon key.
Then navigate to edge functions:
Once in the edge function, click secret. Then name your secret and add your api key in the value.
Then copy and paste the name of your secret into Rork or ChatGPT with the prompt: "I want my app to achieve X task using this API. This is the name of my secret (insert name), make me an edge function code for this API". \
\
Then, in Supabase, click Deploy New Function:
Then click editor:
Then delete the previous code:
Paste in your code from ChatGPT or Rork, then hit the deploy function. After that, copy your endpoint URL and paste it into Rork with the prompt "Use this Edge Function to achieve X task by sending or requesting X data: \"
\
**Troubleshooting:**\
This method requires a lot more trial and error:
* Data is not being parsed, keep reprompting till it works.
* Edge function keeps failing; you may need to rewrite it a few times.
* Invalid api key, you mistyped the api key, or you need to redeploy your edge function.
# Design mode, Plan mode, and building
Source: https://docs.rork.com/features/agent-modes
Rork can design your app before it writes code, write a plan before it changes files, or build straight away. This page explains the three paths, where the switches are, and what each one costs.
Rork has three ways to answer a message. It can **design** the screens first, **plan** the work first, or **build** the change straight away. Every path ends in the same place, a working app, but they cost different amounts and give you different moments to change your mind.
| Path | Rork produces | Use it when |
| - | - | - |
| **Design mode** | Pictures of the screens, nothing built yet | You start a new app and care how it looks |
| **Plan mode** | A written plan of the work, no files changed | The change is large or touches many screens |
| **Build** | Working code in the preview | You know what you want and it is a normal change |
## Where the switches are
On [rork.com](https://rork.com), open the **+** button under the prompt box. **Plan mode** and **Design mode** sit in that menu.
The two switches are exclusive. Turning one on turns the other off.
The **Design mode** switch belongs to paid plans. On the free plan Rork still designs your app first, and pressing **Build** on the design asks you to pick a plan. The paywall says it plainly: free credits cover design, and building your app needs a plan. See [Plans & Subscriptions](/introduction/subscriptions).
Inside a project the composer has a **Plan** button instead. Its tooltip reads **Enable plan mode**. There is no Design switch inside a project, because Design mode belongs to the start of an app.
## Design mode
Design mode is the cheap way to decide how your app looks. Rork draws the screens, and nothing is built until you approve them.
Rork asks a few short questions before it draws anything, usually one to three, sometimes a follow-up. Most answers come with a small preview of the style they stand for, so you pick a look rather than describe one. Every question also offers **Surprise me** and an **Other...** box for your own words. Press **Submit** when you are done.
Rork proposes three or four screens and opens them in the **Design** tab. This is a picture of your app, not a running app.
Ask for a different screen, a different palette, or a different layout in chat. Changing a design costs far less than rebuilding a working app.
The **Review Design** card sits at the bottom of the chat. **View Design** reopens the screens and **Build** turns them into a working app.
**Build** sends one message for you: `Build a working app from the approved design.` Rork then writes the app and saves the design decisions to `.rork/DESIGN.md`, so later messages keep the same look. You can read that file in **More → Code**.
After the build, the proposal does not disappear. Find it again in **More → Design**.
Write the look into your first prompt and Rork has less to ask. "A dark, smoky roastery site with big photo cards" answers most of the questions before Rork asks them.
## Plan mode
Plan mode is for the changes that are too big to hand over blind. Rork writes down what it intends to do, and it changes no files until you agree.
Turn **Plan** on in the composer, then send your message. Rork writes a plan file under `.rork/plans/` and shows a **Review Plan** card in chat:
* **View Plan** opens the plan in the **Plan** tab.
* **Build** starts the work. It sends `Build the plan.` and turns Plan mode off.
Rork can also ask for Plan mode itself when a request looks large. The card reads **Switch to Plan Mode?** with **Approve** and **Decline**. Declining keeps it building the normal way.
Plan mode has no separate price. It uses the same build credits as any other message.
## Building
Building is the default. Neither switch is on, you describe the change, and Rork edits the code.
While it works, the chat shows what it does: **Explored 7 files**, **Made 9 actions**, **Running checks**, **Building app**. Each finished message lists the files it touched, and a preview of the result.
Rork stops and asks when a step needs you: a key it does not have, a question with several sensible answers, a design decision it cannot guess. Those arrive as cards in the chat with buttons, not as walls of text.
## Choose the AI model
The composer has a model picker. It reads **Auto** by default.
**Auto** picks the model and the reasoning effort for each message, so most people never open this menu. Pick a model by hand when you want a specific one. Models above your plan carry a **Pro** or **Max** badge, and choosing one opens the plan picker. See the full list in [Plans & Subscriptions](/introduction/subscriptions).
## Talk instead of typing
The microphone button records your voice and writes the text into the composer. Read it, edit it, then send it. Rork does not send a recording straight to the agent, so a wrong word costs you nothing.
## Attach what you already have
Use **+ → Upload image** or drop a file onto the chat. Rork reads screenshots, photos, PDFs, video, audio, and 3D models.
A screenshot is the fastest way to describe a design. Take a picture of a Figma frame, or of an app you like, and say what you want from it.
Free accounts attach files up to **10MB**. Paid plans go up to **5GB**.
## Queue the next message
You do not have to wait for the agent. Send another message while it works and Rork queues it. The queue header counts them, for example **2 Queued**, and each row can be edited or removed before its turn.
If a turn stops or fails, the queue marks itself **· Paused** so nothing runs on top of broken work. Press **Resume** when you are ready.
## FAQ
Yes, but design credits, not build credits. The free plan includes a monthly allowance for designing. Turning an approved design into a working app needs a paid plan. See [Build credits vs Cloud credits](/billing/build-credits-vs-cloud-credits).
Yes. Turn the switch off in the **+** menu, or press **Build** on the first proposal without asking for changes.
Open the **⋯** menu under any answer. It shows the model that ran, the credits it used, and the size of the context. See [Undo a change and go back a version](/features/undo-and-history).
Stop adding messages on top of it. Revert to the last good version, then describe the change more narrowly. See [How to get out of an error loop](/introduction/introduction/agent-loops).
Plans go to `.rork/plans/` and the design contract to `.rork/DESIGN.md`. Both travel with your code to GitHub. See [How to sync your project with GitHub](/tutorials/how-to-connect-github).
## Next steps
Take back a change, or go back several versions.
Generate the pictures and sounds your app needs.
Ask for an experience, not a list of features.
Invite people to view or edit the same app.
# Project analytics and revenue
Source: https://docs.rork.com/features/analytics
The Analytics tab shows how much you have built in a project and, once you connect RevenueCat, what your app earns: revenue, MRR, subscriptions, trials, and conversion.
Open **More → Analytics** in a project. The tab has two halves: **Activity**, which is about your building, and **Revenue**, which is about your app's money.
## Activity
Activity counts **the messages you sent in this project**, over the last year, as a heatmap. It is a picture of your own work, not of your users.
| Stat | What it counts |
| - | - |
| **This week** | Messages you sent in this project this week |
| **Best streak** | The longest run of consecutive days you worked on it |
| **Best day** | The busiest single day, in messages |
| **Daily avg** | Messages per day, averaged across the year |
The **Daily**, **Weekly**, **Monthly** switch and the range picker above, from **Last 7 days** to **Last 12 months**, change how the charts are grouped.
**Share** turns the graph into an image you can post. Pick what to include, press **Generate**, and Rork renders a PNG with your totals, the heatmap, and your streak.
## Revenue
Revenue comes from **RevenueCat**, the service that handles in-app purchases and subscriptions in your app. Until you connect it, this section only offers the connect button.
Rork opens RevenueCat and asks for access to your account.
Choose the project that matches this app, or press **Create new project** if you have none yet.
The section fills with your app's money.
Once connected, the tab shows:
* **Total revenue** and **MRR**, plus **ARR** and **ARPU**
* **Active subs** and **Active trials**
* **Downloads**, for the selected range and all time
* **Conversion**, and charts grouped as **Overview**, **Revenue Metrics**, **Subscriptions**, and **Conversion**
If a range has nothing in it, Rork says so rather than drawing an empty chart: "RevenueCat has no revenue points in the selected range."
Connecting RevenueCat here is about **reading** the numbers. To make your app sell subscriptions in the first place, follow [How to add a paywall with RevenueCat](/payment-guides/revenuecat-copied-1).
## Ask Rork about your numbers
**Evaluate metrics** sends your activity and revenue snapshot into the chat and asks the agent to read it. You get a written assessment in the chat: what stands out, what looks weak, and what to try next. It is a normal message, so it costs credits like any other.
## What analytics does not include
* **Your app's users.** Screen views, sessions, and retention are not here. Ask Rork to add an analytics SDK to your app if you need those.
* **Web traffic.** A published web app's visitor numbers are not in this tab.
* **Credits spent.** That lives in your account. See [Build credits vs Cloud credits](/billing/build-credits-vs-cloud-credits), or open the **⋯** menu under any answer for the cost of that single message.
## FAQ
Activity counts messages in **this project** only. Each project has its own graph.
Check that you picked the RevenueCat project that matches this app, and that the range you selected contains sales. A brand new app with no purchases yet has nothing to show.
Anyone with access to the project sees the tab. Invite deliberately. See [Share a project and work together](/collaborate/share-a-project).
Not in this tab. App Store Connect and Play Console both report downloads on their own.
## Next steps
Set up subscriptions with RevenueCat.
What to do once the numbers start moving.
What building costs you, as opposed to what your app earns.
Design mode, Plan mode, and building.
# Images, video, audio, and 3D models
Source: https://docs.rork.com/features/assets
Rork generates the pictures, video, sound, and 3D models your app needs, keeps them in the Assets tab, and puts them into the code for you. Ask for them in chat.
An app made of grey boxes looks unfinished. Rork fills those boxes for you: it generates the photography, the video, the sound, and the 3D models, then wires them into the code.
You ask for media in chat, in plain words. There is no separate generator screen to learn.
```
Replace the placeholder photos with real product shots of dark roast coffee bags
```
## Where your media lives
Open **More → Assets** in a project. Everything Rork generated, and everything you attached to the chat, is collected there.
The filters are **Images**, **3D Models**, **Videos**, **Audio**, and **Other** for files like PDFs. Each card offers:
* **Use in Chat**, which attaches that asset to your next message
* **Remove**, which deletes it from the project
* The card itself, which opens the asset full size
**Use in Chat** is the shortest way to say "this one". Attach the asset, then write "use this photo in the hero instead".
## Images
Ask in chat and Rork generates the image, saves it to Assets, and puts it in the screen you meant.
Rork generates in three shapes: square, portrait, and landscape. Say what the picture is for and it picks a sensible one:
```
Generate a landscape hero photo of a fire-lit roasting drum, dark and smoky
```
Images work the other way round too. Attach a photo and ask Rork to build a feature around generating from it, which is how photo filter apps, avatar apps, and "turn my selfie into X" apps get made. There is a full walkthrough in [the NanoBanana image app tutorial](/quick-start-examples/nano-banana-image-app).
## Your app icon
The app icon is generated the same way:
```
Generate an app icon: an ember on a dark background, no text
```
Rork writes it into the right place for each platform, so an iPhone build, an Android build, and a web app all pick it up. The icon you approve is the icon that goes to the App Store.
## Video
Ask for video and Rork generates it, then places it in the screen:
```
Add a looping background video of coffee beans falling into the roaster
```
Video generation goes further than a prompt. Rork can start from your text, from a still image, from a reference clip, or edit a video it already made. Video is the most expensive kind of media to generate, so describe the shot you want before you ask for it.
## Audio and voice
Rork generates four kinds of sound:
| Kind | Use it for |
| - | - |
| **Music** | Background loops, menu music in a game |
| **Sound effects** | Taps, wins, notifications, whooshes |
| **Voice** | A narrator, an onboarding voice, an audio guide |
| **Dialogue** | Two or more speakers in a scene |
```
Add a short success sound when the user finishes a workout
```
## 3D models
Rork generates 3D models for games, product viewers, and playful onboarding. It asks before it spends the credits, with a card that shows what it plans to make and what it will cost:
* **Yes, make the 3D model** starts the work
* **No, and tell Rork what to do differently** lets you correct the idea first
If you leave the card alone it goes ahead after about a minute and a half. Models come out in the formats iPhone, Android, and web apps can all use, and Rork bundles them into the app for you.
```
Add a spinning 3D coffee bag on the product page that users can drag to rotate
```
## Bring your own files
You do not have to generate everything. Use **+ → Upload image** in the composer, or drop files onto the chat. Rork reads photos, screenshots, PDFs, video, audio, and 3D models, and anything you upload lands in Assets.
Free accounts upload files up to **10MB**. Paid plans go up to **5GB**, which is what video needs.
A screenshot is often better than a paragraph. Show Rork the design you want instead of describing it.
## What it costs
Generating media spends **build credits**, the same balance as your normal messages. Bigger media costs more: an image is cheap, a 3D model is a few credits, and video is the most expensive of them.
Two habits keep the bill sensible:
1. Generate at the end, once the layout is settled. Placeholder boxes are free to move around.
2. Reuse from Assets with **Use in Chat** instead of generating a near-duplicate.
See [Build credits vs Cloud credits](/billing/build-credits-vs-cloud-credits) for how the balances work, and open the **⋯** menu under any answer to see what that message actually cost.
This page is about media Rork generates for you while you build. If you want your *users* to generate images or audio inside your finished app, that is a Rork Cloud feature. See [What is Rork Cloud](/backend/rork-cloud).
## FAQ
Yes, they are assets of your app. Do not ask for a real brand's logo, a real person's face, or copyrighted artwork, because the App Store rejects apps over exactly that. See the [App Review guide](/appstore-submission-checklist/app-review-guide).
Yes. Attach it with **Use in Chat** and describe the change: "same photo, but brighter and without the mug on the left".
Yes. Drop the files into the chat, then tell Rork where each one goes. Uploaded files sit in Assets next to the generated ones.
Nothing has been generated or attached yet. The empty state says it: "Files you share in chat will show up here."
Yes. See [Share a project and work together](/collaborate/share-a-project).
Yes, open the card in the Assets tab. Everything is also in your repository if you connect GitHub. See [How to sync your project with GitHub](/tutorials/how-to-connect-github).
## Next steps
A full walkthrough of image generation inside an app.
Turn a finished app into store artwork.
Let your users generate media inside your app.
Design mode, Plan mode, and building.
# Read the code and read the logs
Source: https://docs.rork.com/features/code-and-logs
Every Rork project is a real codebase you can open, read, and on a paid plan edit by hand. The Logs panel underneath shows what your app printed while it ran.
Rork is not a black box. Open **More → Code** and you get the actual project: a file tree, the source of every file, and a panel of runtime logs underneath.
You do not have to read code to use Rork. But four moments make it worth opening:
1. A bug where you want to see what the agent actually wrote.
2. A value you want to check, like a price or a piece of copy.
3. Handing the project to a developer, so you know what they will get.
4. Curiosity, which is how most people end up learning this.
## Read the tree
The tree shows one folder per app in the project, so a project with an iPhone app and a web app has two. Inside is an ordinary codebase: `src/`, `components/`, `pages/`, `package.json`, and the config files a developer expects.
One folder is hidden on purpose. Rork keeps its own bookkeeping in `.rork/`, and the tree leaves it out, except for `.rork/DESIGN.md`, the design decisions from [Design mode](/features/agent-modes).
**Copy** in the top corner copies the whole open file, which is the fastest way to paste something into another tool.
## Edit by hand
Editing code needs a paid plan. On the free plan the editor shows a banner: "Read-only. Upgrade to a paid plan to edit code." You can still read every file.
On a paid plan the editor is writable. Change a line and the header gains **Unsaved Changes**, with **Save** and **Reset All**. `Cmd + S` on a Mac or `Ctrl + S` on Windows saves too.
Two rules to know:
* You cannot save while the agent is working. The header says **Project updating...** until the turn finishes.
* Rork sees your edit. The next message works from the saved file, not from what it wrote earlier.
Hand edits are the one part of Rork with no undo of their own. **Reset All** throws away unsaved changes, and after **Save** your edit is part of the project. Ask the agent for the change instead when you can, because then it lands as a version you can revert. See [Undo a change and go back a version](/features/undo-and-history).
For anything bigger than a one-line fix, ask in chat rather than typing:
```
In src/pages/Index.tsx the free delivery threshold is $30. Change it to $45 everywhere it appears.
```
The agent finds every place, not just the one you spotted.
## Read the logs
The panel at the bottom of the Code section is titled **Logs**, with a count. It shows what your app printed while it ran in the preview, in real time, tagged by level: `[log]`, `[info]`, `[warn]`, `[error]`, `[debug]`.
Scroll up for older lines, and the panel loads them as you go. The chevron on the right collapses it when you want the whole window for code.
Logs are the fastest way out of a bug the agent cannot see. When something misbehaves without an error dialog, ask for logs first:
```
Log the data coming back from the API call so we can see why the list is empty
```
Then reproduce the problem, read the panel, and paste the interesting line into chat.
If the preview throws a visible error you do not need any of this. Press **Fix with Rork** on the error itself. See [Undo a change and go back a version](/features/undo-and-history#fix-an-error-instead-of-undoing).
## Take the code with you
The code in this tab is yours. Connect GitHub and you get it as a normal repository, with one commit per agent turn, which you can clone, run locally, and open in Xcode or Android Studio.
See [How to sync your project with GitHub](/tutorials/how-to-connect-github) and [Open your project in Xcode](/how-to-set-up-xcode/how-to-set-up-xcoe) for optional local development.
## FAQ
No. Reading is free, editing needs a paid plan. See [Plans & Subscriptions](/introduction/subscriptions).
Not silently. It reads the saved file before it changes anything. Conflicts come from editing the same lines while a turn is running, which is why saving is blocked during a turn.
Hidden from the tree, because it is Rork's own bookkeeping. `.rork/DESIGN.md` stays visible.
Not in this tab. Ask the agent instead: "which file sets the free delivery threshold?".
It says "No logs yet. Logs from your app will appear here." Interact with the preview, and anything your app prints will arrive.
Yes. Export to GitHub, then run it like any Vite, Swift, or Kotlin project.
## Next steps
Get the code into your own repository.
Review the diff of any change the agent made.
Use logs to break a cycle of failed fixes.
Why keys do not belong in the code you just opened.
# Element Selection
Source: https://docs.rork.com/features/element-selection
Select any element in the iOS, Android, or web preview and tell Rork how to change it. Rork reads the element you picked and edits that part of the app. No screenshots needed.
Element Selection works on the iOS simulator, the Android emulator, and the web preview.
## How to use it
The screenshots below show the controls in the Rork editor. The orange outlines mark where to click.
Open a project on desktop and wait for the preview to load. For an Android app, press **Turn on emulator** if it is stopped. The pointer stays disabled while the app builds or the preview reloads.
In an iOS or Android preview, hover over the pointer to see **Select an element**. In a web preview, the tooltip reads **Select an element for your prompt**. Click that button to turn on selection mode.
Click the button, card, image, or text you want to change inside the preview. Each element lights up as you hover over it. In this example, select **Shop the roast list**.
Check the name in the **Selected element** card. Type a change such as `Make this button green.` in **Describe the change…**, then press **Add** or Enter. You can also leave the field empty and describe the change in the chat.
The selected element appears as a chip in the chat composer on the left. Click the upward arrow in the bottom-right corner of the composer, **Send message**, to ask Rork to apply the change. **Add** attaches the element; **Send message** starts the edit.
You can select more than one element before you send. Each one shows as a chip in the composer, and the X on the chip removes it.
Short prompts work best here. The element carries the "where", so your message only needs the "what".
Press the pointer, click the element, write the change. Rork edits that part of the app.
## Good prompts
```
Make this button orange and move it to the bottom of the screen.
```
```
Use a larger font here and add more space below it.
```
```
Replace this image with the app icon.
```
```
Turn this list into a two-column grid.
```
## What Rork receives
Rork attaches the element's name and where it lives in your code. It does not attach a screenshot. This is why the edit lands on the exact component instead of a look-alike somewhere else in the app.
If you want Rork to see the whole screen as well, use **Screenshot** in the [iOS or Android simulator toolbar](/features/simulator#take-a-screenshot). It attaches the screen directly to your chat draft. You can also upload an image with **+ → Upload image**. The screenshot and selected element can go in the same message.
## Notes
* The pointer is available on desktop. On a phone, describe the element in words.
* The pointer is disabled while the app builds or the preview reloads. It becomes active when the preview is ready.
* Press the pointer again to leave selection mode without picking anything. In the card, Esc closes the card without adding the element.
## FAQ
All three previews: the iOS simulator, the Android emulator, and the web preview. The pointer sits in the toolbar above each of them.
Yes. Select them one after another before you send. Each element shows as a chip in the composer. Remove a chip with its X.
The preview is still building or reloading. Wait for the app to appear, then press the pointer again.
No. Element Selection is part of the normal message. The message spends build credits the same way any other message does.
Press the X on the chip in the composer, then select again. Nothing is sent until you press send.
## Next steps
Design mode, Plan mode, and building.
Replace the element's picture with one Rork generates.
Roll back a change you did not like.
Write messages Rork gets right the first time.
# Image Generation
Source: https://docs.rork.com/features/imagegeneration
This document outlines how you can use AI Image Generation with your Rork applications.
Rork makes it super easy to quickly generate assets or connect functionality in your app with AI image generation. You can even generate your App Icon within the editor. Lets go through all the use cases.
For video, audio, and 3D models, and for where generated media is stored, see [Images, video, audio, and 3D models](/features/assets).
## **Generate your Image Icon**
You can have Rork generate your image icon just by saying "Please update our app icon by generating an image for it. \{Describe any custom details for your icon}" in the Rork editor for your project.
You can also quickly generate an icon by clicking on the project settings by clicking on your Project Title on the top left, and then pressing "Generate Icon".
If all goes correctly, you should see a new icon generated and your app updated! This icon will transfer to your actual published app on the App Store.
## Using Image Generation functionality within a Project
You can create text to image or image to image generation functions for your Rork project. This can be helpful if you are making an app like a Polaroid app, that takes a picture of you and then generates an image in a polaroid for you.
Here is an example prompt for that:
> Please add an AI image generator / NanoBanana for this camera app. When a user takes a photo with this camera app, instead of returning the actual photo, generate a polaroid version of that image. Ask the user what celebrity that want in the picture before generating the image.
This will generate a project thats main function is to take pictures and turn them into polaroids with celebrities.
# What is an API?
Source: https://docs.rork.com/features/index
An external third party API can enhance the functionality of your apps and help you build the unthinkable. This document explains what they are, which ones are already available on Rork, and how to quickly add new custom ones.
## So you've built an awesome app on Rork...
But now you want to take it to the next level. Maybe your users want a new feature that requires more complicated tooling. For example, a Photo app made in Rork might want to add AI filters when people take pictures, or a music discovery app could add a way to detect genres from song recordings. Whatever you are building on Rork can be iterated and improved upon. That's the power of **External APIs** and our state-of-the-art app builder inside Rork.
### What is an API?
In its simplest explanation, an API can be seen as a **contract**. A contract binds specific agreements that two parties agree to. Imagine the two parties are your app and another. In the same way, an API says, "If you provide this API with Data A from your app, this company promises to provide you with Data B from their services".
> For example, you may be building an app on Rork that helps you find the best restaurants near you with your dietary preferences. In order to get a list of restaurants in a nearby location, you would look for an API like Googles Maps API. In your app, you would grab the location of your user (Rork can do that easily) and then send that data to the Google Maps API (See later in docs on how to do this), and in return, the contract promises to give you a list of restaurants.
Developers rely on this contract not to change, as any changes can break their application. That's why APIs have documentation and clear schemas on how it works.
### What is an External or Third-Party API?
To answer this, let us answer what an internal API is. An API is a contract between two parties. That can be internal too! For example, when you submit a prompt to Rork, we are using an internal API we built on our backend to process your prompt and build your app. That is an internal API that does not require a third party.
A third party or external API is controlled and maintained outside of Rork. These are not necessarily in our control, but Rork can help you connect and maintain your connection to those APIs. A few examples of third-party APIs include (but are not limited to):
### How to find the Right API for your project
For AI image, video, audio, or 3D generation you do not need an external API at all. Rork generates that media for you, and [Images, video, audio, and 3D models](/features/assets) explains how to ask for it. For any other feature you need, read on.
1. **Determine the feature change on your app**\
This is the single change that you want to see in your application that is different from its current state. If you cannot name the change you want to see, it will be difficult to find an API to solve for it. Make sure it's simple, or else it may fail the feasibility test in the next step. Another way to think about this is what data sources you currently have (users' location, their food preferences, photos they took, etc), and what you want to see done with that data.
2. **Run a feasibility check on it**\
In ChatGPT, Gemini, or any other web search-driven LLM, you can search for APIs by the following prompt:
> I am building a mobile app. Its (describe your mobile app briefly). Currently, the functionality is (explain current functionality and data sources that you have). I would like to add/change to (new change you determined in step 1). Please search the web and find any reliable and well maintained APIs that I can plug in to help me with this.
This will determine if your request is feasible or not. This is an important check that all developers do before they use a new API. Otherwise, you risk using something that does not work for your use case, or it breaks on you because it is not well-maintained.
3. **Sign up for that API, Find the Documentation, and Generate your Credentials**\
Most APIs will require you to make an account with them and also create some sort of authentication credential. This changes per API, but usually it is an API key and or some authentication request. This can get confusing manually, so in the same ChatGPT thread, ask it to help you figure out exactly what credentials you need. Just link the documentation and ask:
> What are the keys/credentials I need to use this API, and how do I generate/find them? I need them to add into my Rork app afterwards. Please also generate the instructions for how to use the API that I can pass into the Rork AI editor to make changes on my mobile app.
4. **You are ready to pass this information to Rork and build your new feature!**\
Please refer to the next section on how to pass this information into Rork and build your new changes.
Now that you have done the work required to determine the proper API to use in your project, we can pass all of that information into Rork and build it out. Here are the best practices in doing so:
### How to tell Rork to use External APIs
1. Let's build up a simple set of rules that we will pass into our Rork editor to add our functionality:
1. **We want to change this (current feature on the app) to this (new feature for the app).**
2. **In order to do this, we will use the external API (name of External API).**
3. **Here is the full documentation of what we need: (Copy the documentation or paste the instructions that you asked ChatGPT to generate in Step 3 of the previous part)**
4. **Here are my credentials needed to use that API: (Paste your credentials that you found through Step 3 of the previous part)**
2. Pass those filled-out 4 sentences into the Rork editor. Rork will intelligently determine the best way to add the API to your codebase and application.
3. Test your new changes on your application and iterate if anything is broken.
4. **Troubleshooting tips:**
1. If the function fails, you should be able to send the error to Rork and have it fix it. If it doesn't show a proper error, ask Rork: **Log the call to the API so we can debug why it's failing**.
2. If the function works, but the data you receive isn't what you expected or is missing something, ask Rork: **Log the returned data from the API call so we can utilize it the proper way for our app**
5. Congrats! You've just increased the value of your app and added an external API! Share what you're building with us on our Discord *(Linked on the top left of the Docs)*. We'd love to see how you're using external APIs!
# API keys and environment variables
Source: https://docs.rork.com/features/secrets
Store API keys in your Rork project instead of pasting them into code. This page explains the Secrets editor, which variables reach the phone, and how to keep a private key private.
Most useful apps need a key: a weather API, an email sender, a payment provider, a model provider. Those keys belong in your project's **Secrets**, not in your code and not in a chat message.
## Where secrets live
Open **More → Secrets** in a project.
A new row appears with a **Key** and a **Value**.
`RESEND_API_KEY`, `STRIPE_SECRET_KEY`, `OPENWEATHER_API_KEY`. Use the exact name the provider's documentation uses.
Rork hides it straight away. The eye button reveals it when you need to check it.
Rork stores the variable and rebuilds the parts of your app that need it.
Adding several at once is faster with **Bulk Edit**. Paste one variable per line as `KEY=value`.
## How far a variable travels
The label under each key is the important part of this page. It tells you who can read that value.
| Label | Where the value goes |
| - | - |
| **Server-side only** | Stays on the server. Your users can never read it |
| **Available at build time** | Baked into the app when it is built |
| **Available to all users** | Shipped inside the app, readable by anyone who installs it |
The rule that decides this is the name. A variable whose name starts with `EXPO_PUBLIC_` is sent to the app itself, and everything else stays server-side. The editor repeats the rule at the bottom: "Prefix with `EXPO_PUBLIC_` to make a variable available on the client-side".
Never give a secret key an `EXPO_PUBLIC_` name, and never paste one into your app's code. Anything shipped inside an app can be extracted from it, which means a leaked key on your account, used by strangers, billed to you. A private key belongs in a **Server-side only** variable, used by a server function.
Two examples make the split clear:
* `EXPO_PUBLIC_SUPABASE_URL` is fine as a public value. It is an address, and it is protected by database rules.
* `STRIPE_SECRET_KEY` must be **Server-side only**. It can move money.
If your feature needs a private key, ask Rork for a server function and it will build one:
```
Send the confirmation email from a server function so the Resend key stays private
```
Some rows are marked **Managed by Rork** or **Managed by the Supabase integration**. Rork writes and rotates those itself, so leave them alone.
## When Rork asks you for a key
You usually do not open the Secrets editor at all. When a build needs a key, Rork stops and asks in chat, with one field per key and a short description of what each one is for. Paste the values and press **Save & Continue**, and the build carries on where it stopped.
When Rork already knows the values, for example after an integration, the card asks you to confirm instead: **Yes, set them**.
## Who can see your keys
| Role | Secrets |
| - | - |
| Owner | Can read and edit |
| Editor | Can read and edit |
| Viewer | Sees the panel, cannot edit |
So an editor on your project can read your keys. Invite editors accordingly. See [Share a project and work together](/collaborate/share-a-project).
A cloned project carries your variables over, except the keys Rork manages itself, which it mints fresh for the copy.
## Rotate a key you leaked
If a key ends up somewhere public, changing it in Rork is not enough. Do it in this order:
Delete or rotate it in the provider's own dashboard. That is what actually stops the key from working.
Copy the new value.
Same key name, new value, then **Save**.
If it was in your code, ask Rork to remove it and to read the value from the variable instead.
## FAQ
Prefer the Secrets editor, or the card Rork shows when it needs a key. Both keep the value out of the conversation.
No. They live with the project, not in your code, so they are not committed. Set them again in any environment you run the code yourself. See [How to sync your project with GitHub](/tutorials/how-to-connect-github).
Per project. A project with an iPhone app and a web app shares one set of variables.
Reload the preview first. If it is a native app, the value is baked in at build time, so it needs a new build. If the name is missing the `EXPO_PUBLIC_` prefix, the app cannot read it by design, and the call belongs on the server.
Not necessarily. Rork Cloud gives your app models without your own provider keys. See [What is Rork Cloud](/backend/rork-cloud).
Connecting Supabase sets them for you and marks them as managed. See [How to add a Supabase backend to Rork](/backend/supabase).
## Next steps
Use a third party API with your new key.
A backend inside Rork, with server-side keys handled for you.
Who can read your secrets, and who cannot.
Set up in-app purchases with RevenueCat.
# Rork simulator
Source: https://docs.rork.com/features/simulator
Test your app, take screenshots, and record the screen right in Rork. Attach captures to the chat or download them to share what you are building.
The simulator lets you use your app while you build it, right inside Rork. Open screens, press buttons, and try a flow before asking for the next change.
You can also take screenshots and record your app without opening another tool or saving files just to upload them back to Rork. Capture a screen for feedback, record a quick demo, or show a friend what you are building.
## Open the simulator
Open your project and select the iPhone or Android app in the platform switcher above the preview. Start the preview if it is stopped, then wait for your app to finish building and appear on screen.
An iPhone app runs in the iOS simulator. An Android app runs in the Android emulator. Both support the screen capture controls below.
Use the preview to click through your app and scroll through its screens. When something needs changing, describe it in the chat. You can attach a screenshot or recording to show Rork what you mean.
## Screen capture
The toolbar above the simulator has two buttons: **Screenshot**, with a camera icon, and **Record**, with a video camera icon. They become available once your app is running.
### Take a screenshot
1. Open the screen you want to capture in the simulator.
2. Click **Screenshot** in the toolbar.
3. The image appears as an attachment in your chat draft. Add a message describing what you want to change, then press **Send message**.
For example: “The Continue button is too close to the bottom. Give it more space.”
### Record the screen
1. Open the screen where you want the recording to begin.
2. Click **Record** and wait for the three-second countdown.
3. Use your app as usual. Click through screens or repeat the interaction you want to show. A red border and timer indicate that recording is active.
4. Click the red stop button beside the timer when you are done. Rork saves the video and attaches it to your chat draft.
5. Add a message and send it when you want Rork to act on the recording.
For example: “After I press Continue on the second screen, the next screen stays blank. Please fix it.”
Recordings stop automatically at **60 seconds**. The stop button and timer appear in the toolbar or below the device, depending on the space available.
To cancel before recording starts, click **Cancel** during the countdown. To throw away an active recording, click the trash icon and confirm **Discard**.
## Download and share a capture
Click the screenshot or video attachment to open it, then use **Download** in the preview. Recordings download as MP4 files.
You can share the file in a post, send it to a friend, or use it to ask for feedback. Capturing adds the file to your draft; you choose whether to send a message to Rork.
## Common questions
Wait for the app to start in the simulator. The controls also stay disabled while a capture is being saved or a recording is active. Stop or discard the recording before taking another screenshot.
No. It captures the app's simulator screen. Your Rork chat, browser tabs, and the rest of your desktop are outside the capture.
Use [Element Selection](/features/element-selection) to pick a button, image, or other element and describe the change. Use a screenshot when you want to show the whole screen, or a recording when the issue happens across several interactions.
## Keep building
* [Test on your iPhone](/rork-max-swift) to try the app on a real device.
* [Share your project](/collaborate/share-a-project) when someone should open the app themselves.
* [Build credits vs Cloud credits](/billing/build-credits-vs-cloud-credits) explains how simulator time is billed.
# Undo a change and go back a version
Source: https://docs.rork.com/features/undo-and-history
Every Rork message is a version you can return to. Undo the last change, revert to any earlier answer, review the exact files that changed, and stop a message that is going the wrong way.
Nothing you do in Rork is final. Each answer from the agent is a saved version of your whole project, so you can always go back to the last one that worked.
Going back costs no credits.
## Undo the last change
The last answer in the chat has an **Undo** button under it. Press it and Rork rolls the files back, then removes that exchange from the chat. There is no dialog, because there is nothing to lose: the version you land on is the one you had a minute ago.
Use **Undo** when the last change made things worse and you want the previous state back immediately.
## Go back several versions
Earlier answers show **Revert** instead of **Undo**. It puts your project back to how it looked right after that answer.
Revert asks first, because you may lose work that came later:
After you confirm, Rork restores the files and trims the chat: the messages up to that answer stay, and everything after it goes. A toast tracks the work, first **Restoring project...** and then **Version restored**.
Revert is not reversible. The versions after your target are no longer at the top of the history. Before a big revert, ask yourself whether you only need the last change undone.
You cannot revert while the agent is working. The button explains why: "Hang tight, the agent's still working. Stop the message to revert here."
## Edit a message and try again
Sometimes the answer was fine and the question was wrong. Hover an earlier message of yours and press **Edit message**. Fix the wording and press **Send**.
Rork puts the project back to the state before that message, drops everything that followed it, and answers your new wording. It is a revert and a retry in one step, and it is the cleanest way out of a conversation that went sideways.
## See exactly what changed
Every answer can show its own diff. Open the **⋯** menu under the answer and choose **Review changes**.
The same menu answers "what did that cost?". It names the model that actually ran, the credits the message used, and how much context the agent carried.
**Review changes** opens a full-screen diff of every file the answer touched, compared with the version before it. The header counts the files, and **ESC** closes it.
Read the diff before you publish, and after any change you did not fully understand.
## Stop a message that is going wrong
While the agent works, the send button becomes a stop button. Press it and Rork finishes the step it is on, saves what it already did, and stops.
Stopping is safe and cheap:
* The partial work stays in the chat, marked **Stopped**, with the progress saved.
* Your prompt comes back into the composer, so you can reword it and send it again.
* A build that never finished is not charged.
Stop early. A long turn heading in the wrong direction costs more than a stop and a better prompt.
## Fix an error instead of undoing
If the preview throws an error, Rork shows it and offers to fix it. The dialog is titled **Runtime error** and the button says **Fix with Rork**. With several errors you get **Fix all with Rork**, or a count, and **Dismiss**.
By default, pressing that button sends the fix request straight away. You can change that in **Account settings → Preferences**:
Two more places offer the same help. An answer with TypeScript problems gets a **Fix errors** button, and the **Logs** panel in **More → Code** shows what your app printed at runtime, which is what you paste into chat when an error is not obvious.
## What a version actually is
One answer from the agent equals one saved version of the project. Rork commits your files at the end of each turn, together with the chat history, so the chat and the code can never drift apart.
That has two useful consequences:
* The list of versions is the chat. There is no separate history panel to learn.
* Your project history travels with your code. Connect GitHub and you get the same commits in your own repository. See [How to sync your project with GitHub](/tutorials/how-to-connect-github).
## FAQ
No. Going back to an earlier version is free. You only pay for messages that do work.
To any answer in the chat. Scroll up and older messages load as you go.
No. Cancel the dialog if you are unsure, and prefer **Undo** when you only need the last change back.
No. Your live web app or your submitted build stays as it is until you publish again. See [Rork Web](/web/rork-web).
Environment variables are not part of the code version. Check **More → Secrets** after a revert. See [API keys and environment variables](/features/secrets).
Revert to the last good version first, then narrow the request. [How to get out of an error loop](/introduction/introduction/agent-loops) walks through it.
## Next steps
Design mode, Plan mode, and building.
What to do when the same fix keeps failing.
Keep the same history in your own repository.
Who can revert, and who can only look.
# Build a game with Rork
Source: https://docs.rork.com/games/build-a-game
Rork builds 2D and 3D games without a game engine: SpriteKit and RealityKit on iPhone, three.js in the browser. It generates the 3D models, the animations, and the sound for you.
You do not need Unity, Unreal, or any game engine. You describe the game, and Rork writes it with the tools the platform already has, then generates the art, the models, and the sound to fill it.
## Start a game
The prompt box on [rork.com](https://rork.com) has two shortcuts for games.
* **Create a 3D Game** fills in `Create a 3D game with realistic physics about...`
* **Create a Multiplayer Game** fills in `Create a multiplayer game about...`
Both also switch the platform to **web**, because a browser game is the fastest way to see something playable. Finish the sentence with your idea, and change the platform first if you want a native app instead.
You do not have to use the shortcuts. Describing the game in your own words works the same way:
```
A 3D pet game. You feed, wash and play with a puppy in a garden, and its mood
and hunger change over time.
```
## Pick web or native
The same idea takes a different shape depending on where it runs. Decide this before you build, because it changes the engine, the distribution, and the plan you need.
| | Browser game | iPhone game |
| - | - | - |
| **2D** | HTML canvas | SpriteKit |
| **3D** | three.js with React Three Fiber, physics with Rapier | RealityKit |
| **Share it** | A link, playable immediately | App Store review, then an install |
| **Feels like** | A web page that plays | A real app at native speed |
| **Plan** | Any paid plan | Rork Max, which lists "Games with native performance" |
Start in the browser to find out whether the game is fun. Move to native when it is, and when you want the App Store, Game Center, or the frame rate. See [Plans & Subscriptions](/introduction/subscriptions) and the [Rork Games page](https://rork.com/games).
Android games are not a documented path today. Build for the browser or for iPhone, and remember a browser game already runs on an Android phone.
## Fill the world with generated assets
This is the part that usually stops people making a game alone. Rork generates the pieces in the chat, and puts them into the scene:
* **3D models.** Ask for a prop, a vehicle, or a character. Characters come out rigged, so they can be animated.
* **Animations.** Walk, idle, jump, each as its own clip.
* **Sprites and 2D art** for canvas and SpriteKit games.
* **Music and sound effects**, and voices for characters.
```
Add a 3D low poly treasure chest that opens when the player touches it
```
Rork shows you a preview and the price before it spends anything on a 3D model, and you approve or ask for something different. On iPhone, models are bundled into the app as USDZ. On the web, they load as GLB.
What the pieces cost in build credits:
| Asset | Credits |
| - | - |
| 3D model | about 3 |
| 3D model, low poly | about 1.5 |
| Rigging a character | about 0.5 |
| Each animation clip | about 0.3 |
| Sprites, music, sound effects | varies with size and length |
3D generation works on every plan. See [Images, video, audio, and 3D models](/features/assets) and [Build credits vs Cloud credits](/billing/build-credits-vs-cloud-credits).
## Iterate by showing, not describing
Games are visual, and words are slow. The fastest loop is: look at it, screenshot what is wrong, send the picture.
Short, specific asks work better than a list:
```
The camera is too close. Pull it back so the whole garden is visible.
```
```
The jump feels floaty. Increase gravity and shorten the hang time.
```
## Play it while you build
A browser game runs in the preview next to the chat, so you play it as you go.
An iPhone game needs a simulator, and the simulator costs credits while it runs.
Turn it on to play, and stop it when you are done. The toolbar above the phone can also record the screen and take screenshots, which is where your store video and your first social post come from.
To feel the real frame rate, put the game on a real phone. See [Rork Max app for iPhone](/rork-max/rork-max-app).
## Multiplayer, honestly
Rork has no multiplayer product that you switch on. It writes the multiplayer code into your game, and how hard that is depends on the kind you want.
**Straightforward:** turn-based play, two players on one device, and rooms with a code.
**Harder:** real-time online play. It needs matchmaking, state syncing between players, and rules for what happens when somebody's connection drops. Rork's own FAQ says it plainly: expect a few rounds of iteration.
How it is built:
* **In the browser**, Rork writes a small server with Cloudflare Workers and Durable Objects, and the players talk to it over WebSockets.
* **On iPhone**, Rork uses **Game Center**, which brings real-time and turn-based matches, sign-in, leaderboards, and achievements for free.
* **Voice chat** is separate from the game state, and Rork hosts the servers that make it work.
Start turn-based and add real-time later. A turn-based game that works beats a real-time game that desyncs.
## What to expect
Generated games are real games, not tech demos, but they have a ceiling. Keep scenes in the range Rork targets: roughly a thousand moving things, a few hundred thousand triangles, textures that fit comfortably in memory. Ask for a low poly model when a detailed one is not needed, since it costs less and runs faster.
Some things are not what Rork does:
* **No Unity or Unreal**, and no importing a project from them.
* **Leaderboards** come from Game Center on iPhone. A browser game needs a backend, which Rork can build with [Rork Cloud](/backend/rork-cloud).
* **Selling things in the game** goes through the normal in-app purchase route. See [How to add a paywall with RevenueCat](/payment-guides/revenuecat-copied-1).
## Ship it
A browser game publishes like any web app: press **Publish**, and share the address. See [Rork Web](/web/rork-web).
An iPhone game goes to the App Store like any other app. Games get read carefully in review, so run the [AI App Store Reviewer](/ai-app-store-reviewer) first, and be careful with anything that looks like gambling, loot boxes, or a copied character. See [Publish your app](/introduction/deploy-your-app).
## FAQ
For a native iPhone game, yes. Max is the plan that lists "Games with native performance". Browser games work on any paid plan, and 3D generation works on every plan.
No. Rork writes games with SpriteKit, RealityKit, and three.js, so an engine project cannot be brought across.
Yes. Drop them into the chat and say where they go. Generated and uploaded models sit together in the Assets tab.
Yes, 0.2 build credits per minute while it runs. The panel says so before you start it, and stopping it stops the charge.
Yes, invite them as editors, though only one message runs at a time. See [Share a project and work together](/collaborate/share-a-project).
Say what is slow and where. Common fixes are fewer objects on screen, low poly models, and smaller textures. The logs in **More → Code** show what the game prints while it runs. See [Read the code and read the logs](/features/code-and-logs).
## Next steps
How the 3D, audio, and image tools work.
Pick the platform before you build.
Install the game on a real device.
The product page, with examples of what Rork builds.
# Open your project in Xcode
Source: https://docs.rork.com/how-to-set-up-xcode/how-to-set-up-xcoe
An optional workflow for developers who want to export a Rork iPhone app through GitHub and build or debug it locally on a Mac.
You can [test your app in the Rork simulator](/features/simulator), [run it on your iPhone](/rork-max-swift), and [publish to the App Store through Rork](/store-guides/publish-app-store) without opening Xcode. Follow this guide only if you want to work with the exported Swift project on your own Mac.
## When to use Xcode
Use Xcode when you or a developer want to step through the Swift code, debug on a connected device, or build and archive the app manually. Start by [syncing your project with GitHub](/tutorials/how-to-connect-github).
**Requirements**
* A Mac
* Xcode installed
* Your project connected to GitHub
* GitHub Desktop installed (or `git` in the terminal)
* An Apple Developer account
### Installing Xcode
Download Xcode from the App Store
Then install the command line tools and accept the license:
```shellscript theme={null}
xcode-select --install
sudo xcodebuild -license accept
```
### Opening your Rork project in Xcode
Rork iPhone apps are native Swift projects, so Xcode opens them directly. There is nothing to generate first.
Connect to GitHub
Go to GitHub
Open with GitHub Desktop
Now open a terminal in the project folder and run:
```shellscript theme={null}
xed .
```
Your project opens in Xcode. If your project holds more than one app, run the command inside the iOS app folder.
Xcode resolves the Swift packages your app uses on the first open. Wait for that to finish before you build.
### Run the app
* **Simulator:** pick a simulator in the toolbar and press the play button.
* **Your own iPhone:** plug it in, select it in the toolbar, then press play. Your device needs Developer Mode, under **Settings → Privacy & Security → Developer Mode**.
Open the debug console at the bottom of the window to read the logs while the app runs.
### Publish to the App Store (via TestFlight)
Navigate to "Product" and click "Archive."
When the archive finishes, the Organizer opens. Choose **Distribute App**, then **App Store Connect**, and your build appears in TestFlight.
## Troubleshooting
**The build fails right after opening the project.** Xcode may still be resolving Swift packages. Wait for it to finish, then build again.
**A Swift package fails to resolve.** In Xcode, choose **File → Packages → Reset Package Caches**, then build again.
**Stale build errors that make no sense.** Clean the build folder with **Product → Clean Build Folder** (Shift + Command + K), then build again.
**Signing errors.** Open the project settings, select the target, then **Signing & Capabilities**, and pick your Apple Developer team.
# Convert your app between iOS, Android, and web
Source: https://docs.rork.com/import/convert-between-platforms
Convert an Android app to iOS with AI (or the reverse), turn a React Native codebase into native Swift and Kotlin, and ship every platform from one Rork project.
A Rork project isn't locked to one platform. One project can contain a **native iOS app (Swift)**, a **native Android app (Kotlin)**, and a **web app**. Each app has its own code. They can share one chat and one backend. That makes "convert my app to another platform" a feature, not a rewrite from scratch.
## Convert an Android app to iOS (with AI)
Have an Android app (in Rork, or imported from a repository) and want it on iPhone?
1. If the app isn't in Rork yet, [import its repository](/import/import-from-github) first, Kotlin/Java source included. The agent reads it even though the new iOS app will be Swift.
2. In the project, ask in chat:
```
Create an iOS version of this app
```
3. Confirm the **"Add iOS app?"** widget. The agent rebuilds the screens with native iOS UI, reusing the same backend, data model, and business rules.
4. Preview it in the iOS cloud simulator, then [publish to the App Store](/store-guides/publish-app-store).
## iOS app → native Android app
The mirror path. In your iOS project, click **+** (Add preview platform) → **Android (Kotlin)**, or ask in chat:
Rork builds a native Kotlin app in the same project. Publishing: [create the AAB for Google Play](/submitting-to-play-store/creating-the-aab-file).
## React Native / Expo codebase → native app
Already have a React Native or Expo codebase (from Bolt, a contractor, or your own work)? Rork rebuilds it as native code.
1. Push it to GitHub if it isn't there already.
2. Import it: **GitHub to Mobile App** on [rork.com](https://rork.com) → paste the repo URL → **Generate app now**.
The agent reads your JavaScript or TypeScript source, then rebuilds the screens, navigation, data flows, and design as a **native iPhone app (Swift)**, a **native Android app (Kotlin)**, or a **web app**, whichever you pick. Your product stays the same. The UI code becomes Swift, Kotlin, or React.
From there, publishing runs through Rork: the built-in Publish flow handles the build and the App Store or Google Play submission, so there is nothing to configure yourself.
Not sure which platform to pick? See [iPhone, Android, or web: what's the difference](/swift-vs-react-native/whats-the-difference).
## Mobile app → web app
Any mobile project can grow a web version: **Project Settings → Add new app → Web**, or ask:
```
Add a web version of this app
```
The web app publishes to a `your-app.rork.app` URL from the **Publish** menu (you can attach a custom domain later). Great for landing pages, admin panels, or a desktop companion.
## Every combination at a glance
| From \ To | iOS (Swift) | Android (Kotlin) | Web |
| - | - | - | - |
| **iOS (Swift)** | n/a | Add platform / chat | Add platform / chat |
| **Android (Kotlin)** | Add platform / chat | n/a | Add platform / chat |
| **Web (incl. imported sites & builders)** | Add platform / chat | Add platform / chat | n/a |
| **React Native / Expo (imported repo)** | agent rebuilds it natively | agent rebuilds it natively | Add platform / chat |
"Add platform / chat" = click **+** in the project header, use **Project Settings → Add new app**, or just ask the agent.
## Per-app settings
Each app in the project has its own icon, home screen name, and bundle identifier / package name. Configure them in **Project Settings** before publishing:
## Publishing each platform
* **iOS**: [Publish to the App Store](/store-guides/publish-app-store) directly from Rork:
Every submission (and its TestFlight link) is tracked in the project's **Publish** dialog:
* **Android**: [generate the AAB and upload to Google Play](/submitting-to-play-store/creating-the-aab-file).
* **Web**: one click in the project's **Publish** menu.
## FAQ
### Is the conversion a literal code translation?
No, and that's a good thing. The agent rebuilds the UI with each platform's native components while keeping your product identical: same screens, same flows, same data. You get apps that feel right on each platform instead of a lowest-common-denominator port.
### Do the platforms stay in sync afterwards?
They share the project, the backend, and the chat. When you ask for a feature, tell the agent which apps it applies to ("add dark mode to both iOS and Android") and it updates each native codebase.
### Can I have different features per platform?
Yes. It's common to keep the field-crew features mobile-only and add an admin dashboard as the web app.
# Move your project from any app builder to Rork
Source: https://docs.rork.com/import/import-from-any-app-builder
Migrate a project from Bolt, v0, Replit, FlutterFlow, Bubble, Glide, Softr, or Base44 into Rork and get a native mobile app: export your code to GitHub, then import. Includes per-builder export steps.
Built something in another AI builder or no-code tool and want it as a real native mobile app? The recipe is almost always the same:
1. **Get your project into a GitHub repository** (every serious builder has an export or sync).
2. **Import that repository into Rork** with [GitHub import](/import/import-from-github).
3. Rork reads your real source files and rebuilds the product as a native iOS / Android app.
If your source tool doesn't export code at all (some no-code tools don't), skip to [No code export?](#no-code-export-import-it-anyway), you can still migrate.
## Step 1. Export your project to GitHub
How to get a repository out of each popular builder:
### Lovable
Lovable has first-class GitHub sync, and Rork has a dedicated one-click import for it. Use the dedicated guide: [Convert your Lovable app to a mobile app](/import/lovable-to-mobile-app).
### Bolt (bolt.new)
Bolt can push your project to GitHub: open your project → toolbar → **Connect to GitHub** (or **Export → Download** as a ZIP and push it yourself). Bolt generates standard web projects, and React Native projects if you asked for mobile. Rork imports either one and rebuilds it as a native app.
### v0 by Vercel
v0 projects live in Git already if you've pushed them: use **Add to codebase / Download ZIP**, or connect your v0 project to a Vercel Git repository. Import the resulting repo into Rork.
### Replit
In your Repl: **Git pane → Connect to GitHub → Create repository**, then push. Replit Agent apps are normal source code underneath, so they import cleanly.
### FlutterFlow
**Settings → Integrations → GitHub → Connect** exports your generated Flutter code (paid plans), or use **Download Code**. Rork doesn't build Flutter apps; instead, the agent reads your screens, logic, and data structure from the Dart code and rebuilds the app natively. Mention in your prompt that the source is Flutter.
### Softr / Glide / Bubble (no code export)
These platforms don't export usable source code. See [No code export?](#no-code-export-import-it-anyway) below.
### Base44 / other AI builders
Most AI-first builders (Base44, Create, Databutton, and similar) offer GitHub sync or a code download. Find **GitHub / Export code** in your project settings, get the repo, import it.
If you only have a ZIP: create an empty repository on GitHub, unzip it locally, then run the commands below in the unzipped folder. Replace the URL with your own repository. That's enough for Rork to import.
```
git init
git add .
git commit -m "Initial import"
git branch -M main
git remote add origin https://github.com/YOUR-NAME/YOUR-REPO.git
git push -u origin main
```
## Step 2. Import the repository into Rork
1. Go to [rork.com](https://rork.com) and click **GitHub to Mobile App** under the prompt box.
2. Paste the repository URL.
3. Click **Generate app now**, or **I have extra requests** to describe what you want changed during the migration (this is a great moment to ask for native-first navigation, or to drop features you no longer need).
The agent sets up GitHub Sync, audits your source (screens, routes, data models, integrations, env vars), and rebuilds the app natively:
## Step 3. Reconnect your backend
Your data layer usually survives the migration as-is:
* **Supabase / Firebase**: give the agent your project URL and your public client keys as environment variables, and the mobile app talks to the same database and auth as before. For Supabase use the publishable key (the legacy name is `anon`), and keep Row Level Security on. For Firebase use the public client configuration. See [Supabase](/backend/supabase) and [Firebase](/backend/firebase).
* **Custom API**: the agent reads your API calls from the imported source and reuses the same endpoints.
* **No backend yet**: ask the agent to set one up with [Rork Cloud](/backend/rork-cloud).
Never put a Supabase secret key (the legacy name is `service_role`) or any private API key in the app. Anyone can read the keys inside a shipped mobile app. Keep private keys on the server side, in [Rork Cloud](/backend/rork-cloud) or a Supabase Edge Function.
## No code export? Import it anyway
If your current tool (Softr, Glide, Bubble, Adalo, and similar) won't give you source code, you can still migrate. You just start from the product instead of the code:
1. Take **screenshots of every screen** of your existing app and attach them to your first prompt in Rork.
2. Add the **public URL** of the app so the agent can study the flows.
3. Describe the data model in plain words ("users, orders, each order has line items...").
4. If your data lives in Airtable / Google Sheets / Supabase, tell the agent, it can connect to the same data source or import the data.
You'll be surprised how close the first generation gets when it has real screenshots to work from.
## Why not just wrap my existing app in a webview?
Wrapper services put your website inside a native shell. It works until it doesn't: Apple regularly rejects thin wrappers (Guideline 4.2, Minimum Functionality), push notifications and offline are unreliable, and the app never feels native. Rork rebuilds the UI natively while preserving your product and data, which is what the stores expect.
## FAQ
### Which builders does Rork import from best?
Anything that exports real source code: Lovable, Bolt, v0, Replit, Cursor projects, hand-written apps. FlutterFlow works via code reading. Softr/Glide/Bubble require the screenshot approach.
### Will everything be migrated 1:1?
The agent preserves your product: screens, flows, branding, and data model. Pixel-perfect parity isn't the goal: native mobile patterns (tab bars, native gestures, push notifications) usually make the app better than a straight copy.
### Can I keep the old web app running?
Yes. Import doesn't touch your original project. Many builders run the old web app and the new Rork mobile app side-by-side on the same backend, then consolidate later.
# Import a GitHub repository into Rork
Source: https://docs.rork.com/import/import-from-github
How to import a GitHub repo into Rork and build a mobile app from it: paste the repository URL, connect the Rork GitHub App, and continue your existing project with AI, with two-way GitHub sync.
Already have code on GitHub? Maybe a web app, a prototype, or a project from another AI builder? You don't have to start from scratch. Rork can import a GitHub repository, inspect the actual source files, and continue building from there as a native mobile app.
## Two ways to import
| You want to... | Use |
| - | - |
| Start a **new Rork project** from an existing repository | **GitHub to Mobile App** button on the homepage |
| Pull a repository **into an existing Rork project** (as a connected source) | Paste the repo URL in the project chat |
Both use **GitHub Sync**: Rork stays connected to the repository, so it reads your real source files instead of guessing from screenshots or descriptions.
## Start a new project from a GitHub repo
### 1. Click "GitHub to Mobile App"
On [rork.com](https://rork.com), under the prompt box, click **GitHub to Mobile App**.
### 2. Paste the repository URL
The dialog **"Create an app from GitHub with Rork"** opens. Paste your repository URL (`https://github.com/owner/repo`).
### 3. Generate the app
* **Generate app now** starts immediately, or
* **I have extra requests** attaches the repo to your prompt so you can add instructions ("import this and make the dashboard the home screen").
The repository is attached to the prompt as a **GitHub Sync** source, and Rork creates the project.
### 4. Grant access via the Rork GitHub App
GitHub Sync works through the **Rork GitHub App**, so the app needs access to the repository you're importing. The agent guides you through it right in the chat:
1. If the app isn't installed yet, click **Open GitHub** in the chat widget and install it.
2. If the app is installed but can't see this repository, click **Update GitHub permissions** and add the repo (you can limit access to just that one repo).
3. Back in Rork, click **I've updated permissions** / **Retry**, then **Continue** to confirm.
The status line shows **"Connected owner/repo"** when the link is live.
The repository must live in a GitHub account or organization where you can install the Rork GitHub App. To import someone else's public repository, fork it to your account first and import your fork.
### 5. The agent rebuilds your app from the source
Once connected, the agent scans environment variables, audits the source (screens, patterns, theme, integrations), scaffolds the native app, and reproduces your product, reusing your real assets straight from the repo:
A few minutes later the app is running in the cloud simulator, rebuilt natively from your repository:
## Import without changing anything
You don't have to describe changes to import. Paste the URL and click **Generate app now**. The **I have extra requests** button is optional: you can ask for changes later, in your next chat messages.
One thing to know before you start: **import is a rebuild, not a copy**. Rork connects your repository as a read-only source and writes a fresh native app from what it reads there. It does not move your files into an editor one by one. Your screens, flows, branding, data model, and assets carry over. The UI code becomes Swift, Kotlin, or React.
Import also costs credits, like any other prompt: one credit creates the project, and each following agent message costs credits too.
## Import a repo into an existing project
Inside any project, paste a GitHub URL in the chat and ask the agent to connect it, for example:
```
Connect https://github.com/acme/inventory-api and use it as the backend for this app
```
The agent links the repository to your project (it stays attached across sessions), so it can read the code, reuse your API contracts and data models, and keep everything consistent with the source.
## Keep the sync two-way
GitHub Sync is not a one-time copy. When new commits land in the connected source repository, the project notifies you and you can pull them in with one click:
And by connecting your Rork project to its own GitHub repository you get full **two-way sync**:
* Every change Rork makes is pushed to GitHub.
* Commits you push from your editor are imported back into Rork.
To set it up from a project: **⋯ menu → GitHub → Connect**.
See the full walkthrough: [How to sync your project with GitHub](/tutorials/how-to-connect-github).
## What kinds of repos work best?
* **Web apps** (React, Vue, Next.js, anything with readable source): Rork rebuilds the product as a native mobile app.
* **Output of other AI builders** (Lovable, Bolt, v0, Replit, and others): see [Import from any app builder](/import/import-from-any-app-builder).
* **React Native / Expo projects**: the agent reads the source and rebuilds it as a native Swift or Kotlin app, see [Convert between platforms](/import/convert-between-platforms).
* **Native Swift or Kotlin projects**: the agent reads your existing native source and rebuilds the app in Rork. It does not adopt your Xcode or Android Studio project as-is, so treat the import as a fresh native app that reproduces your product.
* **Backends / APIs**: connect them as a source so your mobile app matches the API exactly.
## FAQ
### How does GitHub to Mobile App work?
In four steps. You paste your repository URL in the **GitHub to Mobile App** dialog on [rork.com](https://rork.com). You give the Rork GitHub App access to that repository. The agent reads your real source files and audits the screens, theme, integrations, and environment variables. Then it builds a native app from what it found, and keeps the repository connected so you can pull in later commits.
### Does importing change my repository?
No. Importing reads your code. Rork only pushes to a repository if you explicitly connect two-way sync for the project, and that's a separate repository that Rork creates (or one you choose).
### Which plan do I need to import a repo?
Import is not locked to a specific tier. It costs credits, like a normal prompt. You do need a paid plan, because the import builds a working app, and the **Free** plan only designs apps.
The platform you build for is what differs. **Rork Pro** (\$20/month) covers iPhone (SwiftUI), Android (Kotlin + Compose), and web. **Rork Max** adds iPad, Apple Watch, Vision Pro, native games, iOS widgets, and priority chat support. So a native Swift repository imports fine on Rork Pro, and you only need Rork Max for the extra Apple devices and Max-only features. See [Plans & Subscriptions](/introduction/subscriptions).
### Can I import a monorepo?
Yes. Mention which folder or app inside the monorepo you care about in your prompt so the agent focuses on the right code.
### The repo isn't found or access fails
* Check the URL is `https://github.com/owner/repo` (no `.git` suffix needed, branches and subfolders can be mentioned in your prompt).
* For private repos, make sure the Rork GitHub App is installed **on the account/organization that owns the repo**, with access to that specific repository.
# Convert your Lovable app to a mobile app
Source: https://docs.rork.com/import/lovable-to-mobile-app
How to convert a Lovable app to a native iOS and Android mobile app: import your Lovable project into Rork, keep your Supabase backend, and ship to the App Store. No APK wrappers, no webviews.
Lovable is great at shipping web apps, but it produces a website, not a native mobile app. If you want your Lovable project on the App Store or Google Play, Rork can import it directly and rebuild it as a **real native mobile app** (not a webview wrapper), while staying connected to your Lovable project's source code.
## Watch the Lovable migration walkthrough
Follow the complete example: publish the Lovable app, link its GitHub repository in Rork, review the imported environment variables, and preview the native app.
## What you get
* A native iOS app (and Android / web versions from the same project) built from your existing Lovable app.
* **Lovable Sync**: Rork connects to the GitHub repository behind your Lovable app, inspects the actual source files, and keeps future syncs connected to the source.
* The full Rork workflow afterwards: preview in a cloud simulator, test on your phone, publish to TestFlight and the App Store, all without Xcode.
Rork rebuilds your app with native UI. This is different from wrapper tools (Capacitor, Median, and similar) that put your website inside a webview. Those often get rejected under Apple's Guideline 4.2 (Minimum Functionality) because they don't offer a native experience.
## Before you start
1. **Connect your Lovable project to GitHub** (done inside Lovable: Settings → GitHub → Connect). Lovable pushes your project code to a repository on your GitHub account. Rork needs that repository to see your real source files.
2. Have your Lovable app URL ready. It looks like `https://your-app.lovable.app`.
## Step-by-step
### 1. Open Rork and click "Lovable to Mobile App"
On [rork.com](https://rork.com), right under the prompt box, click the **Lovable to Mobile App** button.
### 2. Paste your Lovable app URL
A dialog opens: **"Turn your Lovable app into a mobile app with Rork."** Paste your `https://your-app.lovable.app` link.
If you're not sure where to find your link, click **"How do I get my Lovable link?"** inside the dialog for a short walkthrough.
### 3. Generate the app
* Click **Generate app now** to start immediately, or
* Click **I have extra requests** if you want to add instructions to the prompt first (for example: "keep the branding but redesign the navigation as native tabs").
Rork creates a new project and the agent starts working.
### 4. Link the GitHub repository (Lovable Sync)
In the new project's chat, the agent asks you to set up **Lovable Sync**:
1. Paste the URL of the GitHub repository that Lovable created for your project.
2. If you haven't installed the Rork GitHub App yet, click **Install GitHub app** and grant it access to that repository. You may also see **Update GitHub permissions** if access is missing.
3. Click **Link repo**.
Once connected, Rork clones your Lovable source into the project and uses it as the source of truth for screens, logic, and data models.
Eligible Lovable projects unlock **free migration credits**. If your repository qualifies, you'll see this right in the flow:
### 5. Environment variables come along automatically
Right after the repo is linked, Rork scans your source for environment variables. Public client keys that are committed in the Lovable source (Supabase anon key, Firebase web config, Stripe publishable key, analytics keys) are imported automatically; if anything is missing or conflicting, an in-chat panel asks you for the values:
### 6. Watch the mobile app come to life
The agent surveys your screens, flows, copy, colors, and assets, then rebuilds the product as a native mobile app: native tab bars and navigation stacks instead of a web navbar, mobile-first layouts, your real brand assets copied straight from the repo. Marketing/landing pages typically become onboarding and store-listing material rather than in-app screens: the agent keeps the *product*, not the website chrome.
You'll see the app running in the cloud simulator as it's built. From here it's a normal Rork project, so keep iterating by chatting.
## What about my Supabase backend?
If your Lovable app uses Supabase, the imported source includes your Supabase client code and schema references, and the committed anon key is picked up by the env scan, so your web app and mobile app share the same database and auth out of the box. See [Supabase setup](/backend/supabase).
## Publish it
When you're happy with the app:
* [Publish to the App Store](/store-guides/publish-app-store), built into Rork, no Xcode needed.
* [Publish to Google Play](/submitting-to-play-store/creating-the-aab-file) by exporting and building the AAB.
* Or add a web version too: see [Add iOS, Android, and web versions](/import/convert-between-platforms).
## FAQ
### Can Lovable itself make a native mobile app?
No. Lovable outputs React + Vite web applications. You can pin them to a home screen as a PWA, but that's still a website: no App Store distribution and limited offline support. Push notifications work only under conditions: on iOS and iPadOS 16.4 or later the user must add the site to the Home Screen first and then grant permission, so you cannot reach people who just visit in the browser.
### Can I convert my Lovable app to an APK?
Yes. After importing into Rork, add an **Android** version of the app (Project Settings → Add new app → Android). Rork builds a native Android app. You can download an APK to install on your own phone or to share a test build. To publish on Google Play you upload the AAB, because Google Play requires an Android App Bundle for new apps. That's a real native app, not a webview wrapped around your Lovable URL.
### Does this convert Lovable to React Native?
No, and that is the point. Rork rebuilds your app as native code: **Swift** for iPhone, **Kotlin** for Android. Pick the platform when you create the project. The agent rebuilds the UI natively instead of porting web code line by line, so you get a real native app rather than a cross-platform layer.
### Can I export my Lovable code without GitHub?
Lovable's own exports (and Lovable Sync in Rork) go through GitHub. If you only have a ZIP of your code, push it to a new GitHub repository and use the regular [GitHub import](/import/import-from-github) instead.
### Do I need to keep paying for Lovable after migrating?
That's up to you. Many builders keep Lovable for their web app and use Rork for mobile, but a Rork project can also hold a web app next to the mobile apps, so you can consolidate everything into Rork.
### My Lovable repo isn't recognized
Lovable Sync checks that the repository was actually generated by Lovable (recent commits from the Lovable bot). Make sure you linked the repo that Lovable manages, not a manual copy. If it still fails, use the generic [GitHub import](/import/import-from-github) instead. It works with any repository.
# Turn your website into a mobile app
Source: https://docs.rork.com/import/website-to-mobile-app
How to convert a website to an app for iOS and Android: import your site into Rork and get a real native mobile app, not a webview wrapper or APK converter output.
You have a website (a store, a booking page, a SaaS, a community) and you want it on your customers' home screens as a real app. Rork builds a **native** iOS / Android app for your existing site: native navigation and screens, powered by the same content and backend you already run.
## Pick your path
| Your situation | Best path |
| - | - |
| The site's code is on GitHub (or you can export it) | [Import the repository](#path-a-import-the-website-code) |
| Built with Lovable | [Lovable import](/import/lovable-to-mobile-app) |
| Built with another builder (Bolt, v0, Replit, FlutterFlow\...) | [Import from any app builder](/import/import-from-any-app-builder) |
| No access to the code (Wix, Squarespace, WordPress, custom agency site) | [Describe + screenshots](#path-b-no-code-access) |
| You already have a Rork web app | [Add iOS / Android to the project](#add-ios-and-android-apps-to-an-existing-rork-project) |
## Path A. Import the website code
If your website's source is available, import gives the agent the most to work with:
1. On [rork.com](https://rork.com), click **GitHub to Mobile App** and paste the repository URL.
2. In your prompt (via **I have extra requests**), say what the mobile app should focus on, e.g. "make a customer app for browsing and booking; skip the admin pages".
3. The agent inspects the source, keeps your branding and data flows, and builds native mobile screens.
## Path B. No code access
No repository? No problem, give the agent the product instead:
1. Start a new Rork project and paste your **website URL** in the prompt.
2. Attach **screenshots** of the key pages (home, product/detail page, checkout/booking, profile).
3. Describe what the app should do in one or two sentences, for example:
```
Make an iOS app for my salon website https://example.com.
Customers should browse services, pick a stylist, book a time slot,
and get a reminder push notification before the appointment.
```
The agent designs a native app around your site's content and connects to your existing systems where possible (APIs, booking systems, payment links).
## Add iOS and Android apps to an existing Rork project
Every Rork project can hold **multiple apps that share one project and backend**: iOS, Android, and web. Each platform keeps its own native codebase, and Rork updates them from the same project. If you already have (or just imported) a web app in Rork, adding native mobile is two clicks:
### Option 1. The "+" button next to the platform switcher
In the project header, click **+** (Add preview platform) and choose the platform to add:
### Option 2. Project Settings → Add new app
Open **Project Settings** (gear next to the project title) → **Add new app** → pick **Android** or **Web** (or iOS if the project started elsewhere):
### Option 3. Just ask in chat
```
Add an Android version of this app
```
The agent shows an **"Add Android app?"** confirmation, then builds the native Android (Kotlin) app reusing your project's logic and backend.
Each app gets its own icon, home-screen name, and bundle identifier in Project Settings:
## Why native instead of a webview wrapper?
Website-to-app converter services wrap your URL in a webview. That's fast, but:
* **App Store risk**: Apple's Guideline 4.2 (Minimum Functionality) regularly rejects apps that are "just a website".
* **No real native features**: camera metadata, offline mode, background tasks, widgets, and push notifications that reach every user need native code. On the web, iOS delivers push only after the user adds the site to the Home Screen on iOS 16.4 or later and grants permission.
* **It never feels right**: browser scrolling, no native gestures, no home-screen-quality polish.
A Rork app is compiled native code with native UI. Your website keeps doing what it does best, and the app becomes a first-class channel: same data, better experience.
## FAQ
### Does this work with WordPress, Shopify, Wix, or Squarespace sites?
Yes, use [Path B](#path-b-no-code-access). These platforms don't expose app-ready source code, so give the agent your URL and screenshots. For stores, tell the agent which checkout to keep (many businesses link out to the existing web checkout in v1).
### Can I convert my website to an app for free?
You can start for free: the **Free** plan runs Design mode, so you can import the site and explore how the app would look. To build the working app, preview it in the simulator, and run it on your phone, you need a paid plan. Publishing to the App Store / Google Play also needs the stores' own developer accounts (Apple $99/year, Google $25 one-time).
### Website-to-app converters give me an APK in minutes. Why is this different?
Those converters wrap your URL in a webview, so the "app" is your website in a browser shell. Rork builds real native screens. It takes longer than 60 seconds, and the result feels like an actual app. Native screens also help you meet Apple's Guideline 4.2 (Minimum Functionality), which is where webview wrappers usually fail. App Review still judges each submission on its own, so native UI alone does not guarantee approval.
## Ship it
* [Publish to the App Store](/store-guides/publish-app-store) from inside Rork, no Xcode.
* [Create the Android AAB for Google Play](/submitting-to-play-store/creating-the-aab-file).
* Keep the web version alive at your own domain: see the web publish flow in your project's **Publish** menu.
# Welcome
Source: https://docs.rork.com/index
Use this section to understand how Rork works, how projects are structured, and how to begin building with confidence.
# Getting Started
**What is Rork?**
Rork is a platform for building and publishing apps without writing code: native iPhone apps, native Android apps, and web apps.
Instead of hiring engineers or learning to code, you describe your app in plain language. Rork writes the app, handles the design, runs the builds, and publishes it: to the App Store, to Google Play, or to your own web address. There's no Xcode, no Android tooling, no build pipelines to configure. Everything runs in the browser.
What used to require months of work, a full team, and significant capital can now be done by a single person, quickly. You focus on the idea and the product decisions. Rork handles the implementation and publishing.
If you have an app idea and want it live, Rork removes the cost, time, and complexity that normally stand in the way.
Go from an idea to a working app, step by step.
iPhone, Android, or web: what each one is good at.
Ship to the App Store, Google Play, or the web.
What a credit is, and what each plan includes.
# Add accounts and sign-in to your app
Source: https://docs.rork.com/integrations/backend/how-to-set-up-oauth
Rork Auth adds Google and Apple sign-in with no setup and no backend. Supabase Auth covers email and password, magic links, and phone codes. This page explains which one to pick, and why a project uses only one.
An app that keeps data per person needs accounts. Someone signs in, and from then on the app knows whose notes, orders, or photos to show. Rork has two ways to do that, and you pick one before the agent writes any of it.
| What you want | Use | What you set up |
| - | - | - |
| **Sign in with Google** or **Sign in with Apple** | **Rork Auth** | Nothing. Rork runs the sign-in for you. |
| Email and password, magic links, phone codes | **Supabase Auth** | A Supabase backend on the project. |
A **magic link** is the email that signs a person in when they tap it, with no password to remember.
**One project uses one of them, never both.** Each hands out its own kind of user ID. Your data rules read only one kind. Put both in one app and you get two sets of users in the same tables, so people start seeing empty screens. You can change your mind later, but anyone who already signed in has to sign up again.
## Add Google and Apple sign-in
```
Add sign in with Google and Apple
```
It creates the keys, adds the sign-in screen, and writes the part that keeps a person signed in between visits. It asks you for nothing, because there is nothing only you can provide.
Sign in with your own Google or Apple account, right in the preview next to the chat. Sign-in works in the preview, in the simulator, and on a real phone.
In the iOS simulator the Google or Apple window opens in your own browser, not inside the phone screen. The app then carries on as normal. On a real device everything stays inside the app.
```
After sign in, show a profile screen with the person's name and a sign out button
```
Four things people expect to do here, and do not:
* **You do not create a Google sign-in client** in the Google Cloud console.
* **You do not configure Sign in with Apple** in the Apple Developer portal.
* **You do not run a backend.** Your app talks to Rork's sign-in service directly.
* **You do not store passwords.** Google and Apple check the person, so your app never sees one.
After sign-in, the app holds a pass that proves who the person is. It lasts one hour, and the app quietly gets a new one, so nobody is thrown out mid-task. The pass is kept in the safest place each platform has:
| App type | Where the session is kept |
| - | - |
| iPhone app (Swift) | The **Keychain**, the same store iOS uses for passwords |
| Expo app (React Native) | **SecureStore**, the encrypted store on the device |
| Web app | `localStorage` in the browser, which is the only store a browser offers |
The session survives deleting and reinstalling the app. So while you test, use the **sign out** button in your own app. Deleting the app does not sign you out.
### Three Apple rules that are easy to break
Apple reviews the look and behaviour of **Sign in with Apple**, and rejects apps that get it wrong. Two of the three are things you might ask the agent for without knowing:
* **Do not ask for the name and the email again** after somebody signs in with Apple. Apple already handed them to your app. A "complete your profile" screen that asks for them is a rejection.
* **Accept hidden emails.** Apple lets people hide their real address and gives your app a relay address that ends in `@privaterelay.appleid.com`. If your app refuses that as invalid, it is a rejection.
* **Keep the Apple button as prominent as the Google one.** Hide it below the fold, or style it as a small link, and Apple rejects that too.
The [AI App Store Reviewer](/ai-app-store-reviewer) checks your build for these before Apple does. Run it before you submit.
### What Rork Auth cannot do
* Google and Apple only. No email and password, no magic links, no phone codes, no other providers.
* No extra questions inside the sign-in itself. Collect anything else on a screen of your own, after sign-in. Mind the Apple rule above about the name and the email.
* No way to move accounts across from another sign-in system.
### The variables it adds
You never type these in. They are listed here so the project's **Secrets** panel makes sense when you open it:
| Variable | What it is | In Secrets |
| - | - | - |
| `EXPO_PUBLIC_RORK_APP_KEY` | Your app's public key. Safe inside the app. | Listed |
| `EXPO_PUBLIC_RORK_AUTH_URL` | The address of Rork's sign-in service. | Listed |
| `EXPO_PUBLIC_PROJECT_ID` | The project ID, used to bring people back into the app after sign-in. | Listed |
| `RORK_AUTH_URL` | The same address, for server-side code. | Listed, not editable |
| `RORK_AUTH_SECRET_KEY` | The private key that proves a request is your app's. | Hidden, Rork keeps it |
Rork creates all five itself. The private key never appears in the panel, and **the agent never asks you for any of them**. Treat any request for these values as a mistake. See [API keys and environment variables](/features/secrets).
## Email and password with Supabase Auth
Pick this one when Google and Apple are not enough, for example when your users are staff who have no Google account. It needs a Supabase backend on the project, see [How to add a Supabase backend to Rork](/backend/supabase).
```
Add email and password sign-in with Supabase
```
The agent connects the backend, adds the sign-up and sign-in screens, and handles the session.
Supabase sends the confirmation email itself, from a generic address, and it limits how many go out. That is fine while you test. Before real users arrive, set your own mail sender in the Supabase dashboard. Or ask the agent to switch confirmation off while you build.
Other providers, like Facebook or GitHub, also go through Supabase Auth rather than Rork Auth.
## Why each person sees only their own data
A database on its own hands out any row to anybody who asks. What stops that is a set of rules on each table, which say "you may read this row only if it is yours". Those rules need a way to say **who is asking**, and the name differs by model:
| Model | How the rules name the person | Where accounts live |
| - | - | - |
| **Rork Auth** | `user_id()`, which returns an ID like `usr_xxx` | Rork's sign-in service |
| **Supabase Auth** | `auth.uid()`, which returns a Supabase user ID | The `auth.users` table in your Supabase project |
The agent knows which one your project uses, and Rork rejects a database change that uses the wrong one. You never write this by hand.
It is still worth knowing, because it explains the strangest bug in this area. A person signs in, everything looks fine, and every screen is empty. That is a rule asking for the wrong kind of user, so no row matches. Tell the agent what you see. Ask it to check the rules against the project's sign-in model.
## Change your mind later
Ask the agent, and name the model you want:
```
Switch this app to email and password sign-in instead of Google and Apple
```
It turns the old one off, rewrites the data rules, and replaces the sign-in screens. Accounts do not move across, so do this before you have users, or tell them they need to sign up again.
## FAQ
Not with **Rork Auth**. Google and Apple sign-in works with no backend and no database. You need a backend once you want to store what those people do in your app, see [Do You Need a Backend for Your App?](/backend/index).
Not to build it or to test it. You need the **\$99 / year** Apple Developer membership to publish the app at all, see [Create your Apple Developer Account](/store-guides/apple-developer-account).
With **Rork Auth**, the sign-in runs on Rork's service and your app receives the person's ID and profile. Anything else you want to keep about them goes in your own database, under your own rules.
No. A project uses one model. If you need both kinds of sign-in, pick Supabase Auth and ask the agent to add Google there.
Yes. Sign in with your own account in the preview next to the chat, in the simulator, or on a real phone.
Yes. In a web app the sign-in happens in the browser and the session lives in `localStorage`. One project can hold an iPhone app, an Android app, and a web app, see [Convert your app between iOS, Android, and web](/import/convert-between-platforms).
Yes. Add sign-in the same way, then keep each person's rows behind the rules above. See [What is Rork Cloud](/backend/rork-cloud).
Almost always the data rules name the wrong kind of user, so every row is filtered out. Ask the agent to check the rules against the project's sign-in model.
## Next steps
What accounts imply for your data, before you build.
A managed database and server functions inside Rork.
Bring your own Supabase project, and its sign-in methods.
Catch the Sign in with Apple mistakes before Apple does.
# How to build your first app
Source: https://docs.rork.com/introduction/build-your-first-app
Get started by building your first app.
Building apps on Rork is incredibly easy. What used to take months for a production team to put together can now be done in minutes. Rork uses a simple prompt generation system so you can express exactly what you want.
***This guide will help you get started building your first app in the Rork editor.***
### Step 1: Create an Account
To use Rork, you need to create an account. Creating an account is free. You can sign in with Google or Apple. Once you sign in, you will be asked to answer a short survey before being sent back to the home page.
### Step 2: Think of an Idea
Every great prompt starts with an idea. To get started, feel free to branch off an existing app idea, like "*Uber for Cat Food*" or "*First Person Shooter Zombies Mobile Game*". We have an explore screen so you can get inspired by thousands of other app developers. In our onboarding, we encourage you to get started by remixing others' apps as a baseline.
### Step 3: Choose Your App Type
Rork builds three kinds of apps: two native mobile apps and a web app. Pick the platform in the picker next to the prompt box before you send your first message.
| App type | What Rork builds | Runs on | Where it ships |
| - | - | - | - |
| **For iPhone** | Native iPhone app with SwiftUI | iPhone, iPad, Apple Watch | App Store and TestFlight |
| **For Android** | Native Android with Kotlin + Compose | Android phones and tablets | Google Play |
| **For web** | Vite + React | Any browser, desktop and mobile | Your own `your-app.rork.app` address |
Choose **For iPhone** when the app should feel deeply native on Apple devices, or when it needs Apple-only features: home screen widgets, Live Activities, Apple Watch, HealthKit, ARKit, or high-performance games. Read [Build a native iPhone app with Rork](/iphone/rork-iphone) for the full guide, or [iPhone, Android, or web: what's the difference](/swift-vs-react-native/whats-the-difference) for the comparison.
Choose **For Android** when you want a real native Android app instead of a cross-platform wrapper.
Choose **For web** for a browser-first product: a landing page, a dashboard, an internal tool, or a SaaS-style app.
One choice does not lock you in. A single Rork project can hold an iPhone app, an Android app, and a web app side by side. Each app has its own code. They share the chat, and the backend if you have one. You can add the next platform at any time from the platform switcher above the preview, or from **Project Settings → Add new app**. See [Convert your app between iOS, Android, and web](/import/convert-between-platforms).
### Step 4: Prompt It
On the home page, you can start a new project by just typing in the prompt box. Try to focus on one main function for your prompt to begin. The more complex you make the initial prompt, the harder it's going to be for you to iterate after that point. It's better to start one at a time. Explain the pages and functions that you want, or make it brief and let our intelligent agents handle the job.
### Step 5: Test it Live & Iterate
You will be sent to the Rork editor when you submit your prompt. Your agent will begin working on your app. In a few minutes, you'll have a fully functional app that you can test. How you test it depends on the app type:
* **For iPhone**: run the app in the iOS simulator directly on the website, or test on your phone with the [Rork Max app for iPhone](/rork-max/rork-max-app). To install Rork Max on your iPhone, open [rork.com/ios/install](https://rork.com/ios/install) on your Mac or Windows PC and follow the steps. The [Rork Companion desktop app](/rork-max-swift) can also install a Swift project directly from the Rork editor.
* **For Android**: run the app in the Android emulator directly on the website.
* **For web**: the live preview opens right in the editor, and you can open it in a browser tab at any time.
The iOS simulator and the Android emulator run on rented cloud machines, so they spend credits per minute. See [build credits vs cloud credits](/billing/build-credits-vs-cloud-credits).
You can also [take screenshots and record your app in the simulator](/features/simulator#screen-capture). Captures attach directly to your chat draft, so you can show Rork what needs changing or download a quick demo to share.
After playing around with your app, you can send more messages on Rork to continue iterating on our app. You can clone your project at any point to start from a new thread, or you can start a new project entirely by prompting on the home page.
**Good luck with your first app on Rork!**
# Publish your app
Source: https://docs.rork.com/introduction/deploy-your-app
Where your finished app can go: the App Store, Google Play, or the web. Each store has its own account, its own review, and its own waiting time. Start here and pick your route.
Rork builds and uploads for you, on its own machines. You do not need a Mac, Xcode, or Android Studio.
What Rork cannot do is be you. Each store wants an account in your name, your identity verified, and your listing written. Start those early, because the waiting is the slow part, not the building.
## Pick your route
Fastest. No account, no review, no install. Publish and share a link today.
An Apple Developer membership at \$99 a year, and Apple's review.
A \$25 one-time registration, and a closed test for new personal accounts.
The three are not exclusive. One project can hold an iPhone app, an Android app, and a web app, and many founders publish the web app first to test the idea while the store accounts are being verified. See [Convert your app between iOS, Android, and web](/import/convert-between-platforms).
## iPhone, in order
\$99 a year, and Apple verifies who you are. [Create your Apple Developer Account](/store-guides/apple-developer-account).
Put the app on real phones, yours and your testers'. [TestFlight and testers](/store-guides/testflight-beta-testers).
Run the [AI App Store Reviewer](/ai-app-store-reviewer) and read the [App Store Checklist](/submitting-to-app-store/apple/app-store-checklist).
Screenshots, description, privacy answers. [App Store screenshots](/appstore-screenshots/app-store-screenshots) and [Screenshot Studio](/store-guides/screenshot-studio).
[Publish Your App to the Apple App Store](/store-guides/publish-app-store), then the [App Review guide](/appstore-submission-checklist/app-review-guide) for what the statuses mean.
If a build fails or never appears, see [Submission errors](/submitting-to-app-store/apple/submission-errors). For the most common rejections, see [Main App Store rejection reasons](/appstore-submission-checklist/whats-next-after-the-apps-finished).
## Android, in order
\$25 once, plus identity verification. New personal accounts also need a closed test with 12 testers for 14 days, so start this first. [Create your Google Play developer account](/store-guides/google-play-developer-account).
[How to test Android apps on your Android device](/submitting-to-play-store/apk-file).
[How to publish your Rork app to Google Play Store](/submitting-to-play-store/creating-the-aab-file).
## Before you submit anywhere
* **Test the thing you are shipping**, on a real device, not only in the preview.
* **Have your policies ready.** Both stores ask for a privacy policy, and a subscription needs terms. See [How to create a privacy policy](/make-your-app-profitable/paywalls/how-to-set-up-your-policies).
* **Decide how it makes money** before the listing, because pricing and paywalls affect review. See [How to add a paywall with RevenueCat](/payment-guides/revenuecat-copied-1).
# How to get out of an error loop
Source: https://docs.rork.com/introduction/introduction/agent-loops
Sometimes, Rork will be unable to fix the error and/or start to hallucinate. In this doc, we will go over how to solve that
**Go back before you push forward.** The fastest way out of a loop is to leave it. **Undo** sits under the last answer and **Revert** sits under every earlier one, so you can return to the last version that worked and ask again in smaller steps. Going back costs no credits. See [Undo a change and go back a version](/features/undo-and-history).
## When the Model Hallucinates
Occasionally, the model may generate output that is incorrect, incomplete, or not grounded in your actual project state. This is referred to as **hallucination**.
Hallucinations usually appear as:
* Referencing files, APIs, or features that don’t exist
* Claiming something was “fixed” when nothing changed
* Repeating solutions that don’t resolve the issue
* Providing confident but incorrect instructions
This is expected behavior in AI systems and does not indicate a broken project.
## How to Resolve Hallucinations
### 1. Ground the Model With Facts
Provide **real, concrete inputs**:
* Error logs
* File contents
* Build output
* Exact error messages
Avoid vague prompts like:
> “It’s broken, fix it.”
Instead use:
> “Here is the full build error output. Fix only what’s causing this error.”
### 2. Constrain the Scope
Tell the model **exactly what it can and cannot change**.
Examples:
* “Only modify `Info.plist`.”
* “Do not add new libraries.”
* “Do not assume files that don’t exist.”
Clear constraints reduce hallucination significantly.
### 3. Force Verification
If the model claims something is fixed, require confirmation.
Use prompts like:
* “Show me exactly what changed.”
* “Which file was modified and why?”
* “Quote the line that fixes the error.”
If it cannot point to a real change, assume the fix is invalid.
### 4. Reset the Context
If hallucinations persist:
* **Revert** to the last answer that worked, so the broken attempts leave the conversation
* Start a **new message**
* Paste only the **relevant files or logs**
* Restate the goal clearly
Long conversations increase the chance of drift, and every failed attempt stays in the context until you revert it.
### 5. Switch Models
Different models reason differently. If one is looping or hallucinating, open the model picker under the prompt box and pick another, then:
* Re-paste the same grounded inputs
* Retry with tighter constraints
See [Design mode, Plan mode, and building](/features/agent-modes).
## When to Stop Iterating
Stop prompting the model if:
* It repeats the same fix multiple times
* It references non-existent files
* It contradicts itself across responses
At that point, move to:
* Manual inspection
* Logs-first debugging
* Native tools (Xcode for iPhone apps, Android Studio for Android apps)
## Best Practices to Avoid Hallucinations
* Always paste **real logs**
* Keep prompts short and specific
* Verify every claimed fix
* Treat AI output as a **suggestion**, not ground truth
## Key Principle
> The model is strongest when reacting to **real inputs**, not guessing missing context.
Hallucinations are a signal that the model needs **more constraints or better grounding**, not that your app is broken.
# How to prompt succesfully
Source: https://docs.rork.com/introduction/introduction/prompting-strategy
How to prompt Rork to build more polished, high-quality apps.
## Prompting for Higher-Quality Apps
Rork doesn’t just follow instructions – it interprets intent.\
How you describe the *feel*, *goal*, and *user experience* of your app has a direct impact on build quality.
If you want your app to feel polished, alive, and production-ready, you need to prompt for more than features.
## 1. Define the Experience, Not Just the Features
Instead of only listing what the app should do, explain **how it should feel to use**.
Compare:
**Low-quality prompt**
> “Create a fitness app with a dashboard and workouts.”
**High-quality prompt**
> “Create a fitness app that feels fast, motivating, and modern. The goal is to create the best possible user experience.”
When you describe the experience, Rork makes better decisions around layout, spacing, flow, and interaction.
## 2. Tell Rork When Polish Matters
If you don’t ask for polish, Rork will prioritize functionality. If you want a higher-production feel, say so explicitly.
Examples:
* “This should feel high-production and polished.”
* “Make the app feel alive and responsive.”
* “Prioritize smooth interactions over adding more features.”
These signals encourage:
* Better screen transitions
* More thoughtful spacing and hierarchy
* Cleaner, more intentional UI decisions
## 3. Ask for Transitions and Motion
Animation and transition animations can be a major part of perceived quality. Making an app feel alive versus static could be the decider of a good user experience versus a bad experience.
Good prompts:
> “Add subtle transition animations between screens.”\
> “Buttons should feel responsive when tapped.”\
> “Use smooth page transitions to make the app feel alive.”
Even a simple motion dramatically improves how finished an app feels.
## 4. Describe the Mood and Target User
UI improves significantly when Rork knows **who the app is for** and **what mood it should convey**.
Examples:
* “Target user: busy professionals who want clarity and speed.”
* “Mood: calm, minimal, and focused.”
* “Design for Gen-Z: bold, modern, and energetic.”
This helps Rork make better decisions about:
* Color usage
* Typography
* Spacing and density
* Overall visual tone
## 5. State the Primary Goal Clearly
Always tell Rork what matters most.
Examples:
* “The main goal is the best possible user experience.”
* “Optimize for simplicity and clarity.”
* “Reduce friction as much as possible.”
When goals conflict, Rork will prioritize the one you state.
## 6. Combine Intent With Constraints
High-quality prompts balance **vision + boundaries**.
Example:
> “Create a calm, high-production app focused on user experience. Keep it simple. One main flow. No extra features.”
This leads to cleaner, more intentional builds.
## Summary
To increase build quality:
* Describe how the app should **feel**, not just what it does
* Explicitly ask for **polish and motion**
* Define the **mood and target user**
* State the primary UX goal
* Keep scope controlled
When you prompt with intent, Rork produces apps that feel finished – not just functional.
# Plans & Subscriptions
Source: https://docs.rork.com/introduction/subscriptions
Rork pricing explained: the Free, Rork Pro, and Rork Max plans, Design mode vs Build mode, what credits are, what each plan includes (iPhone, Android, web), and how to upgrade, downgrade, or cancel your subscription.
**Rork** has simple, transparent pricing. There is a **Free** plan and two paid tiers (**Rork Pro** and **Rork Max**). Rork Max has several credit options for heavier users. You only pay for the compute you use, and you can upgrade, downgrade, or cancel at any time.
**Paid plans (Rork Pro and Rork Max) reset on the monthly anniversary of your first purchase.** The **Free** plan resets at the start of each calendar month.
## Design mode and Build mode
Rork splits the work into two modes, and this is the main difference between Free and the paid plans.
* **Design mode** explores app designs. You describe your idea and Rork proposes the screens and the look. The **Free** plan runs in Design mode.
* **Build mode** turns those designs into a working app: real Swift, Kotlin, or React code that you can preview, test on a device, and publish. A paid plan unlocks Build mode.
## What is a credit?
A **credit** is a unit of AI compute, roughly one request where Rork designs, builds, or edits your app. Every plan includes a set number of credits per month. When you run out, you can upgrade your plan or wait for your monthly reset.
* **Free** plan: **5 design credits per day**. The monthly allowance depends on your region: **35 credits/month in major markets** (US, UK, Canada, the EU, Japan, Korea, Australia, and other major countries) and **5 credits/month elsewhere**.
* **Paid** plans (Pro and Max): **no daily cap**, so you can spend your full monthly allowance whenever you want.
Some actions cost more than one credit. iOS builds and cloud simulator sessions rent real machines, so they are charged on top of the message that started them. See [Build credits vs cloud credits](/billing/build-credits-vs-cloud-credits).
## Plans at a glance
| Feature | Free | Rork Pro | Rork Max |
| - | - | - | - |
| **Price** | \$0 | **\$20/mo** | from **\$200/mo** |
| **Credits / month** | 35 in major markets, else 5 (5/day) | 100 | 1,000 · 2,500 · 5,000 · 10,000 |
| **Design mode** | ✓ | ✓ | ✓ |
| **Build mode** | ✗ | ✓ | ✓ |
| **iPhone apps (SwiftUI)** | design only | ✓ | ✓ |
| **Android apps (Kotlin + Compose)** | design only | ✓ | ✓ |
| **Web apps** | design only | ✓ | ✓ |
| **iPad, Apple Watch, Vision Pro** | design only | ✗ | ✓ |
| **Native games & iOS widgets** | ✗ | ✗ | ✓ |
| **Private projects** | ✓ | ✓ | ✓ |
| **Dev mode** | ✗ | ✓ | ✓ |
| **Support** | None | Email | Priority chat |
**Native iPhone apps with SwiftUI are included in Rork Pro.** You do not need Rork Max to build for iPhone. Rork Max adds the rest of the Apple devices (iPad, Apple Watch, Vision Pro), native games, iOS widgets, and priority chat support.
Every project is private, on every plan.
## Models by plan
The available models update as Rork adds and changes models. The catalog below is refreshed daily from Rork's public model catalog.
**Major countries** are the US, UK, Canada, the EU, Japan, Korea, Australia, and other major markets. Models marked **first message** are available for a new project's first prompt only.
## Free (\$0/mo)
Design your app for free, no card required.
* **Design mode**: explore app designs for iPhone, Android, web, iPad, Apple Watch, and Vision Pro
* **Private projects**
* **5 design credits/day**, with up to **35 credits/month in major markets** (5 credits/month in other regions)
To turn a design into a working app you build and can publish, move to a paid plan.
## Rork Start (₹649/mo, India only)
An entry plan sold in India, in rupees.
**Platforms:** iPhone (SwiftUI), Android (Kotlin + Compose), Web
**Included:**
* Build mode
* iPhone apps with SwiftUI
* Android apps with Kotlin + Compose
* Web apps
* Light models only, picked automatically
* Private projects
* Dev mode (edit the underlying code)
* **40 credits/month**
## Rork Pro (\$20/mo)
Build **native iPhone apps with SwiftUI**, **native Android apps with Kotlin + Compose**, and **web** apps. A good fit for a first real product, and for prototypes.
**Platforms:** iPhone (SwiftUI), Android (Kotlin + Compose), Web
**Included:**
* Build mode: turn designs into working apps
* iPhone apps with SwiftUI
* Android apps with Kotlin + Compose
* Web apps
* Private projects
* Dev mode (edit the underlying code)
* **100 credits/month**
* Support: **Email**
## Rork Max (from \$200/mo)
For the full Apple device family and for power users. Everything in Rork Pro, plus the rest of Apple's platforms.
**Platforms:** iPhone (SwiftUI), Android, Web, iPad, Apple Watch, Vision Pro
**Included:**
* Everything in Rork Pro
* iPad, Apple Watch, and Vision Pro
* Games with native performance
* iOS widgets
* Priority chat support
**Credit options (Scale):**
| Price | Credits / month |
| - | - |
| \$200/mo | 1,000 credits |
| \$500/mo | 2,500 credits |
| \$900/mo | 5,000 credits |
| \$1,800/mo | 10,000 credits |
## What the icons mean
Each plan shows a **Platforms** strip (the devices you can build for) plus feature icons in the list below it.
### Platform icons
Android (Kotlin + Compose): native Android apps
iPhone (SwiftUI): native iOS apps
Web: web apps
iPad: iPad apps with adaptive layouts
Apple Watch: Apple Watch apps
Vision Pro: visionOS spatial experiences
### Feature icons
A capability included in the plan
Private projects: your code stays private
Dev mode: edit the underlying code
Email support
Chat / priority chat support
Games: native performance
iOS widgets
## Custom & Scale plans
Need more than 10,000 credits/month, or enterprise terms? If you need a **Custom Plan**, please [contact us](mailto:support@rork.com).
## FAQ
### What is a credit?
A credit is a unit of AI compute, roughly one request where Rork designs, builds, or edits your app. Each plan includes a set number of credits per month (see the reset schedule below).
### What's the difference between Rork Pro and Rork Max?
**Rork Pro** builds **native iPhone apps (SwiftUI)**, **native Android apps (Kotlin + Compose)**, and **web** apps. **Rork Max** adds **iPad, Apple Watch, and Vision Pro**, plus native games, iOS widgets, and priority chat support. Pick Pro for iPhone, Android, and web. Pick Max when you need the wider Apple device family or the Max-only features.
### Do I need Rork Max to build an iPhone app?
No. **Rork Pro builds native iPhone apps with SwiftUI.** Rork Max is for the other Apple devices (iPad, Apple Watch, Vision Pro), native games, and iOS widgets.
### Are my projects public on the Free plan?
No. Every project is private, on every plan, including Free.
### When do my credits reset?
**Paid plans (Rork Pro and Rork Max)** reset every month on the **anniversary of your first purchase**. The **Free** plan resets at the **start of each calendar month**.
### How do I upgrade my subscription?
On desktop, click your profile in the top right. If you're on the Free plan, click **Upgrade Plan**; if you already have a plan, click **Manage Subscription**. The full set of plans is available on desktop. In the mobile app, your subscription is managed through the App Store.
### How do I downgrade my subscription?
On desktop, click your profile in the top right, then press **Manage Subscription** and choose a lower plan. On mobile, manage your subscription through the App Store.
### How do I cancel my subscription?
On desktop, open **Account Settings → Manage Subscription** from your profile menu. You'll be taken to the Stripe billing portal to manage or cancel. On mobile, cancel through the App Store.
### Can I get free credits?
Yes, in several ways:
* **Connect RevenueCat:** [connect your RevenueCat account](https://rork.com/revenuecat-gift) to earn up to 1,000 free credits based on your app revenue.
* **Builder community:** active members of our [Discord community](https://discord.gg/rxBHytVKaT) earn credits.
* **Write with us:** share useful guides drawn from your **own hands-on experience** with Rork. We want genuine, first-hand write-ups, not AI-generated content.
* **Run a community event:** host something for the builder community. Pitch your idea to **Dora (@acooldora)** in [Discord](https://discord.gg/rxBHytVKaT).
* **Share your story:** if you've built something great with Rork, we'll interview you and feature it on [Rork Founders](https://rork.com/founders) and the [Rork Blog](https://rork.com/blog).
# Build a native iPhone app with Rork
Source: https://docs.rork.com/iphone/rork-iphone
Rork writes native iPhone apps in Swift with SwiftUI, runs them on a cloud iOS simulator next to the chat, and submits the build to TestFlight and the App Store.
An iPhone app in Rork is a **native iPhone app**. Rork writes it in **Swift** with **SwiftUI**, the stack Apple uses for its own apps. It is not a website in a shell, and it is not an Android app converted at runtime.
You describe the app, Rork builds it, and you watch it run on a cloud iOS simulator next to the chat. When it is ready, Rork builds the app on its own machines and submits it to TestFlight and the App Store. You do not need Xcode or a Mac to publish.
A Swift app running in the iOS simulator inside Rork.
## Start an iPhone 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=iphone-start), open the platform picker under the prompt box and choose **For iPhone**. The picker describes it as **iPad, Apple Watch, and more with SwiftUI**.
The For iPhone row in the platform picker.
The picker footer says it plainly: **You can add another platform later.** One project can hold an iPhone app, an Android 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 habit tracker that reminds me each morning and shows my streak on the first screen
```
**Rork Pro** (\$20/month) builds native iPhone apps with SwiftUI. You do not need **Rork Max** for iPhone. Max adds iPad, Apple Watch, Vision Pro, native games, and iOS widgets. See [Plans & Subscriptions](/introduction/subscriptions).
## Answer the questions, then build
Rork does not start writing Swift straight away. It asks a few short questions about the look first. Each answer is a picture, not a word. You can also type your own answer in **Other**, then press **Submit**. Skip this step by writing the look into your first prompt instead.
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 iPhone app. See [Design mode, Plan mode, and building](/features/agent-modes).
## Run the app on an iOS simulator
Rork runs your Swift app on a **cloud iOS simulator** in your browser. It is the real app on a real iOS system, not a picture, so you tap through it while you build.
The simulator does not run all the time. It waits behind a **Turn on simulator** button, and it tells you what it costs while it runs:
The simulator waits until you start it, and it shows the price first.
The panel says **0.2 build credits/min while running**, so press **Stop simulator** when you finish a testing round. It also tells you how much simulator time this project has used so far. See [Build credits vs Cloud credits](/billing/build-credits-vs-cloud-credits).
The controls above the simulator do this:
| Control | What it does |
| - | - |
| **Record** | Records the preview and attaches it to the chat. |
| **Screenshot** | Attaches a screenshot to the chat. |
| **Home** | Returns the app to its first screen. |
| Simulator settings | Switches **Appearance** between **Light** and **Dark**, changes **Text size**, and sets **Language**. |
| **Select an element** | Point at a part of the screen, then write what to change about it. |
| **Share** | Takes a screenshot you can post. |
| **Restart** | Restarts the simulator when the instance is gone. |
| **Stop simulator** | Shuts it down and stops the per-minute cost. |
| **Run on your device** | Installs the app on a real iPhone. See [Test on your own iPhone](#test-on-your-own-iphone). |
A simulator 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 simulator has no physical camera, and it cannot receive Apple push notifications. Camera code still builds. Test the camera and real push on a phone.
## Test on your own iPhone
The simulator covers most testing. When you want the app in your own hand, use one of these paths:
1. Press **Run on your device** above the simulator. To install through the desktop app, use [Rork Companion for Windows or Mac](/rork-max-swift). If the popover first offers Rork Max for iPhone, expand **Other ways to run** for Companion.
2. Open the [Rork Max app](/rork-max/rork-max-app) on your iPhone, then use **Install on Device**. The app lands on your Home Screen as a real iOS app.
3. Submit a build and invite testers with [TestFlight](/store-guides/testflight-beta-testers).
The Rork Max app is the everyday path when you are away from your computer. For its initial installation, use Chrome or Edge on a Mac, or Companion on Windows or Mac. Start at [rork.com/ios/install](https://rork.com/ios/install).
## Publish to the App Store
Rork builds and submits the app for you. What Rork cannot do is be you: the Apple Developer account and the store listing belong to your Apple account.
Open **Publish** in the project. The App Store section says **Build and submit this app to TestFlight and the App Store**. Until you send a build it reads **No App Store submissions yet**. Press **Submit to App Store**.
Apple membership costs **\$99 / year**. Start this early. See [Create your Apple Developer Account](/store-guides/apple-developer-account).
Step 1 of the **Publish to App Store** dialog is **App Info**: the icon, the **App Name** (max 30 characters), the version, and the bundle identifier. The platform field reads **iOS**, described as **iPhone & iPad**. The panel adds **Each platform is submitted separately**.
Step 2 is **Apple Developer**. Enter your **Apple Developer Email** and **Apple Developer Password**. Rork builds on its own machines, so you do not need Xcode.
Step 3 is **Submit**. Press **Start Submission**, then stay on the page while Rork builds. Apple can ask for a verification code on a signed-in device. Enter that code in Rork when it asks.
A finished upload lands in **App Store Connect**, and the chat shows **Available on TestFlight**. The project keeps every build in **App Store Submissions**, each one with its TestFlight link.
Press **New Submission** for the next version. Use **Beta Invite Link** to share a TestFlight invite. The step-by-step version, with the Apple screens, is in [Publish Your App to the Apple App Store](/store-guides/publish-app-store).
After the app goes live, its ratings and written reviews arrive in the same **App Store** section, and the agent drafts your replies. See [Reply to App Store reviews](/store-guides/app-store-reviews).
Run the [AI App Store Reviewer](/ai-app-store-reviewer) before you submit. It checks your app against Apple's rules inside the project, so you find the rejection reasons first.
## Add an iPhone app to a project you already have
Any project can grow an iPhone app. Click **+** above the preview and pick **iOS (Swift)**, described as **Native iPhone app**. You can also use **Project Settings → Add new app**, or just ask:
```
Add a native iPhone app to this project
```
On an older Expo project Rork also offers a card: **Make this app native iOS**, with the line **Recreate it in SwiftUI for iPhone**. Press **Add iOS app**.
Confirm the **Add iOS app?** card when it appears. The agent rebuilds your screens, navigation, data flows, and design as a Swift app.
When the project already has an iPhone app, the same menus offer the other platforms instead:
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 iPhone app can do
A Swift app talks to iOS directly:
* Screens in SwiftUI: tab bars, lists, forms, and system-style settings
* The camera, sensors, local storage, and iOS permission prompts
* Work that keeps running in the background, within Apple's rules
* Accounts, data, and push notifications from the same backend as your other apps, see [Backend](/backend/index)
* A real Xcode project you can export to GitHub, see [How to sync your project with GitHub](/tutorials/how-to-connect-github)
**Rork Max** adds iPad layouts, Apple Watch, Vision Pro, iOS widgets, and native games. See [Plans & Subscriptions](/introduction/subscriptions) and the [Rork Max page](https://rork.com/max?utm_source=docs\&utm_medium=referral\&utm_campaign=docs-cta\&utm_content=iphone-max).
## What an iPhone app cannot do
An iPhone app is Apple only. These are the limits that matter:
* It does not run on Android. Add an Android app to the same project if you need both.
* The cloud simulator has no physical camera, and it cannot receive Apple push notifications.
* You need an Apple Developer membership to publish. Membership costs **\$99 / year**.
* Each Apple platform is submitted separately.
* iPad, Apple Watch, Vision Pro, iOS widgets, and native games need **Rork Max**.
* A web app in the same project still cannot ship through the App Store. Publish that one to `rork.app`.
If you also need an Android 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 iPhone app is a Swift codebase built with SwiftUI. It is not a browser app in a shell, and it is not an Android app.
No. Rork builds on its own machines and submits to App Store Connect from the browser. To install an app on your own iPhone over USB, use a Mac or a Windows PC. See [Rork Companion](/rork-max-swift) and the [Rork Max iPhone app](/rork-max/rork-max-app).
You can build Swift apps on any Rork plan. Builds and simulator previews spend credits. Access to the Rork Max iPhone app is rolling out separately to selected accounts. See [pricing](https://rork.com/pricing) for current plans and credits.
**0.2 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).
To App Store Connect, then TestFlight. It is not on the public App Store until you finish the product page and pass Apple review.
Yes. An iPhone app is iPhone only, but you can add an Android app or a web app to the same project and share one backend. See [Convert your app between iOS, Android, and web](/import/convert-between-platforms).
Yes. Add a native iPhone app to the same project and the agent rebuilds your screens in Swift. Your Expo app stays where it is. See [What happened to Expo?](/expo).
## Next steps
What each platform is good at, and how to choose.
Install the app on your iPhone and keep building there.
The \$99 / year membership you need before App Store review.
Check Apple's rules inside the project, before you submit.
Accounts, data, files, and push notifications.
iPad, Apple Watch, Vision Pro, widgets, and native games.
# How to add a Free Trial
Source: https://docs.rork.com/make-your-app-profitable/paywalls/how-to-add-a-free-trial
This guide goes over how to add an free trial offer to your IOS app
Requirements:
* RevenueCat already integrated
* Subscriptions already configured in the App Store
First, open up the subscriptions tab inside your app's distribution section in App Store Connect and then click on the subscription you want to add a free trial to:
After that, click on the plus button to add a new subscription:
Click Introductory offer. Then set a duration:
After that, click next and confirm. Within the next 20 minutes, your app should be displaying your free trial.
# How To Create a privacy policy, Terms and conditions, and EULA
Source: https://docs.rork.com/make-your-app-profitable/paywalls/how-to-set-up-your-policies
Every app must include Terms & Conditions, a Privacy Policy, and an EULA to be approved on the App Store and to protect you legally.
### 1. End User License Agreement (EULA)
* You **do not need to write your own EULA**.
* Apple allows you to use **Apple's Standard EULA**, which is accepted by default on the App Store.
* When submitting your app, simply select **Apple's Standard EULA** unless you have custom legal requirements.
**Recommended**: Use Apple's Standard EULA.
### 2. Privacy Policy
* A **Privacy Policy is required** for all apps, especially if you collect:
* User data
* Analytics
* Payments
* Account information
* You can generate a compliant Privacy Policy using tools like:
* **Termly**
* [**PrivacyPolicies.com**](http://PrivacyPolicies.com)
* **Iubenda**
These tools allow you to:
* Answer a few questions about your app
* Auto-generate a policy
* Host the policy or export it as a URL
**Recommended**: Use **Termly** for fast, App Store-ready policies.
### 3. Terms & Conditions
* Terms & Conditions define how users are allowed to use your app and limit your liability.
* You can generate Terms & Conditions using the **same tools**:
* Termly
* [PrivacyPolicies.com](http://PrivacyPolicies.com)
* Most tools bundle **Terms + Privacy Policy** together.
**Recommended**: Generate Terms & Conditions with the same service you use for your Privacy Policy.
### 4. Where to Use These Policies
Make sure you:
* Add all policies in your App Store description to be safe
* Link to your policies inside the app's Settings and Paywall.
# How to add a paywall to your Rork app with RevenueCat
Source: https://docs.rork.com/payment-guides/revenuecat-copied-1
Are you ready to add payments to your app? Use this guide to setup Rork with RevenueCat paywall and deploy your app to Production with a full feature gated payment system!
# Step-by-Step Tutorial: RevenueCat in a Rork App (End-to-End)
## 1) Build your app in Rork
1. Write your prompt (example from video: "note-taking calorie tracker with AI calorie estimate").
2. Submit prompt → Rork builds the app.
3. If you think of additional features mid-build (e.g., "scan your meal"), add them to the **queue** so Rork can handle them after the first prompt.
## 2) Connect RevenueCat inside Rork
1. In Rork, go to **Integrations**.
2. Click **Connect with RevenueCat**.
3. Log in / sign up in RevenueCat.
4. Authorize Rork to access your RevenueCat account.
5. Click **Create new project** in RevenueCat.
* Name it whatever you want (e.g., "Calorie Tracker").
6. Go back to Rork **chatbot** and say:\
**"Set up RevenueCat."**
7. Rork will set up:
* Offerings
* Products
* Entitlements
* Environment variables / API keys
8. When Rork asks to set environment variables → click **Yes**.
## 3) Test purchases in RevenueCat Test Store (sandbox inside RC)
1. In the Rork app, tap the subscription (example: **\$40/year**).
2. You'll see options like:
* Test a valid purchase
* Test failed purchase
3. Tap **Test valid purchase**.
4. In the RevenueCat dashboard → **Overview** → toggle **Sandbox data**.
5. If you see sandbox MRR / the subscription (ex: \$40/year), then:\
✅ Rork + RevenueCat Test Store are connected.
> Note: These are NOT real App Store subscriptions yet.
## 4) Push the app to TestFlight (required for real Apple IAP)
1. In Rork, go to **Get users → Submit to TestFlight**.
2. Click **New submission**.
3. (Optional but recommended) Generate an app icon using Rork.
4. Fill out **Apple Developer** information when prompted.
5. Submit and wait for the build/upload to complete.
6. Go to **App Store Connect**. Complete the required compliance info so the build is testable.
## 5) Create subscriptions in App Store Connect (real products)
### Create a Subscription Group
1. App Store Connect → **Subscriptions**
2. Create **Subscription Group**
* Name it something simple (example: "Subscriptions")
### Create monthly subscription (repeat for yearly)
1. Create **Subscription**
2. Set:
* Reference name: "Monthly subscription."
* Product ID: "monthly\_subscription" (or same name)
3. Configure required metadata:
* Duration: **1 month**
* Availability: **Everywhere**
* Price: example **\$4.99/month**
4. Add localization:
* Display name: "Monthly subscription."
5. Add a screenshot/image of your paywall (required for submission readiness)
6. Submit / Save
7. Repeat the same steps for **Yearly**.
✅ After this, products should be "Ready to submit" in App Store Connect.
## 6) Connect App Store Connect to RevenueCat (so products sync)
RevenueCat → **Apps → iOS app**
### Add App Info
1. Copy your **Bundle ID** from App Store Connect into RevenueCat.
### Add In-App Purchase Key
1. App Store Connect → **Users and Access → Integrations**
2. Under **In-App Purchase**, click the **+**
3. Name it (example: "RevenueCat Calorie Tracker")
4. Download the key file
5. Upload/drag into RevenueCat
6. Copy **Issuer ID** (above the integration keys list) → paste into RevenueCat
### Add App Store Connect API Key
1. Still in **Users and Access → Integrations**
2. Create **App Store Connect API** key
3. Download it → upload into RevenueCat
4. Enter **Issuer ID** again
### Add Vendor Number
1. App Store Connect → **Reports** (Business section)
2. The top left shows the **Vendor Number**
3. Copy → paste into RevenueCat
### Enable server-to-server notifications (recommended)
* Toggle: **Track new purchases from server-to-server notifications**
### Add App-Specific Shared Secret
1. App Store Connect → **Apps → Your app → App Information**
2. Scroll to **App-Specific Shared Secret**
3. Click **Manage → Generate**
4. Copy secret → paste into RevenueCat
5. Click **Save changes** in RevenueCat
✅ Now: Apple ↔ RevenueCat is connected.
## 7) Import your App Store products into RevenueCat
1. RevenueCat → **Product Catalog**
2. Choose **Default** (or your active catalog)
3. Click **Add new product → Import products**
4. Select the monthly + yearly products → **Import**
5. For each imported product:
* Attach an **Entitlement** (same entitlement for both is common)
## 8) Attach products to your RevenueCat Offering
1. RevenueCat → **Offerings → Default**
2. Click **Edit**
3. Attach each App Store product to the correct package
4. Click **Save**
## 9) Final test: TestFlight purchase
1. Install your app via **TestFlight**
2. Open your paywall in-app
3. Your subscriptions should now be purchasable via TestFlight and in production after release.
# Common Issues:
* Make sure all of your Agreements/Bank information is active. (Your subscriptions will not work if this isn't set up
* App store public api key isn't set properly.
* Just give this key to Rork and say, "Make sure Apple and RevenueCat are connected".
## What to do next:
After adding a paywall, you will still be rejected from the App Store if you do not have a privacy policy, terms and conditions, and a visible EULA.\
\
In your App Store description, make sure to mention that every feature requires a paid subscription if you are hard paywalling your app. If you do not, Apple will reject you.
[How to create policies?](/make-your-app-profitable/paywalls/how-to-set-up-your-policies)
# Publishing
Source: https://docs.rork.com/publishing
The short version of an App Store submission from Rork: create the Apple Developer account, press Publish, sign in, and enter the verification code.
1. Create an Apple Developer account
2. Click Publish
3. Enter your login details
4. Enter the verification code
Then ship your app to Apple for review!
# NanoBanana AI Image App Tutorial
Source: https://docs.rork.com/quick-start-examples/nano-banana-image-app
Build a custom AI image app that uses Google's popular NanoBanana API.
# Build a NanoBanana AI Image App
> Build a NanoBanana AI image app from scratch with Rork. This shouldn't take more than 10 minutes to get to a solid version.
## Create your Rork app
⏰ *Estimated time: 10 minutes*
Follow the steps in this guide to create an AI Image NanoBanana app that uses natural language to let you edit images.
Every viral and successful AI image editing app in the App Store market focuses on a popular niche that a lot of people want to see themselves as. For example
* *Celebs Style*: Take a selfie with any Celebrity now
* *Playing Cards Style*: Turn your pictures into playing cards
* *Polaroid Style*: Turn your photos into realistic looking polaroids
Choosing a style is the first step in creating this app because it will prompt our initial message to Rork. The simpler and quicker it is to explain what the style is to others, the better it will be.
For our app, we will be building a graduation photos app. Perfect for college kids who are about to graduate from their schools.
Open the [Home Page](https://rork.com/) and enter the following prompt:
> Create an IOS Graduation Photoshoot Image AI app.
>
> * lets people submit or take a photo of themselves
> * optionally, lets them add which the color of their schools gown and cap
> * NanoBanana takes that photo and input and then generates 4 images
> * returns 4 photoset high quality professional photoshoot set of graduation photos.
> * give an option so they can save and also store each one locally
Instantly, **Rork** handles all the design and development and will start building your app. You can test it right in the browser, in the iOS simulator or the Android emulator, or install an iPhone app on your own device with the [Rork Max app](/rork-max/rork-max-app). The app will not fully load until it's finished developing. This should take just a few minutes depending on the complexity of your application.
Once finished, you should see a beautiful simple graduation photoshoot AI image app with an easy to use flow. Try it out and make sure it works. Rork automatically connects your app to the top LLMs like ChatGPT, NanoBanana, and more when you build inside Rork.
## Things to Try
* Take a selfie and then choose your cap and gown color
* Try a wacky combination of two different colors
* Save your photos to your phone and make sure that works
In just one prompt we got an awesome app that generates graduation photoshoots!
## Additional Features
The beauty of Rork is being able to iterate on your apps beyond their initial prototype. You can build full production apps inside of Rork. Here are some additional features you can add to your app.
Our initial app only gave us 4 color options to choose from, but some schools may be a completely different color, or maybe, a user wants a really specific color. So let's add a custom color picker.
**Here is the custom color picker prompt:**
> Please add a custom color picker beyond the 4 options that lets user enter hex or choose from a color picking component.
# Request Documentation
Source: https://docs.rork.com/request-documentation
Missing a guide? Tell us what you need documented and we will write it.
Anything else you would like information/documentation on, please let us know below 👇
[**Click Here!**](https://form.typeform.com/to/V1FsiZmC)
# Rork Companion for Windows and Mac
Source: https://docs.rork.com/rork-max-swift
Use the free Rork Companion desktop app to install Rork Max or a Swift app you built on your iPhone over USB.
Rork Companion connects your computer to your iPhone so you can install and test apps over USB. It is available for **Windows and macOS**.
On Windows, Companion is the installation path for the [Rork Max iPhone app](/rork-max/rork-max-app). On a Mac, Chrome and Edge can install Rork Max directly from the browser. Companion is also available on Mac when you use another browser or want to install a project from the Rork editor.
## Choose your setup
To install the Rork Max iPhone app, open **[rork.com/ios/install](https://rork.com/ios/install)** on your computer. The same page detects your operating system and browser: on Windows it shows the Companion download and instructions; on Mac it offers browser installation or Companion. For an overview of the iPhone app, see [rork.com/ios](https://rork.com/ios).
| Your computer | How to install Rork Max on your iPhone |
| - | - |
| **Windows** | Install Rork Companion. The Windows download is for x64. |
| **Mac with Chrome or Edge** | Use the [browser installer](https://rork.com/ios/install). No desktop app is needed. |
| **Mac with Safari or Firefox** | Use Rork Companion, or open the installer in Chrome or Edge. |
Rork Companion is the app on your **computer**. Rork Max is the app on your **iPhone**, where you can build, test, and install your projects.
## Set up Rork Companion
### Download for your computer
Follow the steps on the [installation page](https://rork.com/ios/install) to get Companion for your computer. If you want to install a project directly from the Rork editor, you can also download Companion here:
* **Windows:** [Download Rork Companion for Windows (x64)](https://companion.rork.com/windows/nsis/x64).
* **Mac:** [Download Rork Companion for macOS](https://companion.rork.com/mac/installer/universal).
Run the installer, then open Rork Companion.
### Sign in
Sign in to Companion with your **Rork account** and your **Apple Account**. Use the same Rork account as the one you use in the browser. The Apple Account signs the apps for your iPhone.
### Connect your iPhone
Connect your iPhone to the computer with a **USB data cable** and unlock it. If the phone asks whether to trust the computer, tap **Trust** and enter your passcode. Keep Companion open while you install.
### Enable Developer Mode
On your iPhone, open **Settings → Privacy & Security → Developer Mode**, turn it on, and follow the restart and confirmation prompts.
If the setting is missing, keep the phone connected and unlocked, finish the connection steps in Companion, then reconnect the USB cable and check again.
## Install the Rork Max iPhone app
Once setup is complete, click **Install Rork Max** in Companion. Rork Max appears on your iPhone's Home Screen. It requires **iOS 18 or later**.
Open Rork Max on your iPhone to work on your projects. To install an app you built, open the project and use **More → Install on Device**. See the [Rork Max app guide](/rork-max/rork-max-app) for the full workflow.
Access to the Rork Max iPhone app is rolling out to selected accounts and is not tied to a particular subscription. If your account does not have access yet, use the [Rork simulator](/features/simulator) or the project installation flow below.
## Install a project from the Rork website
Companion can also install a Swift app directly from your project in the browser:
1. Keep Companion open, signed in, and connected to your unlocked iPhone.
2. Open the project in Rork and select its iPhone app.
3. Click **Run on your device** above the simulator. If Rork first offers the Rork Max iPhone app, expand **Other ways to run** to find Companion.
4. Complete any remaining setup steps, select your connected iPhone, and use the install control.
5. Wait for the build and installation to finish, then open your app on the iPhone.
## If your iPhone does not appear
* Check that the cable carries data, not just power, and try another USB port.
* Unlock the iPhone and approve its trust prompt.
* Check that Companion is open and uses the same Rork account as the browser.
* Finish the Apple Account and Developer Mode steps shown in Companion.
If installation still fails, include the exact error when you contact support. You can continue testing in the [simulator](/features/simulator), or use [TestFlight](/store-guides/testflight-beta-testers) to distribute a build to testers.
# Rork Max app for iPhone
Source: https://docs.rork.com/rork-max/rork-max-app
Rork Max is the first mobile app that lets you build Swift and Web apps, install, and publish to the App Store on the go. It runs the native iOS apps you build with Rork right on your iPhone, replacing Xcode and TestFlight without compromising performance.
All your apps in one place
Swift and Web in one list Open any and keep going
Build and preview on the go
No TestFlight needed Run natively on iPhone
Install or publish from the Rork app
Project Actions on your phone No laptop required
The Rork Max app shows native **Swift** apps and **Web** apps. Android (Kotlin) projects do not appear in the Apps tab.
If you sign in and the list is empty, you probably have no Swift or Web project yet. Start one on the web at [rork.com](https://rork.com?utm_source=docs\&utm_medium=referral\&utm_campaign=rork-max-app\&utm_content=info-empty-apps), or tap **+** in the app and choose **Swift** or **Web**.
## What you can do with the Rork Max app
### Build apps from your phone
The complete Rork Max chat, redesigned for iPhone: plans, todos, questions, and build progress. Start a new app or open any app you've already built and continue whenever you want. All your apps, sessions, and their latest state are waiting right there, in the **Apps** tab. Each project shows whether it is **Swift**, **Web**, or both.
Swift and Web apps you have built. Tap + to start a new one.
Tap **+** and describe what you want to build. Choose the platform before you create:
The chat works the same way as Rork Max on the web:
* **Voice input**: dictate your message instead of typing, then send it or edit it first.
* **Images and annotations**: attach photos, or grab a screenshot of the running app right from the chat and draw on it to point at exactly what you want changed.
* **File uploads**: attach documents straight from the Files app (specs, CSVs, designs) so the agent can work with them.
* **Plan mode**: have the agent propose a plan and review it before any code is written.
* **Model picker**: choose the AI model for each message, or leave it on Auto.
* **Message queue**: while the agent is working, keep sending follow-ups. They line up above the composer and run one after another. Tap a queued message to edit it, or tap **X** to remove it before it starts.
* **Agent widgets**: the agent can ask you questions, request API keys, generate images, sounds, and 3D models for your app, and show live build progress, all inside the chat.
Attachments and settings live behind the **+** button next to the message field:
While a turn is running, the send button becomes **Queue message**. Stack a few prompts (a color tweak, onboarding, empty states, whatever is next) and clear any you change your mind about:
### Browse your assets
Every asset in your project lives in one place: images, video, music, sound effects, voice, 3D models, and files. Open **More** in the top right of the chat to reach **Project Actions**, then choose **Assets**:
Project Actions: preview, Assets, Open in Browser, Publish, and more.
Preview images and video, play audio, and open 3D models in a full-screen viewer you can rotate with your finger (or drop into your room with AR). Tap **Use in Chat** to hand any asset to the agent, and watch generation progress live: 3D models show each stage from generating to texturing, rigging, and animating.
Asset library in one place
3D, videos, music, and sound effects
3D generations and animations
Preview models, then play Idle, Walk, and more
### Manage your account and credits
Everything billing-related lives in the Profile tab, under **Account & Billing**:
* See your plan and usage, and upgrade or change your subscription (subscription changes open on the web).
* Check build credits and cloud credits in one place.
* **Auto Top-Up** and payment method changes open securely in the browser and pick up right where you left off.
Account & Billing in Profile: plan, credits, and payment method.
### Preview natively, no TestFlight needed
Swift builds run natively inside the app. Full speed, real gestures, no streaming, no simulator. You're testing the real thing, not a video feed of it.
While your Swift app is running, a floating orange Rork button stays on top of it (drag it anywhere if it's in the way):
* **Tap** it to open the chat and keep iterating on your app.
* **Press and hold** it to leave the running app and get back to your list of apps.
The floating orange button brings back the chat.
### Preview Web apps on your phone
Web projects preview inside Rork Max too. Open a Web app from the Apps tab, iterate in chat, and tap **Reload Preview** when you need a fresh load.
Web preview inside the Rork Max app
Web Project Actions: Reload, Assets, Browser
From **Project Actions** (**More** in the top right of the chat) Swift apps can also **Prepare Preview** or **Install on Device**. Web apps use **Open in Browser** when you want the preview outside Rork Max.
### Install apps straight to your Home Screen
Rork Max can install the apps you build directly to your device. They land on your Home Screen as real iOS apps. Launch them like anything else and test native iOS features right away:
Install from the Rork Max app: your app lands on the Home Screen.
* Widgets
* Camera
* Dynamic Island and Live Activities
* Screen blocking and focus controls
### Publish to the App Store from your phone
Open **More → Publish App** to reach **App Store Submissions**, or simply ask the agent in chat to publish your app. From the submissions hub you can start a new submission, track uploads, open TestFlight, and share a **Beta Invite Link** with testers.
App Store Submissions: track builds, then publish in three steps.
Tap **New Submission** to walk through App Info (platform, icon, name, version), connect your Apple Developer account, and upload. Chat widgets can also help with App Store metadata, screenshots, and compliance along the way.
Swift apps can publish to the App Store from your phone. Web apps preview in Rork Max and in the browser, but they are not submitted to the App Store from this flow.
## How to install the Rork Max app
Rork Max runs the apps you build as real native code inside itself, which is why it can't live on the App Store. Install it on your iPhone over USB from a Mac or a Windows PC.
Open **[rork.com/ios/install](https://rork.com/ios/install?utm_source=docs\&utm_medium=referral\&utm_campaign=rork-max-app\&utm_content=install-section)** on your computer. This is the same link for Mac and Windows. The page automatically detects your operating system and browser and shows the right installation steps:
* **Mac with Chrome or Edge:** install directly in the browser, with no desktop app to download.
* **Windows:** download [Rork Companion](/rork-max-swift), sign in, connect your iPhone, and click **Install Rork Max** in Companion.
* **Mac with Safari or Firefox:** use Companion, or switch to Chrome or Edge for the browser installer.
You only need the computer once. After that, everything lives on your iPhone: Rork Max updates itself over the air, so new features simply arrive the next time you open the app. No cable, no reinstalling.
Occasionally we ship a new version of the Rork Max app itself that can't arrive over the air. In that case, just go back to [rork.com/ios/install](https://rork.com/ios/install?utm_source=docs\&utm_medium=referral\&utm_campaign=rork-max-app\&utm_content=install-section-reinstall) and run the install again. It always installs the latest version and replaces the one on your phone.
## Requirements
* An iPhone running **iOS 18 or later** (check in Settings → General → About)
* A **Mac with Chrome or Edge**, or **Rork Companion on Windows or Mac**, for the initial USB install. The Windows installer is x64
* A **data USB cable**, preferably the one that came with your iPhone or any MFi-certified cable (charge-only cables won't work)
* A free or paid **Apple Developer account**. A free account lets you keep up to 3 sideloaded apps installed at a time; a paid membership removes that limit
* **Access to the Rork Max iPhone app**, which is rolling out to selected accounts and is not tied to a particular plan. Swift builds are available on every Rork plan and spend credits: see [pricing](https://rork.com/pricing?utm_source=docs\&utm_medium=referral\&utm_campaign=rork-max-app\&utm_content=requirements-pricing)
Companion is still supported on both Windows and Mac. It handles the Windows installation and provides an alternative for Mac browsers that cannot connect to the iPhone over USB. See [Rork Companion for Windows and Mac](/rork-max-swift).
## Frequently asked questions
Access to the Rork Max iPhone app is rolling out to selected accounts and does not depend on a particular subscription. You can build Swift apps on any Rork plan; builds and simulator previews spend credits. See [pricing](https://rork.com/pricing?utm_source=docs\&utm_medium=referral\&utm_campaign=rork-max-app\&utm_content=faq-pricing).
Yes, Rork Max is an iPhone app. It needs iOS 18 or later. You can check your version in Settings → General → About.
Either works. On Mac, use Chrome or Edge for the browser installer. On Windows, use [Rork Companion](/rork-max-swift). Companion is also an option on Mac if you use Safari or Firefox. After the initial installation, you can build and test from your iPhone.
On a Mac with Chrome or Edge, the installer runs in the browser. On Windows, or a Mac with Safari or Firefox, install the free Companion desktop app. The [install page](https://rork.com/ios/install?utm_source=docs\&utm_medium=referral\&utm_campaign=rork-max-app\&utm_content=faq-install) shows which path to follow.
The Mac browser installer keeps Apple signing credentials, certificates, and pairing data in the browser. Companion stores them on your computer instead. App signing happens locally in both installation flows.
No, both free and paid Apple Developer accounts work. The only difference: a free account lets you keep up to 3 sideloaded apps installed at a time, while a paid membership removes that limit.
Preferably, yes: the one that came with your iPhone, or any MFi-certified cable. It must be a data cable, not a charge-only one. With uncertified cables the connection can drop mid-install, and we can't guarantee it will work.
Companion is still the Windows installation path and an alternative on Mac. In Chrome or Edge on a Mac, you can install Rork Max directly in the browser. Companion also supports installing a Swift project from the Rork editor. See [Rork Companion for Windows and Mac](/rork-max-swift).
Yes, really. The apps you build land on your Home Screen as real iOS apps. You can launch them like anything else and test widgets, camera, Dynamic Island, and other native features right away.
Yes. When you tap **+**, pick **Web** as the platform (or open an existing Web project from the Apps tab). Web apps preview inside Rork Max and can open in the browser from Project Actions. Native Apple features like widgets and Dynamic Island still need a Swift app.
No. Rork Max supports **Swift** and **Web** projects. Swift unlocks native Apple features: widgets, Live Activities, ARKit, HealthKit, even 3D games. Not sure what to pick? See [iPhone, Android, or web: what's the difference](/swift-vs-react-native/whats-the-difference).
Yes for Swift apps. Open **More → Publish App**, then use **App Store Submissions** for uploads, TestFlight, and beta invite links. You can also just ask the agent in chat to publish your app, and it will walk you through the submission. Web apps are not published to the App Store from this flow.
Rork Max updates itself over the air for most releases. Install it once, and new features simply arrive the next time you open the app. Occasionally a host update needs another pass through [rork.com/ios/install](https://rork.com/ios/install?utm_source=docs\&utm_medium=referral\&utm_campaign=rork-max-app\&utm_content=faq-updates); that install replaces the app on your phone.
Each install is tied to the Apple Developer team you signed with, so if you've installed Rork Max with different Apple accounts or teams, each one shows up as a separate app. Reinstalling with the same Rork account and the same Apple team always replaces the existing app instead of adding a new one. Feel free to delete the copies you don't use, just keep in mind that a free Apple Developer account only allows 3 sideloaded apps at a time.
Instead of waiting for the SMS, grab the code from a trusted device: on any iPhone, iPad, or Mac where you're already signed in, go to **Settings → your name → Sign-In & Security → Get Verification Code**. Apple's [verification code guide](https://support.apple.com/102606) walks through every option. Still stuck? Reach [Apple Support for Apple Account](https://support.apple.com/apple-account). SMS delivery is on their side.
Two things to check. First, trust the developer on your iPhone: **Settings → General → VPN & Device Management** → tap your account → **Trust**. Second, make sure Developer Mode is on: **Settings → Privacy & Security → Developer Mode**. And if you're on a free Apple Developer account, Apple allows only 3 sideloaded apps at a time, so you may have hit that limit. The paid [Apple Developer Program](https://developer.apple.com/programs/) (\$99/year) removes it.
Just open Rork Max whenever inspiration strikes. All your apps, sessions, and their latest state are waiting right there.
# Ideation
Source: https://docs.rork.com/rork-playbook/playbook
How to come to a successful idea
# **(Disclaimer)**
These points come from what we have seen work for builders on Rork. There are no absolute rules when it comes to making money online. Always trust your gut.
# **Ideation**
Your marketing will only take you as far as your idea allows it to. When developing an idea, the primary focus should be on solving a real problem or improving the user's life in a meaningful way.\
\
The easiest way to come up with an idea is to find a problem you experience. Then figuring out a creative way to solve it. This will not only help people who are experiencing a problem, but there are also probably a lot more people experiencing the same problem. It also makes you understand your ideal customer a lot more, due to the fact that you are your ideal customer.
\
A good app idea solves a problem that is:
* felt frequently (daily or weekly)
* emotionally irritating or deeply frustrating
* experienced by a large group of people
A user forgetting a password once a month is a weak pain.\
A user procrastinating *every single day* is high-frequency pain.
The more often a person experiences a pain point, the more likely they are to:
* search for a solution
* value the solution
* pay for the solution
* build a habit using the solution
### **Follow User Behavior, Not Stated Desires**
Users *say* they want one thing, but *actually* behave differently.
For example:
* Many people *say* they want to read more
* Their actual behavior: scrolling on TikTok until 2 am
Use behavioral truth instead of verbal claims.\
Observe human nature in action.
Sometimes the best ideas come not from:
"What do people want?"\
but rather\
"What do people actually do, even when they shouldn't?"
### **Build for a Niche First, then Expand**
A common mistake: building for everyone.
A better approach:\
Solve a problem for a very specific audience first.\
\
The largest companies started as a niche
* Facebook started as Harvard-only
* Amazon started with just books
* Snapchat started as a messaging app for teens
* TikTok started as a dancing Gen-Z app.
Owning a niche builds:
* loyalty
* trust
* word of mouth
* authority
Then you expand outward.
Steal proven mechanics and apply them to different formats\
For ex:
* **Duolingo → Fitness & productivity:** streaks, XP, level-ups to gamify consistency.
* **Spotify Wrapped → Personal stats:** yearly fitness, study, sleep, or productivity analytics worth sharing.
* **MyFitnessPal → Behavior logging:** track moods, workouts, studying, spending, or habits.
* **Tinder → Swipe decisions:** instantly choose exercises, outfits, meals, or daily goals.
* **Fortnite → Seasonal progression:** short "seasons" of focused improvement with resets and rewards.
Your idea should also have a viral quality. This ties into the Purple Cow principle, which states that in a field of ordinary cows, the purple one is the only one that stands out. To succeed, your product must be remarkable.
Your app needs to visually stand out from the moment it appears on screen. It should have an element of surprise or uniqueness that compels a viewer to stop scrolling and download your app. If you create something that the user has never seen before, curiosity will drive them to try it.
# **A Real Example**
One builder we worked with launched two apps in the same month.
**App One:** a RizzGPT-style clone. It wasn’t original, and the founder wasn’t particularly passionate about it, but it looked lucrative.\
**App Two:** an AI sports coach that analyzes match footage and breaks down your strengths, weaknesses, and how to improve. The founder used to compete in that sport, and it’s something they would’ve loved to have growing up.
Both apps were marketed through seamless influencer integrations.
**The results were eye-opening.**
* App One generated **1.5 million views** and made **\$15**.
* App Two generated **1 million views** and made **\$17,000**.
The difference wasn’t reach, it was *meaning*.
App One was a remix of previously viral ideas. App Two was a genuinely distinct product, something people hadn’t really seen before and actually cared about.
This revealed a key lesson:\
If your product is not a *Purple Cow*, then your **marketing must be**.
When the idea itself isn’t remarkable, you’re forced to rely on extreme creativity and unconventional tactics to stand out. In those cases, the marketing becomes the product.
Brands like **Liquid Death** and **Rainbet** understand this perfectly. Their differentiation lives in how they market. The experience *is* the marketing.
But when the product itself is remarkable, marketing becomes leverage, not a crutch.
# **Provide long-term value**
An app with a viral hook but no real utility will not have sustainable longevity. Users will come for the novelty and leave quickly.
On the other hand, apps that have valuable but less exciting features tend to retain users over time. The ideal balance is to attract users with a viral and attention-grabbing feature, and then retain them using your practical, useful, everyday features.
Do not be afraid to pull users in with something fun or unique, and then keep them with the features that provide long-term value.
# How to Scale Your Mobile App to $50k+/Month (The Complete Guide)
Source: https://docs.rork.com/rork-playbook/scale-to-50k-month
The complete playbook our top builders use to scale: how to pick the right app, get your first paying users, nail your onboarding, and scale distribution.
Rork builders are shipping more apps to the App Store than ever before.
Some of them are making $20k–$50k a month from apps they built in days or weeks but most aren't making any money.
We made the build easy but distribution is still hard.
Most builders will miss this wave. Not because they're not smart enough, not because they can't build, but because building an app got easier and distributing it didn't.
So here's the exact playbook our top builders are using to scale: how to pick the right app, how to get your first paying users, how to nail your onboarding, how to scale your distribution. Everything.
## Step #1: Pick the Right App
You can build as many apps as you want. The trick is knowing which one to commit to.
Every successful builder has one thing in common: they cracked the code on a single app first. Once they had a system that worked, they replicated it across as many apps as they wanted.
You might see top builders shipping multiple apps right now. That's only because they already learned how to make one work. The distribution patterns, the onboarding instincts, the conversion math: they figured it out on app #1.
That's where you want to be focused. Your first scaled app teaches you everything you need to know to scale the next one.
Distribution is where most builders stall. So pick one app, commit to it long enough to crack distribution, then go wide.
So how do you actually pick the right app to build?
You can do one of two things.
1. **Grab a successful app and add your own twist to it.** Plain copycatting won't get you anywhere. Add your own personality, your own colors, a mascot, whatever makes the app yours. Two apps serving the same core need can have completely different design philosophies and not look at all like each other.
2. **The other thing you can do is grab two successful apps and combine their main features into one.** Think productivity app + faith. Think fitness tracker + screen time blocker. Think journaling + gamification. This is actually harder to do, so if you're just starting out we'd recommend adding your twist to a successful app instead.
Once you know what to build, ship it with Rork. You shouldn't be taking more than 2 weeks to go from idea to launching. Speed is everything.
Now, how do you know if you should stick with the app you launched?
You'll know instantly. If you've launched multiple apps before, you know that most won't get any traction on launch day even with the Apple boost (Apple's way of pushing your app to new audiences when you first launch it).
Your soon to be successful app will get 1 trial, 5 trials, even a direct conversion on launch day.
Plenty of builders ship 3 or 4 apps in the same niche and get absolutely no conversions on launch day, even after going viral on TikTok. Then they ship the right one and get 5 conversions on day one. That's the signal.
If you don't get conversions on your launch day, try to go viral on social media. If after 100k views you still don't get a single conversion, move to the next app idea.
## Step #2: Obsess Over Distribution
Apps are a funnel.
At the top of the funnel you have distribution: eyeballs, views on social media. At the bottom you have your actual conversion, which is people paying money for your app.
There is no point in optimizing for anything below the top of the funnel when you first start out.
Improving animations, making your mascot cuter, changing colors, optimizing retention, adding new features, even optimizing onboarding at this stage. All a waste of time.
> "But if my app isn't optimized I might not convert as well on the few downloads I do have."
It doesn't matter. There is nothing to optimize for or change with 100 downloads. We'd even argue this is the case with 5k downloads.
So don't touch your app at all until your distribution engine is running decently well (we'll get to that).
You have 4 options:
1. Make content yourself
2. Hire influencers
3. Hire UGC creators
4. Paid ads
Knowing what to pick depends solely on how much money you can invest into your app right now.
The more money you can invest, the faster you'll be successful.
### Making Content Yourself
The best way to go if you're new to distribution, even if you have money to invest.
Making content yourself develops your viral sense and gives you the foundations to know what to look for when you want to hire influencers and UGC creators.
Start posting at least 21 times a day across TikTok, Instagram, and YouTube Shorts. It's not as much as it sounds. You only have to make 7 posts a day and cross-post them to the different platforms.
Now the question is what content to actually make. It depends on the niche. Look at the content your competition is making and copy it directly. Use the same hooks, the same script, even the same CTA if you can.
The type of content you make depends on your niche, but here are some formats you can try right now.
#### UGC Reaction + Demo
This format alone has gotten apps to \$10k+/month on its own.
Buy reaction clips from friends or from UGC creator marketplaces, and stitch your demo to it.
The hook, which is the combination of the clip and the text you use on top of it, needs to be really good. Make sure the demo you're using is not longer than 8 seconds.
#### Slideshows
Another strong format. There are apps making \$20k+/month just from slideshows (and they perform great as ads as well).
Make sure your posts aren't Pinterest feeds with a bunch of random aesthetic pictures and no cohesion.
Make your slideshow accounts consistent. Take direct inspiration from your competition and include a direct CTA to download your app. Build a brand identity around your slideshows.
A good slideshow account has a brand identity and is consistent. A bad one is all over the place, with no clear format and no clear brand identity.
#### Memes
These work really well on Instagram. Wouldn't be the first format to try, but it can be great for brand awareness, especially when coupled with a Manychat automation and Instagram Stories that drive your followers to download your app.
### Influencers
Influencers are a great way to scale your app. A lot of apps hitting \$25k+/month scaled this way.
Running influencers correctly is harder and requires investment. You need a budget of at least \$10k to pull it off, because a lot of them won't work.
The first step is mass DMing them. Send at least 100 DMs a day. Most won't respond. Make sure your message starts with "Paid Promo Opportunity" or something similar to cut through the noise. Make your message short and concise.
You can't just reach out to any influencer. They need to actually be in your niche or speaking to your customers. They need good engagement rates. Look at the comment section.
Are most of the replies fire emojis? Do people actually care about this creator? The best influencers have an audience that deeply cares about them. Look for that.
Never disclose the deal through DMs. You'll give them a chance to think it through and get a worse deal for you.
Instead, get them on a call as soon as possible. If you can't, send the deal through text to their phone number.
You should be looking for a deal as close to \$1 CPM (cost per thousand views) as possible.
A clean structure: start them on a "trial" deal at $1 CPM for 300k views with 40% upfront, then move to a $1.2 CPM deal after that.
### UGC Creators
Widely considered the best way to scale mobile apps right now. You hire micro influencers or new creators to make new accounts that produce content just for your app.
Having a successful UGC army is significantly harder. You have to make sure creators make the right content for your brand, check in on them constantly, track their performance, hire new creators, fire them fast, pay them. It's a complex process.
For this reason we wouldn't recommend new builders try to build a UGC army unless you already have experience with distribution or a co-founder. A UGC campaign will take most of your time and is a full-time job on its own.
That said, if you can make it work, you'll have an edge most builders don't, and a skill that compounds for the rest of your life. UGC campaigns are the highest-leverage distribution channel in mobile, and the hardest to get right.
The first step is similar to influencers: mass reach out. But you're looking for slightly different things.
With influencers you mostly want to reach out on Instagram and email. With UGC creators you mainly want to reach out through TikTok or UGC marketplaces.
Followers don't matter at all. Instead, look for creators with 2–3 viral videos, camera charisma, and strong communication skills. UGC campaigns are more about taste and viral sense than anything else. That's what makes them so interesting and so hard at the same time.
### Paid Ads
Apps have gone from $2.5k/month to $25k/month with this distribution strategy.
Most people completely overlook ads. They either start them too late or too early.
We left this distribution channel for last on purpose, because you shouldn't be starting out with paid ads.
Ads do best when you already have organic content that worked for you before. That content could come from your own posts, your influencers, or your UGC creators.
Make sure you already have a content system in place before you jump to ads. You don't need much. Only 5 high quality pieces of content a week to start testing.
By high quality we don't mean highly produced or edited. We just mean content that's already working organically.
Don't make super vague posts that convert through the comment section. Your ads need to be "Organic Ads": posts that have a genuinely organic hook and make the user feel like this is an actual organic video, but with a clear and direct CTA.
Paid ads are the only distribution channel on this list you should not start before you truly nail your onboarding. You need at least a 10% download-to-trial conversion rate to run them successfully.
Which takes us to the next step in scaling your app to \$25k/month. Once you have a content engine running and you've partly solved the top of your funnel (meaning you're getting at least 300 daily downloads), you now need to go back to the product.
You're not going to add new features. You're not going to optimize retention. You're going to completely obsess over your onboarding.
## Step #3: Obsess Over Your Onboarding
Your onboarding is without a doubt the most important part of your app. If you're reading this and still haven't shipped, try to get this right the first time around. Don't wait.
The only reason we mention it as the third step is to push you to get your hands dirty with marketing as soon as possible.
Here's everything that matters when designing your onboarding. Follow these and you will get a strong conversion rate.
* Think of your onboarding as a story with three acts: an introduction that paints the problem, a climax where the user experiences your app, and a conclusion that prepares them for the paywall.
* Don't design your onboarding from scratch. Study the best onboardings in your niche and outside it, find what works, and make it your own.
* You need at least one aha moment, a screen that stops the user in their tracks and makes them feel the weight of their problem. It should hit within the first minute.
* Most founders use onboarding questions to learn about their users. The real purpose is the opposite. You want the user to reflect on their own answers and slowly convince themselves they have a problem worth solving.
* After every few questions, mirror the user's answers back to them so they feel like the experience is being built specifically for them.
* The longer your onboarding, the better it converts, as long as every screen is adding value. People hate losing something they already invested in, so after 10 to 15 minutes in your onboarding, they'll think twice before leaving at the paywall.
* Let the user actually use your core feature during the onboarding. Don't just describe what the app does. Make them do it.
* Show your review modal right after the user completes your core feature, when they are at their most excited. This is the most important thing you can do for your ASO and social proof. Most users will not pay, but they can still leave a review, and that review compounds over time, bringing you more organic downloads for free.
Don't do anything else at this point other than getting your onboarding right. Iterate until your conversion rate is good enough. We'd say at least 10%.
## Step #4: Scale and Iterate Product
By this point you have a good app, a strong onboarding, and a pretty good distribution system.
You are now ready to scale and take your app to \$50k/month and beyond.
At this stage you're mainly focused on scaling your distribution system: more ad spend, more UGC creators, more influencers, more self-made content.
As you scale your marketing efforts, you'll get a lot of user feedback. Now is finally the time to improve the product. Don't bloat your app with features. Be very deliberate about what you're adding and why.
Make data-driven decisions. Don't add features on a whim. Only what's necessary.
Try to always optimize back to a revenue event. For example, instead of adding a useless feature, try to increase your trial-to-conversion rate (if you have a trial).
You should still be spending 90 to 100% of your time on marketing.
## Putting It All Together
That's the playbook. This is everything you need to scale your app to \$50k+/month.
Is it easy? It depends. How fast can you obsess over marketing?
Is it simple? Yes. There's no room for you to fail if you follow these steps.
You might fail your first few attempts. That's okay. The builders who eventually hit \$50k/month often went through 10 apps to find their first successful one.
The key is to obsessively focus on one app and on one thing at a time.
Mobile apps are in their golden era.
It doesn't matter if you know nothing about marketing. It doesn't matter if you're not technical. It doesn't matter if you have no money.
The builders making \$50k/month right now started exactly where you are.
The playbook is here. The tools are here. Start shipping.
# The 7 Ways to Scale Your App
Source: https://docs.rork.com/rork-playbook/seven-ways-to-scale-your-app
The 7 ways to scale your app, broken down in detail with case studies from some of the most successful app founders in the space.
Rork made shipping apps easy, so today, anyone can build a mobile app now. So in this article, we will break down in detail the 7 ways to scale your app based on case studies of some of the most successful app founders in the space.
Apps are the only business in the world that doesn't require any fulfillment; you build it once, and you can sell it forever.
So once your app is built, your sole focus should be 100% on marketing.
## #1. Scale with Faceless Content
A lot of people will tell you this is not effective, but we disagree.
We know founders who have scaled to over \$50k/mo+ with just faceless reels. A great example of this is seen in the looksmaxxing niche, where people are literally just making edits, or before and after content of other people, or guides, like in the example below.
The slideshows usually include a CTA to their app to get a looksmaxxing score. This is how apps like UMAX scaled to over \$100k/mo.
And of course, this is not only credited to faceless content, but the founders of UMAX themselves said that their first \$30k+ in revenue came from 2 faceless posts from Instagram theme pages.
We have spoken to another founder in this niche doing over \$50k/mo with an army of faceless content creators as well.
And this can work across any vertical: cooking niche, looksmaxxing, gym apps. Easy to make and easy to scale.
## #2. Scale with Influencers
This one is super straightforward. It was one of the main methods Cal AI used to scale to 3.6M views, aside from paid ads.
Find influencers that fit your niche, negotiate a good deal, and you will instantly be able to put your app in front of millions of eyeballs. For example, below is a cooking influencer who is averaging 200-300k views per video, plus the occasional banger with 4.4M views.
This is the beauty of influencers: they are already viral. They already know what content works for their audience. And if you can get a video with an influencer that gets 4.4M views, you will literally make over $20k-$40k from that video alone, as long as the CTA is good.
This is truly one of the best ways to scale your app if you have initial capital to invest.
To find influencers:
* Create a branded account for your app
* Post at least 9 reels relative to your niche.
* Add what the app does in the description.
* Add a link to your app.
* Add a logo as the profile picture.
* DM 100 influencers per day across TikTok and Instagram (volume matters a lot).
* Ideally, your outreach account should have over 10,000 followers.
* If not, use your own personal account and get the verified badge on Instagram (\$15/mo). This will make your DMs more visible. Otherwise, it's like speaking to a wall.
You should lead with a DM template. A good DM you can send to influencers massively improves your chances of getting a response:
Once they answer, try to negotiate with them on a $1 to $2 CPM, always capped at $1,000 USD. This protects you from a $10k invoice while you also maximize your results based on performance.
Once they sign the contract, just ensure you stay in close daily communication with them and push them to get videos out. Sometimes influencers need a little push. Your job is to review every video and ensure it has a strong CTA, because if they go viral and the CTA is bad, you are just wasting your money. But if the CTA is good, you can 2-5x your investment.
## #3. UGC (User Generated Content)
This is honestly just as good as influencers, if not better.
UGC is basically when you hire creators and have them create a new account on TikTok and Instagram, then do 30 to 60 videos a month per creator.
The common pay structure is $10 to $15 per video, plus performance bonuses when the videos actually go viral:
* 100k views = \$150
* 250k views = \$250
* 500k views = \$600
* 1M views = \$1,000
There's no CPM; the bonus is only unlocked once those view thresholds are hit. And yeah, a creator can make up to $1,015 on one video, but if your app is good and your onboarding cooks, 1M views will make you a whole lot more than $815.
UGC is actually a lot more affordable than influencers. Now, unless you have the capital, we don't recommend doing more than 1-3 UGC creators at once when you are starting out, because it's hard to find a format that works, and most UGC campaigns end up not working out.
That said, if you have a format that works for your niche, this is when it makes sense to have 10-20 UGC creators making content every day. Otherwise, hire 1-3 to help you find that format that works, and once you crack it, scale up the team.
And since your bonus structure is cheaper and your cost per video is a lot lower, you can blow up your app with millions and millions of views at a fraction of the cost.
This is the best case scenario for UGC, and it's what some of the most successful apps in the space used to scale to over \$400k/mo with their app.
## #4. Founder-Led Content
Founders have done this and generated millions of views. It's really not that hard.
You pick up the camera and film content yourself. It's good if you have no budget starting out, and even if you do have the budget, it's good to be at the forefront of all your creator campaigns. You can find viral formats quicker and feed those to them.
You can start by replicating viral videos in your niche. The key when replicating a viral format is to really replicate everything: the music, the length of the video, the pacing, the vibe. Virality is not luck, it's engineered, and every second of the video matters.
The founders of Push Scroll, for example, have scaled their app to \$100k/mo with founder-led content, plus running those videos as ads, and of course also using a combination of the other methods mentioned in this article.
Founder-led content also builds the viral sense in you. When you are making content yourself, you start to understand what hooks work. And once you have that understanding, you can teach it to your UGC creators and influencers.
You can write better briefs, give better feedback, and spot a bad video before it gets posted, which makes every other channel on this list work 10x better.
This is how some of the best founders operate.
## #5. Paid Ads (TikTok and Meta)
Out of every channel on this list, paid ads are probably the most powerful. All the apps previously mentioned in this article run ads. If you want to scale, you cannot ignore ads.
The reason is simple: once you find a creative that converts and locks in a profitable CPA (cost per acquisition), you literally have a money-printing machine.
This is also why every other channel on this list matters so much. UGC, influencers, faceless, founder-led, all of those are essentially feeding the paid ads machine. If a video popped off organically, it has a very high chance of popping off on ads too.
Paid ads are pretty much the only channel that can keep your app at a baseline. Say you scaled to $50k/mo because you had a good organic month, and next month you made $20k/mo because you had a bad organic month. Paid ads prevent this by keeping you above a baseline, and in many cases, help you scale way beyond that baseline.
A good starting budget is $50-$100/day. Pour in as many creatives as possible and let the algo decide.
Once you get a profitable CPA on your ads and make at least a 1.2x to 2x profit on your ad spend, increase your budget by 25% every week. That's how you run profitable ads.
## #6. Reddit Marketing
Reddit is one of the most slept-on channels for app founders. People sleep on it because it's harder to track, but the traffic is insanely high intent.
The play is simple: find subreddits that match your niche and become a real member first. Don't just spam your link day one, or you will get banned in 5 minutes. Comment, post, build some karma, then start dropping value posts that subtly mention your app or include it in the comments.
Reddit loves a good founder story, especially in subs like r/SideProject, r/Entrepreneur, r/InternetIsBeautiful, and any niche-specific sub for your app.
Another play is to answer questions on Reddit, where people are literally asking for the solution your app provides. Search "best app for X" inside Reddit, and you will find dozens of threads waiting for a link drop.
Founders are pulling in thousands of free downloads per month from Reddit alone. Just don't be salesy, Reddit hates that. Lead with value, always.
## #7. Partnerships
This is basically influencer marketing all over again, except your pitch is not to pay influencers per video, but to give them 20 to 50% of your app in return for them becoming partners of the app altogether and getting a share of the revenue.
The only thing to be cautious of here is who you partner with. Jump on a call with them, weigh a couple of options. Who you partner with can make or break your app's success.
## Putting It All Together
And that's how you market your app after it's live on the App Store!
Feel free to drop any questions below, and follow [@rork](https://x.com/rork) for more value every week!
You can also build your app end-to-end and ship to the App Store at [rork.com](https://rork.com/).
# Posting Organic Content
Source: https://docs.rork.com/rork-playbook/untitled-page
Guide to organic content
Organic content is a powerful way to validate your idea or product. It is also a great way to evaluate the effectiveness of your Gotcha Moment.
You should be able to generate a noticeable amount of views based solely on your app's key functionality.
[https://www.instagram.com/reel/DLdT4Niu25w/?utm\_source=ig\_web\_copy\_link\&igsh=MzRlODBiNWFlZA==](https://www.instagram.com/reel/DLdT4Niu25w/?utm_source=ig_web_copy_link\&igsh=MzRlODBiNWFlZA==)
[https://www.tiktok.com/t/ZP8UHME7v/](https://www.tiktok.com/t/ZP8UHME7v/)
Both of these posts simply demonstrate what the app does. The TikTok video initially received ten thousand views organically and generated around one hundred dollars. After boosting it, the promo spend brought in no additional money.
# **Why Each Organic Video Worked**
## **Instagram**
It had a humorous spin on the functionality of the app. The caption included a call to action, which significantly boosted engagement. This was pre-launch, so the caption said "comment the word 'BETA' to get early access". This also showed that the "gotcha" moment captivated people enough to comment to get early access.
## **TikTok**
It had a decent hook and a slightly dramatic tone. It also clearly showed passion for the product and conveyed authenticity in how it was presented.
# **Pros**
If executed well, organic content can build a strong, almost cult-like following for free
# **Cons**
You need to be skilled at creating this style of content. Many founders are not great at it, but they are very good at directing influencers on what to post. With all marketing channels, you should play to your strengths and your app's strengths. Organic content can also be inconsistent in performance.
# Winning influencer creatives
Source: https://docs.rork.com/rork-playbook/untitled-page-1
How to run profitable influencer marketing
# **Understand the Type of Content in Your Niche**
Spend a decent amount of time scrolling on a fresh account that mimics your target user. Your goal is to analyze what type of content in your niche works and what does not. This helps you understand what resonates with your audience and what they naturally engage with.
# **Understand Your Value Proposition**
Every consumer app should have a "gotcha moment". This is a feature that grabs attention and compels someone to stop scrolling and go to the App Store to download your app.
Examples:\
Cal AI uses its photo calorie tracker\
Quittr uses the panic mode\
UMax uses the face rater
These features are compelling because they either solve a problem uniquely or provide personalized feedback that can only be experienced by using the app.
At least 50 percent of your time building the app should be devoted to creating and refining the "gotcha moment". Make it visually impressive and very easy to understand. Influencers will typically show your app for 10 to 15 seconds. In that short window, the user must clearly see the benefit of downloading your app.
# **Influencer Posts**
The content should not feel like an ad. It should feel like the influencer is a genuine user of your app.
\
**How to make influencer content feel real (not like an ad)**
1. **Study Their Content**\
Watch their last \~20 posts and note what *actually performs*: tone, humor style, editing pace, emotional vibe.
2. **Use Their Best Format**\
If they kill at "Day in the life," put your app there.\
If they crush "routine" videos, put them there.\
Don't force a new style on them.
3. **Make the App a Moment, Not the Topic**\
The app shows up naturally *while they're doing something*, not as a standalone pitch.
4. **Keep Their Voice**\
Same language, same energy, same personality, just with your app inserted into their real life.
5. **The Influencer is the Hero! The App is a Tool**\
They're not promoting it…\
They're using it.
### \*\*How to apply your app in different formats: \*\*
• **Day in the Life:** The app appears as a natural part of their daily actions. Example: they show your app during their morning planning or when solving a problem.
• **Routine Videos:** The app becomes part of a habit. Example: "Every night I do this" or "I always check this before training."
• **Educational or Tip-Based Content:** The app becomes a recommended tool. Example: "One thing that helps me is using this to stay on track."
• **Comedic or Skit Content:** The app is used as a comedic prop or the punchline. Example: "I physically can't open my phone until I finish my task, look." (Don't be afraid to make fun of the product in good fun)
• **Before/After or Progress Videos:** The app is the quiet reason for improvement, not the focus. Example: "Using this consistently helped me change X."
• **Motivational or Storytelling Content:** The app supports their personal growth story. Example: "I used to struggle with this, so I started using this tool."
• **Q\&A or Replying to Comments:** The app is the answer to a viewer's question. Example: "People always ask how I stay focused. Here's what I use."
Choose the format that already gets strong engagement from their audience. Instead of forcing the influencer into a new style, you plug your app into the creative rhythm and tone that already works for them.
Get a feel for the influencer's voice and what works well on their account. Then integrate your app into that format naturally and seamlessly.
# **Case Study**
[https://www.instagram.com/reel/DQWonVYDnpV/?utm\_source=ig\_web\_copy\_link\&igsh=MzRlODBiNWFlZA==](https://www.instagram.com/reel/DQWonVYDnpV/?utm_source=ig_web_copy_link\&igsh=MzRlODBiNWFlZA==)
This video cost seventy dollars and generated close to three thousand dollars.
Interestingly, this was not even the most optimized ad.\
Two products were being advertised\
The app did not appear until around 30 seconds
Despite that, it performed extremely well because the "gotcha moment" clearly demonstrated what the app does and how it benefits the user. Even with two products featured, the influencer made them feel like natural parts of his day instead of interruptions.
"Day in the life" content is especially effective for apps like Cal AI or a sports coaching app because it allows the app to feel real rather than promotional. It also subconsciously associates your app with productive and disciplined people. The viewer absorbs the message that productive people use your app, or that your app makes people more productive.
# **Meme Pages or Topic Pages**
This is a very cost-effective marketing channel for generating views. Have these pages repost your best-performing content.
Entertaining or funny content related to your app typically works best. You should not pay more than fifty dollars per post. CPM should be in the range of fifty cents to one dollar.
The best meme pages have almost cult-like communities built around them.
# **Case Study**
[https://www.instagram.com/reel/DL5dp26S2dP/?utm\_source=ig\_web\_copy\_link\&igsh=MzRlODBiNWFlZA==](https://www.instagram.com/reel/DL5dp26S2dP/?utm_source=ig_web_copy_link\&igsh=MzRlODBiNWFlZA==)
The founder paid a kickboxer three hundred and fifty dollars to film himself using the app and then reposted it on the meme page above. This helped the app grow from five hundred dollars a month to eighteen hundred dollars a month in its first month.
They were willing to lose money for that collaboration because it gave the app credibility. Posting a professional athlete using the app signaled legitimacy.
They reframed the content as a "news headline" to make it feel less like an ad. However, viewers immediately recognized it as a sponsored post and commented about it being an advertisement. Although they intended to criticize it, the high number of comments drove engagement. As a result, it became the most viewed reel on that page for that month.
Normally, content should not feel like an ad. However, all rules in marketing can be broken when engagement is the result.
# Finding Influencers and negotiating with them
Source: https://docs.rork.com/rork-playbook/untitled-page-2
How to find and negotiate profitable deals with influencers
# **Influencer Outreach & Deal-Making Strategy**
*A streamlined guide for finding, contacting, and negotiating with creators.*
## **Finding Prospective Influencers**
### **Method 1: Organic Feed Engineering**
Create a new social media account and use it as if you were your target customer:
* Like the content they would like
* Watch the same types of videos all the way through
* Interact naturally
This trains the algorithm to show you influencers who reach the users you want.\
This method takes longer, but every influencer you find will be highly relevant and a quality prospect.
### **Method 2: Outsourcing Through a VA**
1. Create a set of criteria:
* Minimum & maximum follower count
* Average views on recent videos
* Likes and comments per post
* Posting frequency
2. Define hashtags that your target audience would interact with
3. Use Upwork to hire a virtual assistant
4. Have them run outreach using your account
5. Pay approximately **\$5–\$15 per 100 DMs sent**
\*\*Example of what information to give to your VA: \*\*[**https://docs.google.com/document/d/1ao6EHLSevWQrnRmRFSCPjIRCoWDRcOu\_/edit?usp=drivesdk\&ouid=113359815720101867056\&rtpof=true\&sd=true**](https://docs.google.com/document/d/1ao6EHLSevWQrnRmRFSCPjIRCoWDRcOu_/edit?usp=drivesdk\&ouid=113359815720101867056\&rtpof=true\&sd=true)
This method gives volume, but it will flood your dm inbox with unqualified leads. It happens, as long as you're able to sift through who's quality and who's not.
## **Setting Up a Professional Outreach Account**
1. Create a new dedicated account
2. Bio should clearly communicate:
* Who you are
* What you're building
* Select apps/products you've created (if any)
3. Optionally, post a few portfolio items
* Either lifestyle (people tend to respect people who appear successful. Not every founder likes this, but it's a strategy.)
* Things you've built
* Nothing (won't kill your response rate as long as you do the next two bullets)
4. Have at least 5k followers for your Instagram; people don't want to be sponsored by nobodies. When someone has 5 followers, they distrust the account. When you have at least 5k followers, you seem more reputable
* You can do this through Upwork or various websites
5. Pay for an account verification (\$11.99/month)
* This is another easy way to stand out in their inbox
The goal is for them to see:\
"You are a real builder/company, not a scam or spam account."
## **What type of influencer to reach out to:**
Green flags:
* **25k+ views per video**
* **A stable amount of views never dipping under 15k**
* **Content does well on multiple platforms**
* **Has a unique style of content. You don't want to sponsor someone who's just trend hopping or engagement farming. You should be able to quickly understand why the internet resonates with them**
* **Comments show an engaged community**
Red Flags:
* **Inconsistent views, some videos at 100k+, others around 5k**
* **Trend hopper. Just copies popular sounds and doesn't feel distinct.**
* \*\*Comments are a bunch of emojis. You typically see this on Instagram the most. This shows low-quality viewers or fake engagement. \*\*
* **A lot of views but no comments, people "like" the content but are not engaged enough to take the time to comment. If they don't take the time to comment, they may not take the time to download your app.**
Remember: **followers don't matter**! Only **views & engagement** do.
## **Crafting the Outreach DM**
Your message should be short and instantly clear.
### **Structure:**
**1. The first two words:**\
"Paid promo?" (or similar)
They get a ton of DMs a day saying, "Hey, I love your content". The best way to get a response is by mentioning that they will get paid if they respond to you.
**2. One-sentence explanation of the product**\
Who you are & what your app does. Don't go overboard; you'll explain more to them later. Just give them enough to understand what you're doing, but not overboard to keep them curious.
**3. Clear invitation**\
"I'd love to sponsor you!"
### **Example:**
**"Paid promo for Arc? Hey, I run an app that limits screen time and unlocks usage when goals are completed. I love your content and would love to sponsor you! Let me know if you're interested."**
They will not read a mile long dm explaining everything, and they get a 1000 of dm's, but they will respond if they know you will pay them.
## **Negotiating Deals**
### **Over Text**
Creators will often respond with:
* "Sure, tell me more."
* "Sounds good, what's your budget?"
**Do NOT give payment numbers over text.**
If they say, "tell me more"\
\
Say: "Absolutely, I'd love to hop on a call and walk you through the integration and how we see this working. Here's my number: (xxx-xxx-xxxx)."
If they directly ask for a price:\
"Before we get into numbers, I'd like to show you what we want demonstrated in the video."
**Don't give them a number unless they force you!**
A couple of tips:
* Dm as little as possible. Every dm should be guiding them to get on the phone and closing a deal
* Remember you're the one paying them, not vice versa!
## **On the Phone**
### **Opening the call:**
* Start with a friendly tone
* Compliment a specific aspect of their content. Be hyper specific, it will not only be a much better comment, but they will associate you as a fan of their content and make them more likely to give a better deal.\
("I'm actually a big fan lol, I loved watching your XYZ series", etc.)
This shows you're familiar with them as a creator, not just mass-blasting DMs.
### **Explain the integration:**
* Describe how the app will appear naturally in their content
* Share examples or past influencer videos
* Provide visual assets if needed
### **Discuss rates**
Ask:\
"What do you feel is a reasonable rate?"
Then you determine value by their average view count:
* Take average views
* Underestimate conservatively
* Multiply by the number of videos
Example:\
They average 25k views/video\
You want 4 posts\
You conservatively project 100k total views
You offer:
* \$250 for 4 videos (\$2.50 cpm multiplied by the minimum view guarantee)
* With \*\*a minimum view guarantee \*\*of 100k views
* You should've underestimated enough, so they are very confident that they will hit the guarantee.
* Pay 50% up front / 50% upon 4 videos completed, and a minimum view guarantee is met.
* If they don't hit the guarantee, offer them the ability to keep posting until they do.
If they say it's too low:
* Move to \$350
* OR propose a CPM model:
**\$2–\$5 per 1,000 views**\
With a cap at historical max performance\
(e.g., max \$500 payout if one goes viral)
Present CPM as:\
A chance for them to bet on themselves. Don't directly say that, but it should be naturally implied.
For example:
Influencer: "I think \$350 for 4 videos is too low for me. Is there any way you can come higher?"
You: "I mean, I really have to keep in the \$2-\$3 cpm range. (pause) I mean, what I could do is pay you a rate of \$3 per thousand views, so if 4 videos generate a total of 200k views, I could pay you a total of \$600, but there would have to be a cap of \$500 per video."
This now switched their frame from the idea of earning \$350 for 4 videos, to the idea of potentially earning \$2000 for 4 videos, if they do really well. If you start off with a cpm proposal, it will feel like you are trying to bait them into a commission deal, which most influencers won't go for. When you do it like this, it makes them feel like they opened the opportunity to earn a lot more, even though you just negotiated almost a risk-free deal because you should be very profitable in a \$2-\$3 cpm range.
### **After you present your offer:**
Stop talking.
You are the buyer.\
They need the sponsor as much as you need the promotion.
## **Tactics to motivate them to take the deal**
During the call, make sure to mention that you are only focused on **long-term partnerships**, not one-off posts. You're going to say this for two reasons. **One, it's how you're going to scale.** Recurring posts will raise your floor revenue every week. If you're guaranteed almost a certain amount of views a week, it will make growth consistent. Two, most influencers have done some one-off deals that paid them well, but never gave them a consistent way to monetize their content.
Be extremely passionate about what you're building. Naturally, they will mirror your enthusiasm and commitment. Also, people follow missions; they love working for companies that they believe are out there to deliver the best experience for the customer.
## **Common Objections & Responses**
### **"XYZ brand paid me thousands for a post."**
Response:\
**"Are you still working with them?"**
After you say this, you will close this deal. Big brands spend thousands of dollars on influencers who don't perform for "brand awareness," but because the posts don't do well, they don't continue working with them. Once you ask, "Are you still working with them?" They will most likely say no, and then you will go on to explain how you want to build a long-term partnership, not a one-off post.
### **"Sponsorship content hurts engagement. So I won't do a minimum view guarantee."**
Response:\
"That's why we don't want a typical ad. We want a subtle integration into your content that already performs well. In fact, our best results come when content looks authentic, and people naturally comment about the app. Not only that, but a lot of our influencer promos perform better than their average video, because they have people commenting about our app."\
\
Only say the last sentence if it's true.\
\
**After the influencer posts:**
Moderate your analytics. This deal should be profitable in 1-3 days, depending on your trial length.
Plant comments in the comment section. Have a couple of your friends commenton a question about the app.
* This will make people more interested in your app because they will see other people interested.
Also comment from the company account, this way if a user is not ready to convert or download the app. It can act as a funnel to your account.
A viewer watches an influencer's post → clicks on the comments and sees your account → decides to watch a few videos on your account → now they go and download the app and are very educated about what your app/primed to convert.
# Onboarding and Monetization
Source: https://docs.rork.com/rork-playbook/untitled-page-3
How to make money from an app: onboarding into a paywall, what to charge, and how to test your pricing.
# **How to Make Money Through Apps**
The simplest way to start monetizing an app is by making it pay-to-access. The user will go through an onboarding process and, at the end of it, they'll hit a paywall.
When setting your pricing, you should experiment. But a good rule of thumb is:
* If there are existing competitors, copy their pricing.
* If your app is unique or there are no direct competitors, use your intuition.\
A structure that works well for many builders: **\$9.99/month or \$59.99/year**, with a **3-day free trial attached to the yearly plan only.**
This pricing structure encourages users to choose the annual plan, increasing upfront cash flow.
# **What Onboarding Actually Is**
Onboarding includes everything that happens before the paywall.\
This stage should:
* Educate the user about your app.
* Tailor the experience to them.
* Build desire and justification for why they need it.
The best way to create strong onboarding is by studying successful apps (Cal AI, Quitter, etc.). Borrow the strategies that work and adapt them to your product.
# **My Recommended Onboarding Format**
### **1. Educate the user**
Show quick 3–5 second visuals demonstrating each major feature of your app. Show how the app works, people won't want to pay if they don't know what the app does.
### **2. Personalize the experience**
Ask the user for their name and refer to them personally throughout onboarding.\
Then prompt them with questions that lead them to the problem your app solves.
Example from Cal AI:\
"Have you tried other weight loss apps in the past?"\
If they answer yes:\
"Here's why we're different from traditional calorie trackers."
### **3. Use sunk-cost psychology**
Draw out the personalization process just enough that the user feels invested. However, not too much where the user gets bored and clicks off the app. The more time they spend setting up the app, the more compelled they are to pay at the paywall.
### **4. Tie their goals to the app**
Ask them for their objective related to your solution.\
Example (Cal AI):\
"What is your weight-loss goal?"\
Then, visually show a roadmap:
* Their journey **without** your app\
vs.
* Their journey **with** your app
This creates a clear internal logic:\
**"This app accelerates my progress."**
### **5. Lock the final deliverable behind the paywall**
For apps that analyze data or media (like athlete-training apps), the user uploads a video during onboarding.\
Once it finishes uploading, they see:\
"Profile complete."\
Then they finally get to the paywall.
They've already gone through creation, personalization, and emotional investment.\
Now they're primed to convert.
# **Study Other Apps**
One of the most valuable things you can do is spend 1–2 hours downloading successful apps in your space and studying their monetization experience. Notice where you feel compelled to buy and why.
There is no perfect formula:
* Test,
* Iterate,
* Get creative,
* And have fun with the process.
# Helpful Resources
Source: https://docs.rork.com/rork-playbook/untitled-page-4
Outside reading we recommend on paywall design, onboarding, influencer marketing, and App Store optimisation.
* Full App Mafia video course: [https://whop.com/joined/appmafia/app-mafia-updates-E1s6kcqVuHltzd/app/|](https://whop.com/joined/appmafia/app-mafia-updates-E1s6kcqVuHltzd/app/|)
* Paywall design: [https://apphud.com/blog/design-high-converting-subscription-app-paywalls#conclusion-good-paywalls-are-built-not-just-designed](https://apphud.com/blog/design-high-converting-subscription-app-paywalls#conclusion-good-paywalls-are-built-not-just-designed)
* Cal AI onboarding:\
[https://screensdesign.com/showcase/cal-ai-calorie-tracker](https://screensdesign.com/showcase/cal-ai-calorie-tracker)
* The power of influencers: [https://www.forbes.com/sites/debgordon/2022/12/20/33-of-gen-zers-trust-tiktok-more-than-doctors-new-survey-shows/](https://www.forbes.com/sites/debgordon/2022/12/20/33-of-gen-zers-trust-tiktok-more-than-doctors-new-survey-shows/)
* ASO guide: [apptweak.com](http://apptweak.com)
[https://www.apptweak.com/en/aso-blog/topic/start-aso](https://www.apptweak.com/en/aso-blog/topic/start-aso)
* Onboarding examples: [https://userpilot.com/blog/onboarding-ux-examples/](https://userpilot.com/blog/onboarding-ux-examples/)
# Reply to App Store reviews
Source: https://docs.rork.com/store-guides/app-store-reviews
Your App Store ratings and written reviews arrive inside the Rork project. Rork tells you when a new review lands, and the agent drafts and posts your public developer response after you approve it.
Once your app is live, people rate it and write about it. Those reviews arrive in your Rork project, next to the build that shipped. You read them there, and the agent writes the public reply for you. Apple calls that reply a developer response, and it shows under the review on the App Store.
You do not open App Store Connect for this. Rork already holds the App Store Connect access from your first submission, so the reviews and the replies both run through the project.
## Where the reviews live
Open **More** in the project, then **App Store**. The section has two tabs: **App Review** for your submissions, and **Ratings** for what customers say.
**Ratings** appears only when the app is live on the App Store. Before that the panel says **Ratings aren't available yet**, and adds that they show up after the app is published.
## Read the numbers first
The top of the tab summarises the account: **Average rating** out of 5, the number of total ratings, and a **Rating breakdown** from 5 stars down to 1. **View on App Store** opens your public listing.
Three counters follow, and the third one is the one to watch:
| Counter | What it counts |
| - | - |
| **Written reviews** | Reviews with text, not plain star ratings. |
| **New this week** | Reviews from the last seven days. |
| **Needs response** | Reviews with no developer response yet. |
## Find the reviews that need an answer
Three filters sit above the list. Set the response state to **Needs response** and you see only the open ones.
| Filter | Options |
| - | - |
| Rating | **All ratings**, or one value from **5 stars** to **1 star** |
| Country | **All countries**, or one store territory |
| Response state | **All responses**, **Needs response**, **Responded** |
**Refresh reviews** pulls the list again from App Store Connect. The list shows 25 reviews at a time, so use **Previous** and **Next** for older ones. When a filter matches nothing the panel says **No matching reviews**, and suggests changing a filter.
Each row carries the review title, the stars, the reviewer nickname, the date, and the country, then the text. After you answer, the row keeps a **Your response** block with your reply, its state, and the date it changed.
## Get told when a review arrives
Rork checks App Store Connect for you and files a notification called **App Store review** when a new one lands. The notification quotes the review and names the reviewer and the country. A review of 1 or 2 stars is marked as a warning, so a bad rating does not sit unread for a week.
Press **View review** on the notification. Rork opens the project on the **Ratings** tab and scrolls to that exact review.
## Reply with the agent
You write nothing by hand. Ask in the chat, and the agent handles the App Store side.
```
Show me the App Store reviews that need a response
```
The agent lists each review with its rating, title, text, reviewer nickname, country, and date, so you judge the case before any reply exists.
```
Draft replies for the 1-star reviews from this week. Do not post them yet.
```
The agent writes a short reply per review and shows you the exact text.
A developer response is public, so nothing is posted until you say yes. Change the wording in the chat until it reads the way you want.
```
Post that reply
```
The agent publishes the response and reports back its state. The review then shows **Your response** in the list.
Ask for drafts only, and the agent stops after showing them. That is the safe way to see what it would say before you trust it with the store.
## Answer many reviews at once
Several reviews often say the same thing, for example that a paywall arrives too early. One reply text can cover all of them.
```
The 1-star reviews all complain about the paywall. Write one reply that fits them
all, show me the list, then post it.
```
The agent groups the reviews under one response text, shows you the plan, and runs it dry first. Only after that does it post, and it skips any review that already has a response. If a review fails, the agent names it and says why.
## What makes a good response
The agent follows the rules Apple reviewers and readers expect, and it helps to know them, because you approve the text:
* Short, specific, and about the feedback in that review.
* No promotional copy, no discount codes, no internal links.
* No private customer data, and no blame.
* It never asks the person to change their rating.
* It promises a fix, a version, a refund, or a date only when that is true.
## What this cannot do
* Ratings arrive only after the app is live on the App Store. TestFlight feedback is separate, see [TestFlight: put your app on real phones](/store-guides/testflight-beta-testers).
* Apple allows one developer response per review. Rork treats a review that has one as handled, so say so plainly when you want an answer replaced.
* The reply is public. Anyone reading your listing sees it under the review.
* This tab covers the App Store. Google Play reviews stay in Play Console.
* A project with no App Store submission has no reviews to read, and the **Ratings** tab stays hidden.
## FAQ
The app is not live on the App Store yet. Submit it and pass review first, see [Publish Your App to the Apple App Store](/store-guides/publish-app-store).
No. The agent shows the exact response text and the review it targets, then waits for your approval.
No. Rork uses the App Store Connect access from your submission, so reading reviews and posting replies both happen in the project.
Rork syncs from App Store Connect on a schedule and notifies you when a review lands. Press **Refresh reviews** when you want the list pulled again right now.
Yes. Ask for the reply in the language of the review. Say which language, and the agent drafts it there.
They are not in this tab. Answer those in Play Console. Rork does handle the Play release itself, see [How to publish your Rork app to Google Play Store](/submitting-to-play-store/creating-the-aab-file).
Paste it into the chat and ask for the fix. The agent reads your code, changes it, and you ship a new build, see [Publish Your App to the Apple App Store](/store-guides/publish-app-store). Mention the fix in the reply only after the build is out.
## Next steps
The submission flow that gives Rork its App Store access.
Catch the rejection risks before Apple does.
Collect feedback before the public sees it.
Installs and revenue next to the reviews.
# Create your Apple Developer Account to publish to App Store
Source: https://docs.rork.com/store-guides/apple-developer-account
This guide will help you get your Apple Developer account setup to publish apps in the App Store.
In order to publish your apps to the App Store, you need to set up your Apple Developer account. If you need more information, check [the App Store Connect official page.](https://developer.apple.com/app-store-connect/)
> Join the Apple Developer Program to reach customers around the world on the App Store for all Apple platforms. Membership provides the tools, resources, and support you need to develop and distribute apps and games, including access to app services, testing tools, app analytics, and more. - Apple Developer Program
### 1. Start Your Enrollment
[Click this link and press start your enrollment to begin enrolling into the Apple Developer membership program.](https://developer.apple.com/programs/enroll/)
### 2. Sign in with Your Apple Account (or Create One)
You will be asked to sign in with your Apple account. You can use the same one you use if you have an iPhone, or you can create a new account.
### 3. Skip the customization of the profile
Once you've signed in, agree to the terms. You will then be asked to customize your developer profile. Please press **Remind me Later** or **Not Interested**. It is not needed for most use cases.
### 4. Press continue enrollment on the Web
It will ask you to enroll using the Apple Developer app, but right below that, you will see ***Continue enrollment on the web***. Press that so you can continue with ease.
### 5. Enter your Personal Information As Asked
Please enter your actual information here. This is important to get accurate, because Apple will use your account information when setting up payouts later.
### 6. Select your entity type
For most use cases, an **Individual/Sole Proprietor** is sufficient. Please select it and continue.
### 7. Review and Accept the Final Terms
### 8. Finalize your year of Apple Developer membership by paying the yearly fee (\$99)
## If all goes well, you will be able to log in to [App Store Connect](https://appstoreconnect.apple.com/) and see this page
You are now one step closer to publishing your apps to the app store!
# Create your Google Play developer account
Source: https://docs.rork.com/store-guides/google-play-developer-account
What you need before Rork can publish your Android app: a Google Play developer account, identity verification, and, for new personal accounts, a closed test with 12 testers for 14 days.
Rork builds your Android app and can send it to Google for you. What Rork cannot do is be you: the developer account, the identity checks, and the store listing belong to your Google account.
Set the account up before you finish the app, because Google's checks take days, not minutes.
## What Google asks for
Go to [Google Play Console](https://play.google.com/console/signup) and sign up with the Google account you want to own the app. Google charges a **one-time \$25 registration fee**, unlike Apple's yearly membership.
A personal account is you. An organization account is a company, and Google asks for business details to prove it exists. Pick the one that matches who will be paid, because changing it later is painful.
Google asks for your legal name, address, and a document to confirm them. Use details that match your bank, or payouts stall later.
A paid app or in-app purchases need a payments profile. A free app does not, so this can wait.
**New personal accounts have to run a closed test first.** Personal developer accounts created after 13 November 2023 need a closed test with **at least 12 testers opted in continuously for 14 days** before Google grants access to production. Internal testing does not satisfy that rule.
Plan for it. Twelve real people, opted in, for two full weeks, is the slowest part of shipping your first Android app.
## What Rork does for you
Once the account exists, publishing happens from the project. Open **Publish**, pick your Android app, then **Upload to Google Play**.
Rork can go the whole way:
1. **Build AAB for Play** produces the Android App Bundle Google requires.
2. **Connect Google Play** links the Google account that manages the app. Rork explains why: "Connect the account that manages this Play app. Manual AAB upload stays available."
3. Rork checks that it can reach your Play Console app.
4. **Send to Google Play** uploads the bundle. When it lands, Rork tells you exactly where it went: "Version 1 is in internal testing. It isn't public yet."
If you would rather do it by hand, **Download AAB for Play Console** gives you the file to upload yourself. See [How to publish your Rork app to Google Play Store](/submitting-to-play-store/creating-the-aab-file).
## What you still do in Play Console
Rork cannot create your store listing or accept Google's policies for you. In Play Console you:
* **Create the app** the first time. Rork walks you through it, including **Copy package name** so the listing matches your build.
* **Fill in the listing**: title, description, graphics, category, content rating, data safety, and the policy questionnaires.
* **Add testers** for your closed test, and share the opt-in link with them.
* **Send the release for review** when you are ready for production.
Google's review is usually faster than Apple's, but the first release of a new account takes longer because the account checks run alongside it.
## The order that works
1. Register the account and start identity verification. Do this first, on day one.
2. Build the app in Rork and test it on your own device. See [How to test Android apps on your Android device](/submitting-to-play-store/apk-file).
3. Create the app in Play Console, then let Rork send a build to internal testing.
4. Start the closed test with your 12 testers, and let the 14 days run while you finish the app.
5. Fill in the listing, then request production access and submit.
## FAQ
No. Install the APK on your own phone first. The account is for distribution. See [How to test Android apps on your Android device](/submitting-to-play-store/apk-file).
The rule targets personal accounts created after 13 November 2023. Check the current requirement in your own Play Console, because Google states it there for your account.
They have to be real Google accounts that opt in and stay opted in. Recruiting them is the work. Ask in the [Rork Discord](https://discord.gg/rxBHytVKaT), where founders swap testing.
Rork's automated route targets **internal testing**. Promoting a release to production is a decision you make in Play Console.
Yes, one per store. Apple charges $99 a year, Google charges $25 once. See [Create your Apple Developer Account](/store-guides/apple-developer-account).
## Next steps
Build the AAB and get it into Play Console.
Install the app before anyone else sees it.
The same job on the other store.
Which platforms your project should have.
# Publish Your App to the Apple App Store
Source: https://docs.rork.com/store-guides/publish-app-store
This guide will publish your Rork project to the App Store in minutes.
To publish your apps to the App Store, you need to set up your **Apple Developer account**.
We've made a step-by-step guide so you can quickly set up your account. [Please go here to do that and come back once that's finished.](/store-guides/apple-developer-account)
> Publishing an App through Rork is incredibly simple. Once you have your developer account, you just have to enter a few details about your app and submit it. This guide will go through each step.
## Watch an App Store submission
This example resubmits an existing app: sign in to Apple Developer through Rork, ask the agent for a new build, then submit it for review in App Store Connect.
### 1. Update Your Icon and App Name
Inside your app, we need to update your App Icon, Name, and Variables before we submit it to the App Store. Inside your project, click on the title on the top left of your project. This will open a window with your Project Settings.
Please update your **Project Name, bundle identifier, and App Icon** to whichever one you prefer. Once finished, **save your changes.**
**Generate a new App Icon directly in Rork**
You can ask your Rork editor to generate an App Icon for you, and it will integrate it for you automatically.
### 2. Press Publish to App Store
Press **Publish to App Store**. Another window will open up.
[*Remember, if you haven't set up an Apple Developer account. Check out our guide.*](/store-guides/apple-developer-account)
Sign in with your Apple Developer account. Rork builds the app on its own machines, so you do not need Xcode, a Mac, or any other build account.
**You should not have to do anything at this point since we already updated our names earlier. Start Submission.**
**Stay on this page while the app builds and submits. There will be a point where Apple asks for a code through one of your signed-in devices. Please have that ready to enter into Rork when asked.**
**When the app submits, you will see it show up on App Store Connect Apps Dashboard.**
[Click this link to get to it quickly](https://appstoreconnect.apple.com)
### Congrats! You have successfully submitted your app to the App Store
From this point, just follow all the instructions inside your app in App Store Connect to finish entering your [Product Page](https://developer.apple.com/app-store/product-page/), then you can finally submit to the App Store!
You will have an app in the App Store in no time! Good luck and tweet us your app link! [@rork\_app](https://x.com/rork_app)
Once the app is live, the ratings and the written reviews arrive in the project, and the agent writes your replies. See [Reply to App Store reviews](/store-guides/app-store-reviews).
# Screenshot Studio: App Store screenshots in a minute
Source: https://docs.rork.com/store-guides/screenshot-studio
Screenshot Studio turns your raw app screens into a designed App Store deck: written headlines, painted backgrounds, and iPhone frames, exported at the size App Store Connect accepts.
Raw simulator screenshots sell nothing. The listings that convert have a headline on every slide, a background that matches the app, and the screen inside a device frame.
**Screenshot Studio** does that for you, at [rork.com/screenshots](https://rork.com/screenshots). It is free while in beta, and it needs no account.
## Use it
**App Store URL** works best, because Rork reads your app's name, its description, and your existing screenshots. **GitHub repo** works for an app that is not published yet. If neither fits, skip ahead and upload your screens by hand.
Rork fills in the app name, the category, and a summary. Correct them if the store listing is out of date, because the headlines are written from this text.
Choose the screens that carry your story. Use **Upload your own** for screens Rork could not find, straight from your simulator or phone.
**Layout** and **Style** are both optional. Pick a preset like dark premium or gradient dreamy, or write your own direction in a sentence and the whole deck follows it.
It takes about a minute. **Download all** gives you the deck, and any slide you dislike has its own **Retry**.
## What you get
* **PNG files at 1284×2778**, the iPhone 6.5-inch size App Store Connect accepts for every modern iPhone
* **A written headline per slide**, short and specific to your app
* **Background art per slide**, tied together by one palette
* **Your screen inside an iPhone frame**, composited to the pixel
Upload the files straight into App Store Connect. There is nothing to resize.
The output is sized for the App Store. For Google Play, generate your Play listing images separately, since Play asks for different sizes. See [How to publish your Rork app to Google Play Store](/submitting-to-play-store/creating-the-aab-file).
## Write better headlines
The studio writes the copy, but it writes from what you give it. Two habits improve the result:
1. **Fix the summary before you generate.** One clear sentence about who the app is for beats a paragraph of store keywords.
2. **Order the screens like a pitch.** The first slide earns the second. Lead with the thing people came for, not with your settings screen.
## How it relates to the rest of Rork
| Tool | What it is for |
| - | - |
| **Screenshot Studio** | A standalone deck for your store listing, from any app, no account |
| **Screenshots in your project** | Ask the agent for store screenshots while you build in Rork |
| **Mockup creator** | Social images from the preview, sized for X, Instagram, and stories |
The studio also works for apps that were never built in Rork. If you are shipping something from another tool, you can still use it.
## FAQ
Yes, free while in beta, and no account is needed. It does not spend your Rork credits.
Import a GitHub repo, or upload raw screenshots from your simulator. The studio takes it from there.
Yes. Pick a preset, or describe the look you want in a sentence and the whole deck follows it.
Up to six, which matches what a store listing shows before people stop swiping.
Screenshots have to show your real app, not a mockup of features you do not have. The studio frames your real screens, which is what Apple asks for. See the [App Store Checklist](/submitting-to-app-store/apple/app-store-checklist).
## Next steps
Required sizes and what to put on each slide.
Check your app against the guidelines before you submit.
Take the finished app to review.
Images, video, audio, and 3D inside your app.
# TestFlight: put your app on real phones
Source: https://docs.rork.com/store-guides/testflight-beta-testers
Rork uploads your iPhone build to TestFlight, then gives you a link to invite testers. This page covers the submission steps, the beta link, and exactly what a tester has to do.
TestFlight is Apple's way of putting an app on real phones before it reaches the App Store. Use it to check your app on a real device, and to let other people try it before review.
Rork uploads the build for you. You do not need Xcode and you do not need a Mac.
## Get a build onto TestFlight
In the project header, press **Publish** and choose your iPhone app.
Rork shows the name and details the store will see, then **Continue**.
Rork needs your Apple Developer account. Membership costs **\$99 a year**, and it may vary by country. If you do not have it yet, see [Create your Apple Developer Account](/store-guides/apple-developer-account).
Rork downloads the project, prepares the build, builds the app, and uploads it to App Store Connect. The chat shows each stage, so you can leave and come back.
When the upload finishes, Rork says the build is available on TestFlight and names the build number.
Apple processes the build for a few minutes after the upload. Until that finishes, TestFlight may not show it yet.
## Invite testers with a link
After a successful build, Rork offers **Share Beta Link**. It gives you an address like `rork.com/beta/…` that walks a tester through the whole install.
The dialog lets you **Copy invite link**, **Regenerate** it if it leaked, and **Revoke** it when testing is over.
Only the project owner and editors can share a beta link. A viewer does not get the button. See [Share a project and work together](/collaborate/share-a-project).
## What your tester does
Send them the link and they see "You've been invited to test", with your app's name, then five short steps:
Apple's TestFlight app, from the App Store. The page offers **Get TestFlight** for people who do not have it.
It has to be the email on their **Apple ID**, otherwise the invite lands nowhere.
They press **Request Team Invitation**, then accept the email Apple sends. **Resend** is there if it does not arrive.
**Join TestFlight**, then accept in the TestFlight app. **Refresh Status** updates the page.
The page confirms it: the app is installed, and they open it from the home screen like any other app.
Tell your testers to use their Apple ID email, and warn them there are two invitations to accept, one by email and one in TestFlight. Those two things cause most of the confusion.
## How big a beta this suits
Rork's link adds testers through your **App Store Connect team**. That route is quick and needs no extra Apple review, and Apple caps how many people it allows, so it fits a tester group of friends, colleagues, and early users.
For a large public beta, add external testers in App Store Connect yourself. Apple reviews a build before it goes to an external group, which is a separate wait.
## After the beta
TestFlight is not the App Store. A build on TestFlight is not for sale and not public.
When the app survives your testers, submit it for review. See [Publish Your App to the Apple App Store](/store-guides/publish-app-store), run the [AI App Store Reviewer](/ai-app-store-reviewer) first, and read [Main App Store rejection reasons](/appstore-submission-checklist/whats-next-after-the-apps-finished) so review does not surprise you.
## FAQ
No. Rork builds and uploads in the cloud. Xcode is optional and is useful for local debugging, testing on a connected device, or manual builds and archives. See [Open your project in Xcode](/how-to-set-up-xcode/how-to-set-up-xcoe).
Yes. TestFlight distribution runs through App Store Connect, which needs a paid Apple Developer account.
Yes. Use [Rork Companion on Windows or Mac](/rork-max-swift) to install a Swift project over USB, or install from the [Rork Max app for iPhone](/rork-max/rork-max-app).
Check that they used their Apple ID email, and that they accepted both invitations. If the link itself is dead, **Regenerate** it and send the new one.
Uploads can fail after they look finished, usually over signing or a missing detail. See [Submission errors](/submitting-to-app-store/apple/submission-errors).
Testers already in the group get the next build you upload. They do not have to accept the invitations again.
## Next steps
Take the tested build to review.
Catch guideline problems before Apple does.
When the build fails or never appears.
The membership TestFlight needs.
# App Store Checklist
Source: https://docs.rork.com/submitting-to-app-store/apple/app-store-checklist
Now that your app is complete here's everything you have to do to make sure your app is App Store ready!
## Test your app
This should seem obvious, but most issues can be avoided by testing your app thoroughly for at least an hour before pushing it to review.
## Create the necessary policies and link them to your app
* Create:
* Privacy policy
* Terms and Conditions
* Get the Apple standard EULA by looking up "Apple standard EULA" on Google, and then get that link for your EULA.
* Take these links and prompt Rork to add them to the paywall
* Add these links to the App Store description as well
Doing both of these actions will prevent future App Store rejections.
## Be transparent with your app's pricing
If you have a paywall inside your app, you must include that fact in your App Store descriptions.
## Review your permission descriptions
Apple rejects apps that ask for a permission without saying why. Every permission your app requests needs a clear sentence explaining the reason.
* Open the code editor in your project
* Open `Info.plist` in the iOS app folder
* Read each `NSCamera...`, `NSPhotoLibrary...`, `NSLocation...` and similar description
Make sure each description properly explains why your app needs that permission. "We need camera access" gets rejected. "Take a photo of your receipt to add an expense" gets approved. You can also ask the agent in chat to review and rewrite all of your permission descriptions.
## Create App Store Screenshots
Create 3-10 screenshots accurately showcasing the functionality of the app. Do NOT stretch iPhone screenshots for iPad screenshots, Apple will reject you!
[***You can find more information on this here!***](/appstore-screenshots/app-store-screenshots)
## **Create a Support URL**
For this, you need your own site displaying a contact page. You can use Google Sites, any website maker, or Termly.
Make sure all of this stuff is done before submitting to the App Store, to get approved by Apple more quickly.
# Submission errors
Source: https://docs.rork.com/submitting-to-app-store/apple/submission-errors
Here are the most common issues with submissions on Rork and the work arounds.
## The build succeeded, but the app is not in App Store Connect
Sometimes the build itself works and the upload to App Store Connect is what fails.
Open the **App Store** tab in your project. Every submission is listed there with its state and its logs. Open the failed submission and read the log to see where it stopped:
* **The build is still running.** Wait for it to finish, the upload starts on its own.
* **The build failed.** Fix the build first, see the next section.
* **Apple needs to approve a capability.** Rork shows the request with a link to Apple. Approve it there, then start the submission again.
* **A version is already waiting for review.** Apple allows one build per version in review. Either replace that build or raise the version number, then submit again.
If the submission still fails, start a new submission from **Publish → App Store → Submit to App Store**. Rork rebuilds and uploads with the same settings.
## Build error
If the build fails, the log tells you exactly what Xcode did not like.
### How to resolve a build error
1. **Open the build logs**
* In the **App Store** tab, open the failed submission and expand the log.
* Scroll until you see the complete error message.
2. **Copy the entire error log**
* Include all lines related to the failure (do not truncate).
* The more complete the log, the faster the issue can be resolved.
3. **Paste the error log into Rork**
* Provide the log directly to Rork and ask it to fix the build.
* Rork uses the exact error output to identify missing configuration, invalid values, or dependency conflicts.
4. **Apply the suggested fix and rebuild**
* Rerun the build after the fix is applied.
* If the build fails again, repeat the process with the new error output.
### Why this works
Build errors are highly specific to the state of your project. Passing the **exact build output** lets Rork reason over the same information the build machine used, which makes the fix faster and more accurate.
In most cases, repeating this loop resolves the issue within one or two iterations.
### Common causes of build errors
* An iOS permission key is missing from `Info.plist`, so Apple rejects the upload
* A Swift package fails to resolve, or two packages need different versions
* A capability in the project is not enabled on your Apple Developer account
* The bundle identifier or version does not match what App Store Connect expects
### Tip:
Always paste **full logs**, not summaries. Partial logs can hide the root cause and slow resolution.
## Testflight Bugs
There are two common Testflight issues:
1. The app will instantly crash once you open it
2. The AI functionality will not work inside Rork.
### Issue #1
First click share:
Copy the Crash logs from App Store Connect and paste them into Rork, telling it to fix it. If that doesn't work, go to XCode
Check the logs in either Xcode or VS Code after running yarn start and run it through ChatGPT or Rork till the issue is resolved.
# How to test Android apps on your Android device
Source: https://docs.rork.com/submitting-to-play-store/apk-file
How to test your Rork app on a real Android phone, and how to get an installable APK build when you need one.
Android apps in Rork are **native Android (Kotlin)** apps. They come with a built-in Android emulator: Rork builds the app and runs it in the emulator right in your browser, so most testing needs no extra setup. See [Build a native Android app with Rork](/android/rork-android) for what the emulator can do.
When you want the app on your own phone, you have two ways: install the APK by hand, or test through Google Play.
An iPhone (Swift) app is iOS only and does not run on Android. To reach Android users, add an Android app to the same project, see [Convert your app between iOS, Android, and web](/import/convert-between-platforms).
## Install the APK on your own phone
Rork builds the APK for you, so you do not need a terminal or any build service:
1. Open your project and click **Publish** at the top of the page, then open the Google Play section.
2. Click **Download APK**. If the button is not there yet, build the app first and wait for the build to finish.
3. Open the downloaded `.apk` file on your Android phone and install it. Android asks you to allow installs from your browser or file manager the first time.
## Test through Google Play instead
Use Google Play internal testing when you want testers to install from the Play Store, or when you want to check your Play Console setup before launch:
1. Follow the [Google Play publishing guide](/submitting-to-play-store/creating-the-aab-file) to build the AAB and send it to an internal testing track.
2. Add your own email as a tester and accept the invite link.
3. Install the app on your phone directly from the Play Store.
Internal testing releases are only visible to your testers. This is the same path you will use for the real launch, so testing this way also verifies your Play Console setup.
# How to publish your Rork app to Google Play Store
Source: https://docs.rork.com/submitting-to-play-store/creating-the-aab-file
Google Play requires an AAB (Android App Bundle) file for distribution. This guide shows how to get the AAB for your Rork project and upload it to the Play Console, starting with an internal testing release.
**Prerequisites:**
* A Google Play Developer account. Sign up at [https://play.google.com/console/signup](https://play.google.com/console/signup)
* A desktop or laptop. You cannot do this from a phone.
Rork builds the AAB for you. Android apps in Rork are **native Android (Kotlin)** apps, and the **Publish** button does the whole build. For the whole picture, from the first prompt to the release, see [Build a native Android app with Rork](/android/rork-android).
An iPhone (Swift) app cannot go to Google Play. To reach Android users, add an Android app to the same project, see [Convert your app between iOS, Android, and web](/import/convert-between-platforms).
## Watch the Android and Google Play walkthrough
The video starts with adding Android to an iPhone project, then shows the Google Play connection and build dialog. Continue below for the full build and upload instructions.
## Build the AAB in Rork
1. Open your project and click **Publish** at the top of the page, then open the Google Play section.
2. Click **Connect Google Play** and sign in with the Google account that manages this Play Console app.
3. Click **Build AAB for Play**. Rork builds a release AAB signed with a persistent upload key that is unique to your project.
4. When the build finishes, choose how to deliver it:
* **Send to Google Play** uploads the AAB to your internal testing track for you. This appears once Rork verifies that your Google account can manage the Play Console app.
* **Download AAB for Play Console** downloads the signed `.aab` file so you can upload it by hand.
5. If you downloaded the file, continue with [Upload the AAB in Play Console](#upload-the-aab-in-play-console) below.
Rork needs the app to already exist in Play Console before it can send a build. If Rork says **Create Play Console app**, create the app listing first, then let Rork check access again.
**Do not ask the Rork agent to add its own signing keys, keystores, or SHA1 fingerprints to the project.** Google Play permanently associates your app with the key used for the first upload. Rork manages this key for you, and changing signing files in the project can make Google Play reject future uploads. If Play Console reports a signing key or SHA1 mismatch, contact support with your project link instead of regenerating anything.
For app updates, make your changes in Rork and click **Rebuild AAB**. Then send the new build to Google Play, or download it and upload it as a new release in Play Console.
## Upload the AAB in Play Console
Log in to the Play Console at [https://play.google.com/console/developers](https://play.google.com/console/developers) and click the **Create App** button on the right side.
Fill out the app name, the default language, whether or not this is an app or a game, and if you want to make it free or paid. **VERY IMPORTANT:** If you intend for this to be a paid app, make sure that it's marked paid now. You can make a paid app free later, but you can't make a free app paid at any point. Agree to the developer program policy of Google and the export laws. Press Create App.
Now select View Tasks under internal testing.
Click on Select Testers.
Scroll down to the Testers tab and select Create email list. This is where you'll create a distribution list of emails for people you want testing your app. For now, just add your own email so you can test the app yourself.
Just create a list with your email address and hit save.
Scroll back up and click on Create a new release
Upload the AAB file you downloaded from Rork earlier.
Enter the name of your app and any release notes that you may want to add. Perhaps the version from Rork that you uploaded so that you can remember.
Click next at the bottom of the screen.
This brings you to a summary screen. Click Save and Publish at the bottom.
If you get a pop-up, select "Save and Publish."
Once that is completed, go back to the internal testing page and scroll down to the bottom under the testers tab. Copy the link that says testers can join you on the web. They must join on the web first before they try to download the app.
Send the link to yourself and accept the invitation. Now you can install the app from the Google Play Store and test it. Once internal testing looks good, promote the release to a broader track in Play Console when you are ready to launch.
# iPhone, Android, or web: what's the difference
Source: https://docs.rork.com/swift-vs-react-native/whats-the-difference
Rork builds native iPhone apps with Swift, native Android apps with Kotlin, and web apps with React. This page explains what each one is good at, so you can pick the right one for your product.
Rork builds three kinds of apps:
| App type | Language and framework | Runs on | Where it ships |
| - | - | - | - |
| **For iPhone** | SwiftUI | iPhone, iPad, Apple Watch | App Store and TestFlight |
| **For Android** | Kotlin + Compose | Android phones and tablets | Google Play |
| **For web** | Vite + React | Any browser, desktop and mobile | Your own `your-app.rork.app` address |
All three are real code. Rork writes the same kind of project a mobile studio would write by hand, and you can export any of them to GitHub.
## What is Swift?
Swift is Apple's programming language for building apps that run **natively on iPhones and other Apple devices**. Swift apps are built the same way Apple builds its own apps: Xcode, SwiftUI, and the iOS SDK.
With Swift, apps can use native iOS capabilities like home screen widgets, Live Activities, advanced motion and body tracking, augmented reality, better game performance, and more precise access to device sensors. These are the features that make apps feel polished, responsive, and truly "Apple-quality."
Why this matters to you as a Rork user is simple:\
Swift unlocks the same tools used by top-performing iOS apps. It allows apps to feel faster, look cleaner, and take advantage of new Apple features as soon as they're released. If you're building an iOS-first app or care about delivering the best possible experience on Apple devices, Swift gives you the highest ceiling.
In short, Swift is about building apps the way Apple intends: more control, more performance, and a more premium result.
See [Build a native iPhone app with Rork](/iphone/rork-iphone) for the full guide, from the first prompt to the App Store.
## What is Kotlin?
Kotlin is Google's language for **native Android apps**, and Compose is the modern way to build their screens. A Kotlin app talks straight to Android, the same way the apps Google ships do.
Rork writes a real Android Studio project in Kotlin. That gives your app native performance, native navigation and gestures, Material You theming, and direct access to Android capabilities: home screen widgets, background work, notifications, the camera, and device sensors.
Why this matters to you as a Rork user:\
Android is the larger platform by device count in most of the world. A native Android app feels right to those users, passes Google Play review as a normal Android app, and can use new Android features as they arrive.
See [Build a native Android app with Rork](/android/rork-android) for the full guide, from the first prompt to the Google Play release.
## What is a web app?
A web app runs in the browser. Rork builds it with React and Vite, and publishes it to your own address on `rork.app`. There is no app store, no review, and no install: you share a link and people open it, on a laptop or on a phone.
Web is the fastest way to put a product in front of people. It is the natural choice for a landing page, a dashboard, an admin panel, an internal tool, or a SaaS-style product. What it cannot do is the deeply native work: widgets, Live Activities, background tracking, Apple Watch, or store distribution.
See [Rork Web](https://rork.com/web) for examples, and [Rork Web: build and publish a web app](/web/rork-web) for the full guide.
## Things a native iPhone app can do that a web app can't:
### System & Home Screen Features
* Home screen and lock screen widgets
* Live Activities on the lock screen and Dynamic Island
* Apps that continue working in the background (within Apple's rules)
* Integration with iPhone system search (search inside your app)
### Motion, Fitness & Body Tracking
* Advanced motion and full body tracking
* Tracking real movements like pushups, punches, squats, posture, and form
* More accurate, real-time access to motion sensors
* On-device analysis that works offline
### Augmented Reality & Games
* Augmented reality features and immersive AR experiences
* AR-based games and interactive environments
* Smoother, higher-performance games with better responsiveness
### Focus, Control & Productivity
* Screen blocking and focus-style controls for productivity apps
* System-level actions triggered by voice, search, or automations
### Apple Watch & Health Ecosystem
* Deep Apple Watch integration with companion watch apps
* Native workout sessions with background heart-rate and movement tracking
* Apple Watch complications that show live data on the watch face
* Full integration with Apple's Health ecosystem (health data, workouts, routes, permissions)
### Voice, Messaging & Extensions
* Siri voice control and Apple Shortcuts automation
* iMessage apps, sticker packs, and in-message experiences
* Share extensions and system extensions that work outside the main app
### Audio, Camera & Car Integration
* Low-latency audio for real-time voice, sound effects, and audio processing
* Advanced camera features like high-frame-rate video, depth sensing, LiDAR, and real-time analysis
* CarPlay support for driving, audio, fitness, or navigation-style apps
## How to choose:
**Choose For iPhone** if you're building an app that is iOS-first or Apple-only, and you care about taking full advantage of what Apple devices can do. This is the right choice if your app relies on motion or body tracking, fitness or workout data, augmented reality, games, widgets, Live Activities, Apple Watch or Health integrations, or deep system-level features.
**Choose For Android** if Android is where your users are, or if you need a real native Android app for Google Play: native performance, widgets, notifications, and background work on Android terms.
**Choose For web** if the main experience is a website: a landing page, a dashboard, an internal tool, or a SaaS product you want people to open from a link today.
**In simple terms:**\
If the product feels deeply tied to the iPhone itself, build it for iPhone.\
If your audience is on Android, build it for Android.\
If people should just open a link, build it for web.
## Do I have to pick only one?
No. One Rork project can hold an iPhone app, an Android app, and a web app at the same time. Each app has its own code. They share the chat, and the backend if you have one. Start with the platform that matters most, then add the next one from the platform switcher above the preview, or from **Project Settings → Add new app**. See [Convert your app between iOS, Android, and web](/import/convert-between-platforms).
**What about React Native and Expo?** React Native is a cross-platform approach: one JavaScript codebase that renders native UI on both iOS and Android. Rork used to build apps this way and no longer does for new projects. Read [What happened to Expo?](/expo) for the full story, including what happens to projects you already have.
# How to sync your project with Github
Source: https://docs.rork.com/tutorials/how-to-connect-github
Full guide on how to connect your Rork project to GitHub for a 2-way sync
## Why would you want to enable GitHub sync?
Connect **GitHub** if you want to take your Rork app beyond the Rork editor and into traditional development tools.
### GitHub lets you:
* **Share your project with a developer** for collaboration or customization
* **Open and edit your app in Cursor or any code editor**
* **Run and debug the project in Xcode** for iOS development
* **Make code-level changes** that go beyond prompt-based building
GitHub serves as the bridge between **Rork** and professional development workflows, facilitating seamless handoffs, customization, and native development.
If you’re staying fully inside Rork, GitHub is optional.\
If you want deeper control, collaboration, or native tooling, it’s recommended.
\
Step-by-step guide:
1. Click Integrations
2. Click connect with GitHub
3. Once GitHub opens, create an account. Then click install and authorize
4. You will get redirected to Rork, and then name your Repository
5. Now your project is officially connected to GitHub
## What You Can Do Now
With GitHub connected, your Rork project is no longer limited to the Rork editor. You can now:
* **Hand your project to a developer**\
Share the repository so a developer can clone, edit, and push changes.
* **Open the project in Cursor or a code editor**\
Inspect and modify the generated code using Cursor, VS Code, or any IDE.
* **Run and debug the app in Xcode**\
Build locally, test on real devices, and use Apple’s native debugging tools.
* **Customize beyond prompts**\
Make precise code-level changes, add native features, or fine-tune performance.
* **Work in parallel with Rork**\
Continue building in Rork while edits are made through GitHub.
This integration enables you to transition smoothly from **prompt-based building to full code control**, whenever you’re ready.
# Rork Web: build and publish a web app
Source: https://docs.rork.com/web/rork-web
Rork builds web apps with Vite and React, previews them next to the chat, and publishes them to your own address on rork.app. Use it for a website, a dashboard, a client portal, or an admin tool.
One prompt, one project: the chat on the left, the running site on the right.
A Rork web app runs in the browser. Rork writes it with **Vite and React**, previews it next to the chat, and publishes it to your own address on `rork.app`. There is no app store, no review, and no install. You share a link, and people open it on a laptop or on a phone.
Web is the right platform for a website, a dashboard, a client portal, an admin tool, or a SaaS product. It is also the fastest way to put something in front of people today. See what it builds on the [Rork Web page](https://rork.com/web).
## Start a web app
Pick the platform before you send your first message. On [rork.com](https://rork.com), open the platform picker under the prompt box and choose **For web**. Then describe the product, not the technology.
The picker says it plainly: **you can add another platform later**. One project can hold an iPhone app, an Android app, and a web app at the same time. See [Convert your app between iOS, Android, and web](/import/convert-between-platforms).
## Answer the questions about the look
Rork does not start writing code straight away. It asks a few short questions about the look first, and each answer is a picture, not a word. You can also type your own answer in **Other**.
Answer all three, 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 site.
## Work in the project
The project has the chat on the left and a live preview on the right. The preview is the real app, not a picture, so you can click through it while you build.
The controls above the preview do this:
| Control | What it does |
| - | - |
| **Switch preview platform** | Moves the preview between the apps in the project, and adds a platform. |
| **Switch preview size** | Cycles the preview through **Desktop**, **Tablet**, and **Phone**. |
| **Go to home** | Returns the preview to the first page. |
| **Preview path** | The address field. Type a path like `/about` and press Enter to open that page. |
| **Reload preview** | Loads the app again after a change. |
| **Select an element for your prompt** | Point at a part of the page, then write what to change about it. |
| **Publish** | Opens the publish panel. |
Use **Select an element for your prompt** instead of describing a position in words. Point at the element, then say "make this button darker". The agent gets the exact element and changes less around it.
## Check the phone width
A web app has to work in a phone browser as well as on a laptop. Press **Switch preview size** until it reads **Phone**. Rork draws the site inside a phone frame, so you read the same pages at the width your visitors get.
Then ask for the fixes you need:
```
On phone widths the hero text overlaps the image. Stack them instead.
```
## Publish to the web
Open **Publish**, then press **Publish to web**. Rork builds the app and hosts it at your own address on `rork.app`.
What the panel shows:
* **The address.** Rork picks one from the project name, like `ember-roast-website.rork.app`. Press the pencil to change the subdomain.
* **The status.** It reads **Site offline** until you publish for the first time.
* **Add a custom domain.** This row stays off until the first publish. The panel says so: "Publish the project first to add a custom domain."
Publishing is a separate step from building. Your changes stay in the preview until you publish again. When the live site is behind your project, the panel reads **An older version is live** and the button reads **Publish latest version**.
After the first publish the panel changes: the status reads **Live**, it tells you when the version went out, and **Unpublish** takes the site down again. Unpublish asks you to confirm first, because every address on the site stops serving it right away.
## Domains
A `rork.app` address is fine for testing, but a real product wants a real name. Domains live on your account, and one panel manages them. You reach it from two places:
* **Account Settings → Domains**, for every domain you own, from any page.
* **Publish → Add a custom domain**, inside a project. The same panel opens in a dialog called **Custom domains**, and what you set up there connects to this project on its own.
### The domains list
Open the account menu, then **Account settings → Domains**. Every domain on your account is listed here with each of its addresses underneath.
Each address row shows its status, which project it serves, and two icons: a chevron that unfolds **Setup and status**, and either **Disconnect** for an address that serves a project or **Remove address** for a free one. **Add a subdomain** adds another address on the same domain, and reads **Add more subdomains** once the domain has one. The bin on the domain's own row is **Remove domain**.
| Status | What it means |
| - | - |
| **Available** | Ready to connect to a project. |
| **Securing** | Rork is issuing the HTTPS certificate. Nothing to do. |
| **Propagating** | Waiting for DNS to update. Usually a few minutes. |
| **Finishing** | Routing traffic to the app. |
| **Live** | The address serves your published site. |
| **Site offline** | The project is not published. Publish it again and the address comes back. |
| **DNS moved** | Your DNS provider no longer points at Rork. Add the records back, then check again. |
Rork never changes or deletes anything at your domain provider. Disconnecting or removing an address only changes what Rork serves.
### Buy a new domain, or connect one you own
Press **Add domain**. Rork hands this step to **Entri**, its domain partner, which does the technical setup for you. The first screen is the fork:
| Route | Pick it when | What happens |
| - | - | - |
| **Buy a new domain** | You have no domain yet, or you want a fresh one for this product. | You search for a name and buy it inside the flow. It arrives already pointed at Rork. |
| **Connect a domain** | You already own the name, at any registrar. | You give the domain, and Entri sets the DNS records that point it at Rork. |
Buying goes through Entri, not through your Rork credits, and a domain is a yearly cost like any other registration.
Either way the domain lands in the list above. Its addresses start as **Available**, or go straight through **Securing** and **Propagating** while Rork finishes the setup.
### Point a project at an address
The domain is on the account, but no app answers on it yet. That link is made in the project.
The custom domain row stays off until you do. Before the first publish the panel says "Publish the project first to add a custom domain."
In the project, open **Publish**, then press **Add a custom domain**. The **Custom domains** dialog opens with your account's domains and the addresses that serve this project.
Two ways, depending on where the address is:
* **The address is already on your account.** Its row reads **Available**. Press **Connect to this project** on that row.
* **You need a new domain or a new subdomain.** Press **Add domain**, or **Add a subdomain** on a domain you have. Set up from inside the project, the new address connects on its own. Its row reads **Connecting** while that happens.
The address now sits under the `rork.app` row in the Publish panel, with its status underneath. The gear on the row opens its **Setup and status**, and the last row now reads **Add more custom domains**.
One address serves one project. An address that another project already uses reads **In use by** that project, and has no **Connect to this project** button. To move it, press **Disconnect** on that address in the domains list first, or add a subdomain instead.
Only the person who created the project can connect a domain to it. Collaborators see the panel, with a note that says so.
## Add a web app to a project you already have
Watch a finance tracker gain a web version and switch between the web and mobile previews.
Any mobile project can grow a web version. Open **Project Settings → Add new app → Web**, use the platform switcher above the preview, or just ask:
```
Add a web version of this app
```
Each app keeps its own code. They share the chat, and the backend if you have one. A common split is a mobile app for customers and a web app as the admin dashboard.
## What a web app cannot do
A web app runs inside the browser, so the deeply native features are out of reach:
* No App Store or Google Play distribution
* No home screen or lock screen widgets, no Live Activities, no Dynamic Island
* No Apple Watch app and no Apple Health integration
* No background tracking, and no advanced motion or body tracking
* Push notifications are limited. On iPhone and iPad the user must add the site to the Home Screen first, on iOS 16.4 or later, and then grant permission
If your product needs any of those, build the native app and keep the web app beside it. See [iPhone, Android, or web: what's the difference](/swift-vs-react-native/whats-the-difference).
## FAQ
A real Vite and React project in TypeScript, styled with Tailwind. You can export it to GitHub and run it anywhere. See [How to connect GitHub](/tutorials/how-to-connect-github).
Yes. Write the look into your first prompt, and the agent has less to ask. In **Design mode** you can also press **Build** straight away.
Yes. Use [Rork Cloud](/backend/rork-cloud) for a backend inside Rork, or connect [Supabase](/backend/supabase) or [Firebase](/backend/firebase). The apps in one project can share the same backend.
Yes, and you can buy one inside Rork if you do not have it yet. Publish to the `rork.app` address first, then see [Domains](#domains).
No. An address belongs to one project. The domains list marks an address that is already taken as **In use by** that project. Disconnect it there first, or add a subdomain for the second project.
No. Rork imports it. See [Lovable to mobile app](/import/lovable-to-mobile-app), and keep the web app in the same project.
## Next steps
The matching Swift guide, from the first prompt to the App Store.
What each platform is good at, and how to choose.
Grow the project into iOS and Android from the same chat.
Accounts, data, and files for your web app.
Turn an existing site into a native app.
The product page, with examples of what Rork builds for the browser.