A wallpaper app is one of the more approachable genres for an indie developer. The feature set is simple, the content is the star, and it has many of the traits of apps that stick around on the App Store for a long time.
I've run wallpaper and calming-themed apps as an indie developer for years. Building a new one with Rork was a natural extension of that, and this piece is a full record of taking it from zero to release. I'll be honest about the parts that went smoothly and the parts that got stuck. In particular, the fact that iOS won't let an app set the wallpaper directly is something worth knowing before you plan anything — it changes the design — so I give it proper space below.
Planning — deciding not to build "just another wallpaper app"
The first thing I did was install more than thirty existing wallpaper apps and actually use them. What struck me was how many were just "a big pile of images stuffed into an app."
What I wanted to build was an app with a small, curated set of images, made carefully all the way down to the download experience. My goal was that ten images someone loves the taste of would beat a hundred generic ones.
Deciding this direction up front kept my instructions to Rork consistent. When the experience you want is put into words, that's exactly what carries over to a generative tool.
Building the UI in Rork — what worked and what fought back
What worked:
A wallpaper app's main screen is a grid of images. This is squarely in Rork's wheelhouse, and when I said "make a gallery screen that shows images in a grid, and opens a full-screen preview on tap," it produced a surprisingly complete first version.
Placing the "download" button in the detail view was also just a few rounds of natural-language tweaking to land where I wanted it.
What fought back:
The skeleton animation while images load (the grey placeholder frames) was hard to fine-tune. "Make the fade-in a bit slower" didn't land well, and I ended up editing Rork's generated code directly. Generative tools are great at framing the whole structure at once, but for this kind of feel-based adjustment, it's sometimes faster to touch the output yourself.
On iOS, an app can't set the wallpaper directly — this is the design fork
This is the single most important thing to know before building a wallpaper app. iOS has no public API for an app to set the home or lock screen wallpaper programmatically. Private APIs that attempt it exist, but submitting one to the App Store gets you rejected. Even if you want an app that finishes the job with a "Set as wallpaper" button, that experience simply can't be built officially.
There's really only one realistic design. You save the image to Photos (the camera roll) first, then guide the user: "Please set it as your wallpaper from the Photos app or the Settings app." Rork produces React Native (Expo) apps, so saving uses expo-media-library.
import * as MediaLibrary from 'expo-media-library';
import * as FileSystem from 'expo-file-system';
// Save the wallpaper to the camera roll. Since iOS can't "set wallpaper"
// directly, this function's only job is to hand a full-res image to Photos.
async function saveWallpaper(remoteUrl) {
const { status } = await MediaLibrary.requestPermissionsAsync();
if (status !== 'granted') {
// If permission was denied, surface a path to the Settings app
return { ok: false, reason: 'permission-denied' };
}
const target = FileSystem.cacheDirectory + 'wallpaper.jpg';
const { uri } = await FileSystem.downloadAsync(remoteUrl, target);
await MediaLibrary.saveToLibraryAsync(uri);
return { ok: true };
}Turned around, this constraint means the one sentence right after saving decides the quality of the experience. When a save succeeds, I show an "Open Photos" button and a short three-step guide (open Photos → share → set as wallpaper). The limitation itself can't be changed, so the idea is to differentiate on how gracefully you guide. Explanations like "you can choose home screen, lock screen, or both" also live in that guidance text, not in a screen the app pretends to control.
Rork's in-editor preview can't fully verify the save-and-permission behavior, so I iterated on a real device with Rork Companion. The photo-library permission dialog is one of those things you can only truly judge on hardware.
Preparing the images — where most of the time went
More than the technical implementation, preparing the content took the most time. Images used as wallpaper need to be clearly cleared for copyright. I combined images I shot and made myself with CC0-licensed material.
Prepare resolution for the largest iPhone display. Recent large models sit around 1290×2796px, so I export with headroom — roughly 3000px on the long edge — and optimize from there for delivery. File size ties directly to perceived speed, so I recommend converting to WebP.
# Convert a source image to WebP. Quality around 82 tends to be the
# sweet spot between fidelity and file size.
cwebp -q 82 wallpaper_3000.png -o wallpaper_3000.webp
# To convert a whole folder at once
for f in originals/*.png; do
cwebp -q 82 "$f" -o "webp/$(basename "${f%.png}").webp"
doneFor the same image, WebP is often 20–30% smaller than JPEG, and it makes grid scrolling smoother. That said, at the moment of "saving" a wallpaper I want to avoid degradation, so I hand over the original high-quality image and use WebP only for the list thumbnails — a two-tier setup.
App Review will sometimes ask where the image copyright resides, so keep a note of sources and rights during this prep stage. It makes the first response to a rejection remarkably easy.
Structuring revenue — where to place ads without breaking the experience
Wallpaper apps are commonly distributed free and run on ad revenue. My own indie work has long been anchored on ad income too. The key here is not to let ads ruin how the work is seen.
Here's the placement I settled on.
| Ad type | Where | Intent |
|---|---|---|
| Interstitial | Right after a save action | Slip it in at a natural break. Frequency-cap to once every few times |
| Rewarded | Unlocking a limited pack | Only those who want to watch, watch. Never forced |
| Banner | Avoid on principle | Never fix one over the grid or the preview |
The thing I most wanted to avoid was overlaying a banner on the full-screen preview. A wallpaper's core value is showing that image large and pleasingly, so putting an ad on top of it erodes the very experience. Interstitials shown every time drive people away too, so I started at roughly one per three saves and tightened the frequency while watching real data. Rather than rushing to raise impressions, earning across total session volume by keeping people around longer tends to make revenue more stable in this kind of app.
App Store review — the road to approval
My first submission was bounced because the screenshot specs didn't meet requirements. I'd used the app screenshots straight from Rork, but the App Store needs screenshots at different resolutions per iPhone model.
I rebuilt the screenshots at each device size in Figma and resubmitted, and it was approved. From first submission to passing review took about six days; including the back-and-forth from rejection to resubmission, about ten days total. This varies a lot by app, but it's easier on you to treat a rejection as expected and prepare for it.
For wallpaper apps specifically, review tends to look at two things: rights, and whether there's substantive functionality. An app that only lines up images to save can be judged thin, so having one or two basic "app-like" touches — favorites, or category sorting — keeps things stable.
What I learned running it after launch
Looking back at the first month's numbers, downloads grew most not right after launch, but around three weeks in, when the in-App-Store search ranking started to climb.
Keyword settings (the "Keywords" field in App Store Connect) matter. Beyond "wallpaper," including compound keywords like "phone background" and "aesthetic iphone wallpaper" made the app surface across a wider range of queries. You can register more terms by packing the 100-character field with commas instead of spaces.
The biggest ongoing cost of running a Rork-built app on the App Store is content updates, not development. Designing a weekly or monthly cadence for adding new wallpapers from the start makes long-term operation far easier. I keep a stock of images a month ahead so updates never stall.
For anyone about to do the same with Rork
Building a wallpaper app with Rork turned out to be a very good entry point into indie development. The simple feature set stays within Rork's strengths, and since the quality of the content (the images) gives the app its character, it's a genre where you can lean on strengths outside engineering.
Rather than aiming for a perfect 100-image app from day one, aim for a curated 10–20 images someone will say "I love this selection" about. Add a save flow that understands the iOS constraint, and an ad design that doesn't break the experience. That order, I believe, is the entry point to indie development that lasts. Start with a single wallpaper you genuinely think is good. Thank you for reading.