There was a moment — before I started the actual work — when I genuinely believed Antigravity could handle the whole thing in one shot.
In May 2026, I set out to update four iOS apps (Beautiful HD Wallpapers, Ukiyo-e Wallpapers, Relaxing Healing, and Law of Attraction Everyday) for new iPhone models. These four apps together account for over 50 million downloads. The work I thought would take a few hours ended up requiring 29 individual edits to DefineManager.h. Antigravity caught most of them — but not all. Here's what actually happened.
Why iPhone Resolution Support Keeps Getting Harder
If you've shipped an iOS app for more than a few years, you already know the feeling. Every new device generation adds a screen size that your existing point-to-pixel mapping doesn't account for. By mid-2026, the relevant screen sizes (in points) look like this:
- iPhone 16 / 17: 390×844
- iPhone 16 / 17 Plus: 430×932
- iPhone Air (new): 420×912
- iPhone 16 Pro: 393×852
- iPhone 17 Pro (new): 402×874
- iPhone 16 Pro Max: 440×956
- iPhone 17 Pro Max: 440×956 (same)
For a wallpaper app, this matters a lot. Serving a "Plus-sized" image to an Air-sized screen leaves content cropped or aspect-ratio-broken. All of that branching lives inside DefineManager.h — a growing chain of ternary operators that I've been adding to since 2013. By this update, 29 entries needed touching.
The First Prompt I Sent
My opening message to Antigravity was straightforward:
Check the device detection section of DefineManager.h and add support
for iPhone Air (420×912) and iPhone 17 Pro (402×874).
Follow the existing ternary operator pattern.
Antigravity opened the file, read the existing pattern, and added the new conditions cleanly. No typos, correct formatting. Then I ran the simulator — and found the problem.
What Antigravity Missed
Certain resolution buckets were switching correctly; others were still pulling from the wrong size tier. After some digging, I found that DefineManager.h has several independent reference points, not just one:
- Thumbnail resolution definitions: Updated ✓
- Full-size download resolution definitions: Updated ✓
- Preview resolution (shared constant leftover from Play Store logic): Missed ✗
- Cache key generation (includes resolution string): Missed ✗
- OGP image generation helper (shared definition): Missed ✗
When I told Antigravity "find all other places in the project that use the same device-detection pattern," it found four more. The cache key issue I caught myself — Antigravity didn't flag it until I asked directly.
Where Antigravity Genuinely Helped
For all my caveats, 29 edits would have taken considerably longer without Antigravity. Here's what it handled well:
1. Reading and replicating the existing pattern
Long ternary chains are error-prone when written by hand. Antigravity read the existing structure and extended it in exactly the same style. That consistency is hard to maintain manually across dozens of entries.
2. Exhaustive in-file search
When asked to "list every location where device size detection occurs in this file," it ran a pattern-based search and returned a comprehensive list faster than I could scroll through manually.
3. Simulator setup guidance
I didn't have an iPhone Air simulator preset available in Xcode yet. Antigravity explained how to add a custom simulator device through Devices and Simulators → +, using the exact point dimensions. That's not hard to find in the docs, but having it surface immediately saved a few minutes of searching.
The Two-Step Prompt Pattern That Worked
From this experience, I've settled on a two-step approach for any device-specific code changes:
[Step 1 — Enumerate]
List every location in DefineManager.h where UIScreen.main.bounds.size
is used for device detection. Include both direct references and any
constants or helper functions that rely on it.
Give me file names and line numbers.
[Step 2 — Narrow and fix]
From that list, which locations need to be updated for iPhone Air
(420×912) and iPhone 17 Pro (402×874)?
Update only those locations, following the existing ternary pattern.
The "one-shot fix" instruction tends to lead Antigravity to update the most obvious locations and stop. The explicit enumerate-then-narrow flow surfaces the less obvious ones.
A Side Issue: Android Density Splits
While updating the iOS apps, the Android versions ran into a separate problem. With Play Store density splitting enabled, wallpaper samples placed in drawable-nodpi/ were disappearing on low-density devices.
Antigravity's suggestion was to either move the assets to drawable/ or revisit the density split settings. We kept drawable-nodpi/ and fixed the resource bucketing instead. The more useful lesson: when iOS and Android problems are happening simultaneously, keep separate chat sessions. Mixing context caused noticeably more confused responses.
After 29 Edits
Beautiful HD Wallpapers v2.1.0 shipped with iPhone Air and iPhone 17 Pro support. After the staged rollout (5% → 25% → 50% → 100%), there were zero resolution-related crashes. That was a relief.
But I didn't walk away feeling like AI had done the work. The honest experience was that Antigravity handled about 70% of the edits confidently, flagged a few edge cases when asked directly, and missed some non-obvious references that I caught through manual review. That ratio feels about right for this kind of structural change across a legacy codebase.
I've been developing apps independently since 2013. Getting to 50 million downloads doesn't happen by cutting corners on this kind of verification work. My grandfather was a shrine carpenter who used to say that careful handwork is its own form of devotion. Twelve years into indie development, I still think about that when I'm doing the final review pass after an AI has done the heavy lifting.
The next new iPhone announcement will bring another round of this. The prompts I refined this time will make it faster — but the final check will still be mine.