iOS developer betas are live: the 90-day sprint before September's public release

WWDC 2026 opened the annual iOS developer beta window. Here's the week-by-week testing and screenshot-update checklist for indie devs and app teams — including why mid-August is when you need to finish, not start.

WWDC 2026 wrapped this week, and with it came the first developer betas for Apple's next OS releases. If you ship on iOS — whether you're an indie dev, app agency, or growth team — the next 90 days are your window to catch breaking changes, adapt to new design patterns, and update App Store assets before the public release lands in September. Here's how to spend that time well.

What to test in the first two weeks

The developer beta is always rougher than it looks. Crashes, layout regressions, and IAP edge cases surface in week one that vendors scramble to patch over the summer. The goal in the first two weeks isn't feature adoption — it's regression triage.

• In-app purchases and subscriptions: StoreKit workflows are frequently affected by OS beta changes. Test your paywall, restore, and upgrade/downgrade flows explicitly. If you use RevenueCat or a similar SDK, check their GitHub for beta compatibility notes before assuming the SDK is clean.
• Privacy manifest compliance: Apple has progressively expanded required-reason API declarations over recent releases. Check whether any new APIs in this cycle require additional manifest entries — Apple typically publishes the updated list in developer documentation within days of the beta dropping.
• Third-party SDKs: Crash analytics, attribution, and ad SDKs are the most common source of beta-day crashes that aren't your fault but show up as your crashes in the dashboard. Audit your SPM or CocoaPods manifest before filing radars.
• Localized layouts: New typography scale or safe-area changes can clip text in languages with longer strings — German, Finnish, Arabic. If you ship in 10 or more languages, run a smoke test on at least a German and an Arabic locale before week three.

The screenshot window: plan updates by week six

App Store screenshot specifications are tied to device generations. New OS releases sometimes coincide with display dimension changes, and when Apple updates its required device sizes, your existing sets can become outdated or visually inconsistent with the new design language shown to searchers on the results page.

Reports from early beta testers following WWDC 2026 suggest the design system has continued to evolve from last year's Liquid Glass introduction, with refinements to dynamic material rendering and typography. Whether or not your screenshots show live UI, assets that look current signal to users that your app is actively maintained — and apps that appear “last generation” tend to see measurable conversion drops when the public OS ships in September.

A recurring pattern: apps that update screenshots and feature images in August — before the public release — tend to hold or improve conversion rates during the September upgrade surge. Apps that wait until October miss the highest-traffic week of the year for the App Store.

If you publish in multiple markets, this is the right window to refresh localized screenshots at scale. The cost and lead time of updating screenshots in 12–39 languages during the beta window is significantly lower than scrambling after launch — when competitors have already updated and your older assets are live for millions of searchers. See how screenshot localization cost breaks down by language count to plan your budget now rather than in August.

The Android side: keep Android 16 on the radar too

For cross-platform teams, Google I/O 2026 (May) and Android 16's general availability mean a parallel sprint running alongside the iOS beta window. The key difference is timing: Android 16 is already shipping, so for Google Play the window is now rather than in September.

For Android, the large-screen adaptivity requirements that shipped with Android 16 are now enforced on new app submissions targeting API 36+. If your app scales up a phone layout to a tablet rather than adapting, Play Store review may flag it. A day testing on a Pixel Tablet emulator is worth scheduling before your next production release.

A realistic sprint timeline for small teams

Most indie developers and small app teams can't run a dedicated OS-compatibility project. Here's a practical priority order that fits alongside normal shipping:

1. Weeks 1–2: Install the beta on a spare device (not your daily driver). Run through core flows and note crashes. File issues upstream to SDK maintainers — don't fix their bugs yourself.
2. Weeks 3–6: Update critical third-party SDKs. Fix IAP flows. Check the privacy manifest. If your app uses on-device AI APIs, verify behavior under the new OS runtime.
3. Weeks 6–8: Update App Store screenshots and feature graphic. If you use a localization service for multiple markets, place the order now — turnaround on sets covering 20+ languages is typically 5–10 business days. See AppsOps pricing for current rates.
4. Weeks 8–12: Submit an updated build. Apple typically opens submissions targeting the new OS 2–3 weeks before public release. Aim to be live on launch day, not the week after.

The developers who do best at the annual September cycle treat the beta window as a scheduled project, not a fire drill. Ninety days sounds like plenty of time. It goes fast.

Sources and further reading

• Apple Developer (developer.apple.com) — OS beta downloads, API diffs, required-reason API documentation
• Android Developers (developer.android.com) — Android 16 API 36 migration guide and large-screen requirements
• RevenueCat (revenuecat.com) — SDK beta compatibility notes, State of Subscriptions report
• 9to5Mac (9to5mac.com) — WWDC 2026 coverage and developer beta reporting