In mid-May I put an iPad mini on the right side of my desk and started the work I had put off for years: making a Rork-scaffolded wallpaper app actually presentable on iPad. I am Masaki Hirokawa, an artist and indie developer. I have run wallpaper apps since 2014, and even after the portfolio crossed 50 million downloads on iPhone, iPad was always slotted into the "deal with it later" pile. These are field notes from two weeks of finally dealing with it on a Rork-generated app.
Why iPad finally got my attention
For years I had treated iPad as "supported, but not really tuned." I would set SupportedInterfaceOrientations, ship the iPhone layout stretched vertically, and move on. Several of my older apps are still in that state, honestly.
What pulled me back was watching App Store Connect metrics for the new wallpaper app I scaffolded with Rork. iPad accounted for 12.8% of launch sessions and 8.4% of new downloads, which is well above the "under 5%" figure I had been carrying in my head for a decade. Across 50 million total downloads on iPhone, I had simply never looked at iPad as its own slice.
The Rork-generated project builds for iPad out of the box because Expo includes iPad as a target. But "the build passes" and "the app is usable on iPad" turned out to be two weeks of work apart.
What Rork ships by default on iPad
Before changing anything I wanted to see how far the Rork defaults take you on iPad.
Launch worked. No errors, the app renders, the navigation stack behaves. If your only goal is to ship to the iPad section of the App Store, you are fine. The first time you actually use it on hardware, though, you see a stretched iPhone:
- Hero images fill the width but gain too much vertical whitespace on top and bottom, breaking the composition
- The wallpaper thumbnail grid stays at 2 columns, so each tile becomes roughly the size of an iPhone 12 Pro screen
- The bottom tab bar stays pinned, with the icons spaced out across a much wider strip
- The AdMob banner does something unexpected (covered below)
I do not see this as a Rork shortcoming. The point of Rork in my workflow is to bootstrap iPhone and Android together as quickly as possible. iPad tuning belongs in a separate pass, and for my pipeline that division of labor is honestly easier to live with.
Safe Area and Dynamic Type, the first wall
The first real friction was Safe Area handling combined with Dynamic Type.
iPad Safe Area behaves very differently from iPhone, especially on M2-era iPad mini and iPad Air in landscape. With the default Rork output the hero image clipped slightly into the Home Indicator area when held sideways. The starter code was reading the top and bottom insets but ignoring left and right, which is fine on iPhone and breaks on landscape iPad.
The fix was to push the SafeAreaProvider to the top of the tree and pull left/right insets from useSafeAreaInsets into the hero container's padding. That single change took most of the landscape awkwardness out.
Dynamic Type was the other half of the wall. When you crank "Settings → Accessibility → Larger Text" to the maximum, the category tab labels wrap to two lines and the layout collapses. Adding numberOfLines={1} and adjustsFontSizeToFit to those labels prevents the wrap. The same bug exists on iPhone, but on iPad's wider screen the broken layout is far more obvious.
The AdMob adaptive banner running wild on iPad
This was the part that ate most of my two weeks.
I had been relying on AdMob adaptive banners as a "just works" surface. They are reliable on iPhone and a meaningful slice of my monthly AdMob revenue comes from them. On iPad, calling the exact same adaptive banner produced a banner near 150pt tall instead of the 90pt-ish height I was used to, and that ate into the bottom action area.
This is documented behavior. Adaptive banners scale their height with container width, so when the container is iPad-wide the height grows. For a wallpaper app, though, the wallpaper itself is the product. Letting the banner take that much screen on iPad makes the experience cheap.
I split the response into two steps:
- Stop letting the banner go full-width on iPad. Cap the container at 728pt (the conventional tablet banner width) and pad either side with spacers.
- Add 8pt of breathing room above the bottom Safe Area inset so the banner stops sitting flush against the home gesture area.
The eCPM on iPad fell a bit relative to the unconstrained adaptive banner, but Day 1 retention on iPad recovered from 21.3% before the change to 28.1% three weeks later. The right way to read that number is not "ads matter for retention" but "feeling like the app respects you matters for retention."
The resolution problem hiding in the grid
The next pain point was the wallpaper thumbnail grid.
Two columns was fine on iPhone. On iPad with two columns, each thumbnail becomes so large the page stops feeling like a gallery. I added breakpoints: 3 columns at 640pt width, 4 columns at 900pt width.
The catch is that the source images on my CDN had been optimized for the iPhone 2-column case, mostly around 1290px wide. Blown up into 4 columns on iPad they were visibly soft. Tuning expo-image's contentFit and transition was not enough; I ended up re-exporting the top 240 wallpapers at 2x resolution using a Mac Automator + sips batch overnight, then swapping them on Cloudflare R2 the next morning.
Both of my grandfathers were temple carpenters. The paternal side worked on restoration at Horyu-ji; the maternal side built shrines and small temples in his region for a lifetime. What I watched in their workshops as a kid was that nobody ever cut corners on the side of the work that "isn't seen." That habit makes it hard for me to leave the iPad rendering coarser than the iPhone one. It is the same instinct showing up in a different medium.
Landscape behavior, finally taken seriously
iPad users hold the device sideways far more often than iPhone users. On this app, 32.8% of iPad launch sessions are in landscape, against 3.4% on iPhone. The priority for taking landscape seriously is just different.
For a decade I had assumed wallpaper apps are "obviously portrait" and treated landscape as a non-goal. With this app I had to actually decide: support it, or lock it out cleanly. I landed on a hybrid. The wallpaper preview screen stays locked to portrait because the artwork is meant to be viewed that way. Everything else (list, categories, favorites, settings) accepts landscape. Expo's top-level orientation config can't toggle per screen, so I added expo-screen-orientation and called the appropriate lock on navigation transitions.
What two weeks of iPad-focused work actually changed
The biggest lesson is unflattering: working with an iPad-first mindset surfaced bugs that had always existed on iPhone too.
The Dynamic Type breakage, the missing landscape Safe Area, the cramped bottom strip above the AdMob banner. All of it had been hiding in plain sight on iPhone because the smaller screen was forgiving. Once the screen got wider, the rough edges had nowhere to hide.
The numbers from the three weeks since: iPad Day 7 retention recovered from 11.6% to 18.4%. iPad AdMob revenue grew a modest 6%. Average review score from clearly-iPad-attributable reviews rose from 3.9 to 4.4 across 14 new reviews in two weeks. The review sample is too small to draw a real conclusion, but it feels right.
What is still on the list
Plenty of homework remains:
- Test the app properly under Stage Manager on the M1 iPad Pro I own
- Adopt a Sidebar Navigation pattern on iPad to use the landscape width as "vertical card list plus side-by-side preview"
- Keyboard shortcut support for iPad (arrow keys to walk through wallpaper categories)
Stage Manager is the one I had ignored hardest. I personally rarely use it, but a few users contacted me about ad positioning misbehaving when the app shares the screen with another window, and that bumped Stage Manager up the queue.
Twelve years into running wallpaper apps, iPad has lived as a permanent afterthought. Being able to finally focus on iPad on this Rork-scaffolded app came down to a workflow shift: Rork handled iPhone and Android quickly enough that, for the first time, I had spare time to spend on iPad alone. That, more than anything, is what made the catch-up possible.
If you have been deferring iPad work on your own indie apps, hopefully something in here saves you a day or two.