The iOS 27 Launch Screen Rule: Four Keys or Rejection

Apple’s iOS 27 release notes convert a documentation sentence into a submission gate: “iOS and iPadOS apps built with the 27.0 SDK or later are required to include a launch screen. Your app’s Info.plist must contain one of the following keys: UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen, or UILaunchScreens. Apps that don’t include a launch screen are rejected when the App Store begins accepting apps built with the 27.0 SDK.”¹

The requirement itself is old. Apple’s Xcode guide opens with “Every iOS app must provide a launch screen.”² What arrives in iOS 27 is the consequence for ignoring it.

TL;DR

• Apps built against the iOS 27.0 SDK or later must declare a launch screen through one of four Info.plist keys, and the App Store rejects builds that don’t.¹
• The gate is submission, not runtime. Apple’s language is “rejected when the App Store begins accepting apps built with the 27.0 SDK,” so the failure lands in App Store Connect rather than on a user’s device.¹
• The rule names iOS and iPadOS and stops there. Apple does not extend it to tvOS, visionOS, or Mac Catalyst in the same note.¹ The scene life cycle mandate landing in the same cycle reads differently: its migration guide binds iOS 27, iPadOS 27, Mac Catalyst 27, tvOS 27, and visionOS 27 by name.³
• Two keys cover a single launch screen (UILaunchScreen builds one in the property list, UILaunchStoryboardName names a storyboard file) and two cover per-URL-scheme variants (UILaunchScreens, UILaunchStoryboards). Three of the four are dictionaries; UILaunchStoryboardName alone is a string.⁴⁵⁶⁷
• Projects created from recent Xcode templates already satisfy the rule, and they satisfy it through a build setting rather than a file.⁸¹¹ Auditing by grepping your repository for the four keys therefore misses the answer entirely.

The rule, stated precisely

Three details in Apple’s sentence carry weight, and coverage tends to blur all three.

First, the trigger is the SDK you build against, not the OS your users run. A binary compiled against iOS 26 keeps its place on the store. Rebuild with Xcode 27 to pick up anything from the new SDK and the requirement rides along.

Second, the enforcement point is App Store acceptance. Apple wrote “rejected,” which places the failure at submission review rather than at launch. That distinction separates the launch screen rule from the scene life cycle mandate shipping in the same cycle, where Apple’s wording is that apps “fail to launch.”¹ One costs you a rejected build; the other costs you a dead app on a user’s phone.

Third, the scope is iOS and iPadOS. Apple’s note names those two platforms and stops. Anyone maintaining a Catalyst or tvOS target should read the requirement as unstated rather than as extended by analogy. The 27 cycle enforces plenty elsewhere, from the scene life cycle across five platforms to ImageCreator’s removal from Image Playground, but the launch screen note stays narrow.

Which of the four keys applies

Apple offers two ways to build a launch screen and two cardinalities, which produces the four keys.

UILaunchScreen configures the launch interface directly in the property list, with no storyboard file involved. Apple describes it as the way “to configure the user interface during app launch in a way that doesn’t rely on storyboards,” and it accepts child keys for the background color, image, and the visibility of the navigation bar, tab bar, and toolbar.⁴ For an app whose first screen is a plain background, an empty UILaunchScreen dictionary satisfies the rule. Xcode’s own build system takes that route: “When GENERATE_INFOPLIST_FILE is enabled,” INFOPLIST_KEY_UILaunchScreen_Generation “sets the value of the UILaunchScreen key in the Info.plist file to an empty dictionary.”⁸

UILaunchStoryboardName points at a storyboard by filename, minus the extension: a LaunchScreen.storyboard file becomes the string LaunchScreen.⁵ It dates to iOS 9, and it is the only one of the four that takes a string rather than a dictionary.⁵ Apps with a designed launch state, or any project that ships the LaunchScreen.storyboard Xcode still adds to its storyboard templates, want this key.²

The plural forms exist for one specific case, and both are dictionaries rather than arrays.⁶⁷ UILaunchScreens holds three child keys: UILaunchScreenDefinitions, the array of launch screen configurations, each carrying a UILaunchScreenIdentifier; UIURLToLaunchScreenAssociations, the map from URL scheme to identifier; and UIDefaultLaunchScreen, the fallback.⁶ UILaunchStoryboards mirrors the shape with UILaunchStoryboardDefinitions, UIURLToLaunchStoryboardAssociations, and UIDefaultLaunchStoryboard.⁷ Either one lets an app opened from myapp://compose present a different launch state than the same app opened from the home screen. Apple is direct that most apps should skip them: “If you need only one launch screen, use UILaunchScreen instead.”⁶

The practical decision collapses to one question. If your launch screen is a storyboard, declare UILaunchStoryboardName. If it isn’t, declare UILaunchScreen. Reach for a plural key only when you already know why you need one.

The apps that are actually caught

An app created from a current Xcode template passes without anyone touching it, which is exactly why the rule is easy to dismiss and easy to get caught by. The population at risk shares one trait: nobody on the team wrote the Info.plist by hand recently.

Generated property lists are the largest category, and Xcode itself is the largest generator. Xcode 13 changed the default: projects created from several templates “no longer require configuration files such as entitlements and Info.plist files,” and you configure the fields in the target’s Info tab and the build settings editor instead.⁹ Cross-platform toolchains, wrapper frameworks, and build scripts that synthesize a plist at package time add a second layer, and their templates may predate UILaunchScreen entirely. Nobody reviews a file the build system writes.

Stripped plists are the second category. Launch storyboards get deleted during size optimization, during a migration away from Interface Builder, or during a cleanup that removed the last storyboard in the project and took the launch screen with it. The app kept building, so the removal looked safe.

Inherited projects are the third, and the cohort is narrower than most coverage assumes. UILaunchStoryboardName shipped in iOS 9, so a project carried forward from 2015 already holds a qualifying key.⁵ The apps holding none of the four are older than that: the ones still declaring launch artwork through UILaunchImages, the iOS 7.0 key Apple deprecated at iOS 13.0 with a single instruction, “UILaunchImages has been deprecated; use Xcode launch storyboards instead.”¹⁰ A UILaunchImages array is not on Apple’s list of four, so a project that still relies on it and never adopted a storyboard reference has nothing the requirement accepts. A decade of Xcode upgrades will not have added one, because nothing in the build ever failed.

Auditing an Info.plist the build system writes

Start by accepting that the file may not exist. GENERATE_INFOPLIST_FILE turns on automatic generation, and each INFOPLIST_KEY_* build setting writes one key into the plist the build produces.⁸ Launch screens get two of those settings: INFOPLIST_KEY_UILaunchScreen_Generation, which writes an empty UILaunchScreen dictionary, and INFOPLIST_KEY_UILaunchStoryboardName, which writes the storyboard name.⁸ Neither leaves anything for a text search to find. Xcode’s current iOS SwiftUI App template ships INFOPLIST_KEY_UILaunchScreen_Generation = YES in its shared settings, so a project created that way holds a compliant target with no launch screen text anywhere in the repository.¹¹

Ask the build system instead of the filesystem:

xcodebuild -showBuildSettings \
  -project YourApp.xcodeproj -target YourApp \
  -configuration Release -sdk iphoneos 2>/dev/null \
  | grep -E "^ +(GENERATE_INFOPLIST_FILE|INFOPLIST_FILE|INFOPLIST_KEY_UILaunch)"

Run against the Ace Citizenship project on my machine, three lines come back:¹¹

    GENERATE_INFOPLIST_FILE = YES
    INFOPLIST_FILE = Ace-Citizenship-Info.plist
    INFOPLIST_KEY_UILaunchScreen_Generation = YES

The third line is the whole compliance answer, and no file in the repository contains it. Read the output in that order. GENERATE_INFOPLIST_FILE = YES plus an INFOPLIST_KEY_UILaunch line set to YES means the build system writes the key for you: Apple gates every INFOPLIST_KEY_* setting on generation being enabled, so the same line reads as inert under GENERATE_INFOPLIST_FILE = NO, and a value of NO writes nothing either way.⁸ With generation off, an INFOPLIST_FILE path is where your launch screen key has to be, so open that file and look for one of the four. With generation on and a file path present, the build system merges the two and either source satisfies the requirement.⁸

Both flags earn their place. -configuration Release matters because App Store review sees the Release product. -sdk iphoneos matters because Xcode writes these settings per SDK on multiplatform targets: the Reps project declares INFOPLIST_KEY_UILaunchScreen_Generation three times, once each for [sdk=iphoneos*], [sdk=iphonesimulator*], and [sdk=appletv*], and Banana List declares the first two. Drop -sdk iphoneos and none of them resolves, so the key vanishes from the output and a compliant target reads as exposed.¹¹

Then check the artifact you actually submit. In plutil -p output, two leading spaces mark a top-level key:

plutil -p YourApp.xcarchive/Products/Applications/*.app/Info.plist \
  | grep -E '^  "UILaunch'

Against a Return archive built for distribution in April, one line comes back, and the same command against a bundle with no launch screen prints nothing and exits 1:¹¹

  "UILaunchScreen" => {

Reach for plutil rather than PlistBuddy here. Given a path that doesn’t resolve, PlistBuddy -c "Print" writes “File Doesn’t Exist, Will Create:” and an empty Dict { } to standard output and exits 0; pipe that into a grep for the launch screen keys and the only line revealing the mistake gets swallowed, leaving empty output that reads exactly like a missing key. plutil names the file it couldn’t open and exits 1.¹¹

A repository sweep still has a job, but a smaller one than it looks: finding hand-maintained plists worth reading.

find . -name "Info.plist" \
  -not -path "*/build/*" -not -path "*/DerivedData/*" \
  -not -path "*/.build/*" -not -path "*/Carthage/*" -not -path "*/Pods/*" \
  -print0 | xargs -0 grep -L -E "UILaunchScreen|UILaunchStoryboard"

Every path it prints is a candidate to check against build settings, not a target that will fail submission. On Banana List the command returns exactly one line, ./Banana List/Info.plist, and that target ships a launch screen anyway: its build settings carry INFOPLIST_KEY_UILaunchScreen_Generation, and the archived bundle contains UILaunchScreen. Without the exclusions, the same command returns 25 lines on that repository, 24 of them build artifacts inside build/, including test-runner bundles, XCTest.framework, an .xcresult log, and a watch app.¹¹

Adding the key by hand takes a few steps rather than a text edit. Apple’s sequence: in the settings for your target, select the Info tab; in the Custom iOS Target Properties section, expand the Launch Screen key; click the Add button, type UILaunchScreen, and press Return; then select the UILaunchScreen key, click Add again, and add child keys for the appearance options you want.² On an Xcode-generated plist, setting INFOPLIST_KEY_UILaunchScreen_Generation to YES in the target’s build settings does the same job and survives the next build.⁸ For a plist generated by something other than Xcode, patch the generator’s template; the next build discards anything you edit in the output.

What the rule does not say

Apple has not published a calendar date. The trigger is phrased as “when the App Store begins accepting apps built with the 27.0 SDK,” which historically falls near the fall OS release but which Apple has not committed to in writing for this cycle.¹ Treat any specific date you read as inference.

Apple also has not said that existing apps stop working, that TestFlight builds are affected, or that the requirement extends beyond iOS and iPadOS. The note covers submission of new builds and nothing else.

The fix is small enough that the interesting question is not how to comply but whether you already do. For a hand-maintained project the answer is almost certainly yes. For anything with a generated plist, the answer is worth confirming with the build system before the store starts saying no.

FAQ

Does an app built from a current Xcode template already comply?

Almost certainly, and the evidence lives in build settings rather than in a file. Xcode’s iOS SwiftUI App template sets INFOPLIST_KEY_UILaunchScreen_Generation = YES in its shared settings, which writes an empty UILaunchScreen dictionary into the Info.plist the build system produces.⁸¹¹ Confirm it by running xcodebuild -showBuildSettings for the Release configuration with -sdk iphoneos and looking for an INFOPLIST_KEY_UILaunch line.

Why does grepping my repository for UILaunchScreen find nothing?

Because since Xcode 13, projects created from several templates carry no Info.plist on disk; Apple moved those fields into the target’s Info tab and the build settings editor.⁹ The launch screen arrives from INFOPLIST_KEY_UILaunchScreen_Generation or INFOPLIST_KEY_UILaunchStoryboardName at build time.⁸ A text search over source files cannot see either setting, and the Info.plist files it does find are usually partial fragments the build system merges, or build artifacts under build/ and DerivedData/.

Which key should I add if I genuinely have none?

UILaunchStoryboardName if you ship a LaunchScreen.storyboard, and UILaunchScreen if you don’t.⁴⁵ An empty UILaunchScreen dictionary is enough for an app that launches on a plain background, which is what Xcode generates by default.⁸ Skip UILaunchScreens and UILaunchStoryboards unless you present different launch states for different URL schemes; Apple’s own guidance is “If you need only one launch screen, use UILaunchScreen instead.”⁶

Does the requirement apply to TestFlight builds?

Apple’s note does not say. It names one consequence, rejection “when the App Store begins accepting apps built with the 27.0 SDK,” and TestFlight distribution appears nowhere in it.¹ Because TestFlight builds pass through App Store Connect and beta review, the safe assumption is that a build failing the requirement fails everywhere it meets review, but Apple has not written that down. Anyone depending on the answer should test a 27.0-SDK upload rather than trust either reading of the silence.

Key Takeaways

For iOS developers: - Query build settings before you grep files. Run xcodebuild -showBuildSettings -configuration Release -sdk iphoneos and look for INFOPLIST_KEY_UILaunchScreen_Generation or INFOPLIST_KEY_UILaunchStoryboardName.⁸ A repository text search cannot see either one. - Choose UILaunchStoryboardName if you ship a launch storyboard and UILaunchScreen if you don’t. Skip the plural keys unless you serve different launch states per URL scheme.

For teams shipping through cross-platform toolchains: - Audit the archived .app bundle with plutil -p, not the file in source control. The generator’s output is what review sees, and plutil fails loudly on a bad path where PlistBuddy prints an empty dictionary and exits 0. - Patch the plist template in your build configuration rather than the generated file, or the next build discards the fix.

For release managers: - The failure surfaces at App Store submission, not at runtime, so it costs you a review cycle rather than a production incident. Schedule the audit before the first 27.0-SDK submission, not after a rejection. - Pair the check with the scene life cycle migration, which shares the same trigger and carries a harsher penalty.

The 27 cycle keeps converting suggestions into enforcement: ImageCreator stops working, the scene life cycle becomes a launch requirement, and the launch screen becomes a submission gate. For the rest of what ships in the same SDK, see What’s New in SwiftUI for iOS 27. The full series hub is the Apple Ecosystem Series.

References