Supporting iPhone Air and 17 Pro Max New Resolutions Across Six Apps in Parallel

The prompt I gave Claude on Xcode

Inside Xcode, the template I used with Claude on Xcode was deliberately conservative.

## Context
- Target: DefineManager.h (shared macro definitions)
- Existing macros: 16-device IS_IPHONE_* checks + 29 ternary-chain macros
- New devices: iPhone Air (420×912) / 17 Pro (402×874) / 17 Pro Max (440×956)
- Rules:
  - Do NOT reorder existing branches
  - Insert each new device branch in narrowest-screen-first order
  - Preserve indentation and inline comments on existing branches
 
## Ask
- Produce a patch adding the three new device branches to every one of the 29 chains
- Each hunk must be ≤ 6 lines so it stays reviewable

"Do not reorder" and "preserve comments" are the two phrases that matter most for files like this. If you let the model regenerate the file fluently, six months later it becomes unreviewable.

Claude on Xcode returned 29 small hunks. I reviewed them in the Xcode sidebar one by one. Total time to apply the entire patch with reviews: about two hours.

Synchronizing six apps with defineManagerSync.sh

All six apps have their own DefineManager.h. I've tried both the "single source + patches" and "fully independent per app" approaches over the years, and I now keep them independent. Each app diverges in ad-gate logic and theme color enums, and shared headers tend to break in subtle ways the moment you do.

What I share is a tiny diff script. Right before each release I run:

#!/usr/bin/env bash
set -euo pipefail
 
apps=(
  "BeautifulWallpapers"
  "UkiyoeWallpapers"
  "RelaxingHealing"
  "LawOfAttraction"
  "FractalGalleria"
  "CoolWallpapers"
)
 
REFERENCE="apps/BeautifulWallpapers/DefineManager.h"
 
for app in "${apps[@]:1}"; do
  target="apps/${app}/DefineManager.h"
  if ! diff -q \
    <(grep "IS_IPHONE_" "$REFERENCE" | sort) \
    <(grep "IS_IPHONE_" "$target" | sort) > /dev/null; then
    echo "❌ ${app}: IS_IPHONE_* declarations diverge from ${REFERENCE}"
    diff -u "$REFERENCE" "$target" | head -40
    exit 1
  fi
done
 
echo "✅ Device detection macros are in sync across all six apps"

This compares only the IS_IPHONE_* declarations. Layout values like NAV_BAR_OFFSET differ per app and shouldn't be normalized. The script caught one case where iPhone Air had been added to four apps but accidentally skipped on a fifth.

A 14-day phased rollout without owning the new devices

When you don't have hardware for the new resolutions, TestFlight plus App Store Connect phased rollout becomes your only real verification. I start every phased release at 1%. Across a portfolio that has shipped roughly 50 million downloads over the years, 1% is enough to land tens of thousands of users with the new devices within 24 hours.

My pinned Crashlytics filter for resolution-related issues:

app_version == "3.0.0"
AND device_model starts_with "iPhone18"
AND fatal == true

iPhone18 is the internal model prefix Apple uses for the 17 Pro, 17 Pro Max, and Air. One thing the docs don't tell you: depending on Crashlytics SDK version, the field can be reported under device.model or device.modelIdentifier, and I've been bitten by inconsistent results. I now keep both in the filter.

1% → 10% → 50% → 100% — the gates that got me to zero

The phased rollout schedule I now use, with the gate criterion at each step, looks like:

Day 1: 1%   - 24h watch; resolution filter must be zero events
Day 2: 10%  - 24h; ANR-free; no resolution complaints in App Store reviews
Day 4: 50%  - 48h; if stable, re-enable cross-app push campaigns
Day 7: 100% - Full distribution; Crash-free users must hold ≥ 99.7%
Day 14: Retrospective — decide between keeping the 29 ternary branches as-is or migrating to a table-driven layout

Day 14 is the part of indie release management I most often see skipped. Without that retrospective, your DefineManager.h is one device generation away from being unmaintainable.

Where I'm going next — a table-driven layout

Anticipating that resolution counts will keep climbing, I'm in the middle of moving DefineManager.h to a Swift table-driven layout. Objective-C ternary chains were the right tool when I started this codebase in 2014. At sixteen devices and 29 chains, they're no longer paying their rent.

The shape I'm prototyping is a (modelIdentifier, key) -> CGFloat dictionary with a sensible default fallback for unknown models. I'm letting Claude on Xcode draft it as a Swift Package so each of the six apps can adopt it on its own schedule.

What I've learned in 12 years of indie work is that the right time to refactor isn't "before it breaks" — it's right after the last change that made the existing pattern feel obviously expensive. Having just added 29 branches, I have the cleanest possible picture of what should and shouldn't live in the table.

One thing to try before next year's resolution wave

If you ship any production iOS app, the most useful thing you can do today is launch your app on the iPhone Air, 17 Pro, and 17 Pro Max simulators in Xcode 17, and log both UIScreen.main.bounds.size and UIScreen.main.nativeBounds.size from your application(_:didFinishLaunchingWithOptions:). The logical and physical dimensions for each device are the foundation any future layout logic will sit on top of.

I hope this saves another indie developer a couple of late nights when the next round of resolutions ships. Thank you for reading.