I've been building iOS apps independently since 2014. The tools have changed — from Objective-C and Xcode, to Swift, to React Native, to now letting AI write the code. The fundamentals of shipping an app and making it earn money haven't changed as much.
This is a documented record of taking a Rork app from idea to revenue — with specifics I don't see in most guides. Not "Rork is great," but "here's what actually happened."
Planning: How to Decide What to Build
Before touching Rork, I verify demand using a few data points.
Category demand check
On data.ai (formerly App Annie), I look at the top apps in the target category: estimated monthly downloads, estimated revenue, and — most importantly — obvious weaknesses in the top 3 apps that I could address.
For lifestyle and wallpaper apps specifically: the category has high install volume, but users churn and switch frequently. An app with a distinctive theme that resonates deeply with a specific audience can build a loyal user base without competing head-on with large publishers.
Revenue model — decide before building
I choose the monetization model before writing a single prompt to Rork. The three options:
- AdMob only: Simple to implement. Requires high session frequency and volume to generate meaningful revenue. Viable if the app type naturally drives daily or multiple-daily use.
- Subscription only: Predictable monthly revenue, but the free tier needs to be genuinely useful or no one converts.
- Hybrid (AdMob + subscription): Free users see ads; paying users get ad-free. This is my primary model. It creates a natural upgrade incentive without making the free experience feel punitive.
My hybrid model rule: ads should be present enough to motivate upgrades, not intrusive enough to cause uninstalls. Concretely: interstitial every 5 uses + persistent banner, both removed for subscribers. Full-screen interstitials after every action reliably destroy retention; banner-only doesn't motivate upgrades.
Development: How I Structure Rork Prompts
Before starting in Rork, I write a specification document in plain text. The document covers:
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 document into Rork's first prompt. A clear full-scope description upfront reduces costly mid-development pivots — "I need to add a screen we didn't plan" is expensive to fix after other screens are built.
Common development issues and fixes
Some problems come up consistently in Rork projects:
Slow image loading with large lists: Loading Supabase images into a FlatList with native Image components causes scroll jank with more than 20-30 items. Fix: prompt Rork to switch all Image components to expo-image with contentFit="cover" and cachePolicy="memory-disk". Jank drops substantially.
Navigation state issues in nested stacks: Stack → Tabs → Stack navigation sometimes produces incorrect back-button behavior. Fix: prompt Rork to use router.dismiss() instead of useRouter().back() for dismissing modals and returning from nested stack screens.
AdMob initialization timing: Ads don't load on the first screen if AdMob initializes late. Fix: prompt Rork to call mobileAds().initialize() at the top-level component in app.tsx, before any ad-displaying screen mounts.
App Store Review: Rejection Patterns I've Hit
Knowing what gets rejected before you submit saves days. These are the patterns I encounter most:
Guideline 2.1 — App Completeness
Crashes or non-functional features are immediate rejections. Solution: test on a real device via TestFlight before submitting. Rork-generated apps can behave differently on device vs. simulator — always validate on hardware.
Guideline 4.0 — Copycat Apps
Simple-category apps (wallpaper, timer, calculator) face more scrutiny for originality. If the reviewer can't identify what makes your app distinct, it risks rejection under the "copycat or clone" guideline. My rule: build at least one feature or interaction pattern that no top competitor offers. The uniqueness doesn't need to be dramatic — a thoughtful UX detail or a specific niche focus is enough.
Guideline 3.1.1 — In-App Purchases
Before submitting any app with subscriptions, verify in TestFlight with sandbox accounts:
- Subscription purchase completes successfully
- Premium features unlock immediately after purchase
- Features revert correctly after subscription cancellation
- Restore purchases works across reinstalls
A broken purchase flow is an automatic rejection. Testing this in sandbox catches the issues before review.
PrivacyInfo.xcprivacy
Recent Xcode/EAS build requirements mandate accurate PrivacyInfo.xcprivacy declarations for any SDK that collects data. AdMob, Firebase, and RevenueCat each have required entries. Prompt Rork to configure PrivacyInfo.xcprivacy correctly when you add these SDKs — it generates the file but sometimes requires explicit instruction.
The First Month After Release
Without external action, new app downloads after release are minimal. App Store search rankings depend on downloads, reviews, and engagement signals — all of which need a cold-start push.
My release-day checklist:
- Personal network downloads: 10-20 installs from people you know helps prime the algorithm. Ask directly.
- Social media posts: Short video (Reels, Shorts) outperforms static screenshots for reach. Show the app actually running, not just the icon.
- In-app review prompt implementation:
SKStoreReviewController.requestReview()triggered at a moment of genuine positive engagement — after favoriting content, completing a goal, or returning for a third session. Not on first launch. - ASO keywords: Fill title, subtitle, and keyword fields completely before submission. It doesn't need to be perfect — it needs to exist. Iterate monthly.
Revenue timeline
AdMob revenue becomes meaningful around 100 DAU (daily active users). At that level, depending on category and geography, expect roughly a few hundred to a few thousand yen per month. The path to 100 DAU typically takes 2-6 weeks of consistent promotion for a lifestyle app with no paid acquisition.
Subscription revenue at 100 DAU: assuming 1-3% conversion, that's 1-3 subscribers. At ¥500/month, that's ¥500-1,500 monthly. Modest, but real. The value of first subscription revenue isn't the amount — it's confirmation that someone believed your app was worth paying for. That confirmation is what makes iteration feel worthwhile.
Growing Revenue After Launch
Acquisition: ASO iteration
Monthly: check competitor keyword changes, update your keyword field accordingly. Quarterly: run Product Page Optimization (App Store A/B test) on screenshots. Screenshot order and design have measurable conversion impact.
Retention: push notifications
Habit-building notifications outperform re-engagement notifications. "Your daily [X] is ready" converts better than "You haven't opened the app in 3 days." Weekly frequency is my balance point — frequent enough to maintain habit, not frequent enough to trigger uninstalls.
Conversion: paywall timing
The upgrade screen shown at a moment of value recognition converts better than one shown at first launch. After a user favorites content, after their third session, after using a premium-adjacent feature — these are the right moments. Rork makes it straightforward to wire a navigation action to any user behavior trigger.
RevenueCat's dashboard supports built-in A/B tests on paywall variants. Test annual vs. monthly plan prominence, price display format, and copy. Measure for 2+ weeks before concluding.
Sustaining a Rork App Long-Term
At 6-12 months post-launch, apps split into two trajectories: stable or growing revenue vs. declining. The dividing factor is consistent updates.
Apps updated monthly maintain their "recently updated" signal in App Store search. Apps left untouched after launch lose positions to newer competitors within 3-6 months.
Rork's core advantage for long-term operation: small improvements are fast. Changing a UI element, adding new content, tweaking copy — these take minutes of prompting rather than hours of coding. That speed makes sustaining a release cadence realistic for one person juggling multiple apps.
The combination that works: Rork handles implementation velocity; you handle strategy — what to build, how to position it, which numbers to optimize. Neither part is optional. The developers who sustain apps long-term are the ones who stay engaged with both.