The night before I planned to submit, the build was green and my checklist still had no line for the Apple Developer Program fee. I was redoing the cost estimate and realized I had spent all my attention on the building and almost none on what goes out, or on what stops a review. I noticed it standing in front of the submit button.
This is a record of taking a Rork app from idea to store release and on to revenue improvements, ordered by where people tend to stumble. Plenty of material says "you can build it in Rork." Much less covers what happens after you ship. I'll try to fill that gap and keep verified facts separate from my own estimates.
Rork can do the building; deciding what to ship, how to ship it, and how to grow it stays with you. Everything below hangs on that line.
Planning: How to Decide What to Build
Before opening Rork, I check demand with a few data points.
Category demand check
For the top apps in the category I want, I look at estimated downloads, estimated revenue, and, most of all, a clear weakness in the top three that I could address.
One note: App Annie (later data.ai), which many older guides recommend, was folded into Sensor Tower in 2024. Today Sensor Tower or similar tools are the realistic option. Free views are limited, so I also read the store rankings and the reviews themselves.
Wallpaper and lifestyle categories are crowded, but users switch apps easily. An app with a distinctive theme can build a loyal audience without competing head-on with large publishers.
Revenue model: decide before building
I choose the model before writing the first prompt. There are three options:
- AdMob only: Simple to implement, but it needs an app that people open often. As a rule of thumb, I'd want to expect 500,000 to 1,000,000 monthly impressions before relying on ads alone.
- Subscription only: Revenue is predictable, but the free tier has to be genuinely useful or nobody converts.
- Hybrid (AdMob + subscription): Free users see ads, paying users get an ad-free experience. This is the model I mainly use.
The principle for the hybrid: ads should be present enough to motivate an upgrade and never so intrusive that people uninstall. A full-screen interstitial after every action drives people away, and banners alone give no reason to pay. As a starting point, I use an interstitial every few uses plus a persistent banner, both hidden for subscribers, then adjust the interval by watching drop-off. I look more closely at where ads and subscriptions start eating each other's revenue in Rork App Revenue Design: Where Ads and Subscriptions Eat Each Other.
The Costs That Don't Show Up in the Estimate
Before the money coming in, the money going out. Shipping one app involves more than the Rork subscription.
| Item | Cost (at time of writing) | Notes |
|---|---|---|
| Rork (React Native) | Free to about $25/month | The free tier caps generations; plan on a paid plan once you start building in earnest |
| Rork Max (native Swift) | $200/month | An option if you want to reach Apple Watch or Vision Pro. For this article, the React Native version is enough |
| Apple Developer Program | $99/year | Required for App Store submission. If it lapses, distribution stops |
| RevenueCat | Free up to $2,500/month tracked revenue | As stated on RevenueCat's pricing page. Above the threshold, a revenue-based rate applies |
| Supabase | Free tier available | Plan for a paid tier once image bandwidth grows |
Another easy-to-miss cost is credit consumption. Every time you change the spec and regenerate, credits burn. Writing the full screen plan first, as described below, saves money as well as rework.
Prices and plan terms change, so please verify against official sources before committing. For choosing between tiers, see Rork Pricing Plans Compared Honestly: Free vs Pro vs Max and How to Choose as an Indie Developer.
Development: How I Structure Rork Prompts
Before starting in Rork, I write the whole screen structure down in plain language.
App name: [name]
Core concept: [one sentence]
Screens:
1. Splash → Home (first launch only)
2. Home: [description]
3. Detail view: [description]
4. Favorites list
5. Settings: subscription management, notification preferences
6. Premium upgrade screen
Monetization:
- AdMob banner: bottom of Home screen
- AdMob interstitial: Detail view, every 5 views
- Subscriptions: monthly + annual plans via RevenueCat
Backend:
- Image assets: Supabase Storage
- User data: Supabase Database (favorites, settings)
- Subscription management: RevenueCat
I paste this into the first prompt. The clearer the full scope, the fewer "we need one more screen after all" pivots.
Common development issues and fixes
In React Native (Expo) apps, the same few problems keep appearing.
Slow image loading in long lists: Rendering many Supabase images in a FlatList with the stock Image component tends to make scrolling heavy. Switching to expo-image often helps, so I tell Rork:
Replace every Image component with expo-image.
Use contentFit="cover" and cachePolicy="memory-disk".
Odd back behavior in nested navigation: With Stack → Tabs → Stack, the back button can behave differently than you expect. Expo Router has router.back() and also router.dismiss(), which closes the current stack. Which one is right depends on your structure, so I describe concretely which screen should return to which. That usually saves a round of rework.
Late AdMob initialization: If initialization is late, the first ad is late too. In an Expo Router project I ask Rork to call mobileAds().initialize() once in the root layout, such as app/_layout.tsx, and to request ads only after initialization finishes.
App Store Review: Where Reviews Tend to Stop
The items that stop reviews are fairly predictable. Clearing them beforehand cuts the back-and-forth.
Guideline 2.1: App Completeness
Crashes and non-working core features are rejected. Testing carefully on a real device through TestFlight catches these before you submit. Generated code can behave differently on a device than in the simulator, so I never skip the hardware check.
Guideline 4.1: Copycats
Apple's guidelines say, in essence, don't copy a popular app or make minor changes to another app's name or UI and pass it off as your own. Crowded categories such as wallpaper, timer, and calculator apps tend to be asked this question more often. My rule is to build at least one thing only your app does. A UI detail or a narrow niche focus is enough.
Guideline 3.1.1: In-App Purchases
If you ship subscriptions, check these four points with sandbox accounts before submitting:
- The purchase completes
- Premium features unlock right after purchase
- The app returns to the free state after cancellation
- Restore purchases works after a reinstall
A broken purchase flow stops the review. Please run the whole loop yourself before submitting.
Privacy manifest (PrivacyInfo.xcprivacy)
Apple asks apps and SDKs to include a privacy manifest and to declare approved reasons for certain APIs. Missing declarations can lead to emails from App Store Connect or upload errors such as ITMS-91053. After adding SDKs such as AdMob, Firebase, or RevenueCat, I keep them up to date and check that the build output shows no missing declarations. I don't leave this entirely to the generated code; I read what comes out.
The First Month After Release
Without any action from you, a newly released app gets almost no downloads. The first push has to come from you.
My release-week routine has four parts:
- Tell people close to you: Cover the first 10 to 20 installs by telling friends and colleagues. I avoid trading anything for ratings or reviews.
- Post on social media: Show the app actually running on X, Instagram, or Threads. Short video seems to travel further than a static screenshot.
- Add a review prompt: In Expo,
requestReview()fromexpo-store-reviewdoes this. Trigger it right after a good moment, such as favoriting something. The official docs advise against calling it from a button or in time-sensitive moments. - Set up ASO: Fill the title, subtitle, and keyword fields. They don't need to be perfect at first. Get something in, then revisit monthly.
How long until the first revenue (an estimate)
What follows is an estimate built on stated assumptions, not a measured result. Real numbers vary a lot by category and country.
| Assumption | Value |
|---|---|
| Daily active users (DAU) | 100 |
| Ad impressions per user per day | 3 |
| eCPM (revenue per 1,000 impressions) | $1 to $3 |
| Exchange rate | $1 = ¥150 |
That gives 100 users × 3 impressions × 30 days = 9,000 impressions a month. Revenue is $9 to $27, or roughly ¥1,350 to ¥4,050. At 100 DAU, ad revenue is in the range of a few hundred to a few thousand yen a month.
For subscriptions, assuming 1 to 3 percent conversion at 100 DAU, you have 1 to 3 subscribers. At ¥500 a month that is ¥500 to ¥1,500, before store fees.
Is that small, or a beginning? I take it as a beginning. Someone choosing to pay, even a single yen, is worth more than the number suggests. The same arithmetic also shows that reaching tens of thousands of yen a month from ads alone means growing DAU by an order of magnitude.
Growing Revenue After Launch
Once the first revenue arrives, I cycle through three levers.
Acquisition: ASO iteration
Steady ASO review costs nothing to keep up. Once a month I check how competitor keywords have changed and update my keyword field. Screenshot comparisons can be run with Product Page Optimization in App Store Connect.
Retention: push notifications
Notifications can affect retention depending on how you use them. Ones tied to a habit ("Your daily [X] is ready") seem to suit. Win-back messages like "You haven't opened the app in 3 days" get noticed, but high frequency is a common reason people switch notifications off. In my own operation I start from about once a week. For a fuller treatment of notification design and long-term retention, see User Retention & LTV Maximization for Rork Apps.
Conversion: paywall timing
When you show the upgrade screen matters. I believe it responds better right after someone feels value, such as after favoriting content or using a feature twice, than at first launch.
UI choices such as showing the annual plan first or spelling out the saving over monthly also affect conversion. RevenueCat lets you compare paywall variants, so after each change I check the numbers.
Sustaining a Rork App Long-Term
Six to twelve months after launch, apps split into those that hold their revenue and those that decline.
In my observation, one dividing line is update frequency. Apple has not officially said that updates lift search rankings, so please take that as a rule of thumb. What I can say as fact is that an abandoned app collects newer competitors around it, and review replies and bug fixes stop.
Rork suits small, fast improvements. Changing a button color or adding content takes a prompt rather than hours of coding. That speed makes a steady release cadence realistic for one person.
Closing
Add three lines to your pre-launch checklist: costs, a real-device test, and one full pass through the purchase flow.
Rork takes care of the building. What to make, how to ship it, how to earn from it, and how to improve it stay in your hands. I hope this record serves as a rough draft for your own release.