Launch screen not refreshed after app update: is clearing Library/SplashBoard supported?

We're adding an option to our Unity SDK that gives a game a native launch screen: a launch storyboard (set through UILaunchStoryboardName) showing a full-screen image from an asset catalog.

What we see

  • On a clean install, the new launch screen shows as expected.
  • When the same device installs an update over the existing app (tested through TestFlight), the previous launch screen keeps showing. Launching the app several times does not change it.
  • Deleting the app, restarting the device and reinstalling shows the new launch screen straight away.

We checked the build itself: the compiled storyboard, the image in Assets.car and the Info.plist keys are all correct, so this looks like the system's launch screen snapshot cache. We assume App Store updates behave the same way.

What we're considering

On the first launch after an update, the app would delete the cached launch screen snapshots in its own container (Library/SplashBoard), so the system regenerates them and the new launch screen shows on the next launch. This only uses public file APIs inside the app's own sandbox. But Library/SplashBoard is not documented anywhere, so we'd rather ask before shipping it.

Questions

  1. Is deleting Library/SplashBoard from the app's own container a supported or acceptable practice, or could it cause problems (with the system, or in a future iOS version)?
  2. Is there a supported way to make iOS refresh a cached launch screen after an app update?
  3. If not, is the expected behaviour simply that the system refreshes the snapshot at some point? Is it documented when that happens (for example after a reboot, or after a certain time)?

If clearing the folder isn't recommended, we won't ship it. Updating players would just keep the old launch screen until iOS refreshes it.

Thanks!

Answered by DTS Engineer in 915782022

Thanks for checking the compiled storyboard, Assets.car, and the Info.plist keys first, and for asking before shipping the change.

Library/SplashBoard isn't documented. Using the file system effectively describes the directories an app uses for its own files, such as Documents, Application Support, Caches, and the temporary directory. Library/SplashBoard isn't among them, so its contents and how the system uses them are implementation details that can change in any release. Deleting it isn't a supported technique.

I didn't find a supported way to make iOS regenerate a cached launch screen. TN3118: Debugging your app's launch screen covers an outdated launch screen during development. Its remedy is to clean the build folder, remove the app, and run it again. That doesn't help people who install your update over an existing copy. The documentation also doesn't say when the system refreshes the launch screen it shows, whether after a restart or after some amount of time.

Separately, since your launch storyboard shows a full-screen image: Responding to the launch of your app says, "Don't use a static image for your launch screen. In iOS 14 and later, the launch screen is limited to 25 MB." The documentation doesn't connect that guidance to the cached launch screen.

There's also a way to make a cached launch screen matter less: shorten the time anyone sees it. Responding to the launch of your app also says the system "displays your launch storyboard until your app is ready to display its UI." If your app readies its UI quickly, "the user may see your launch storyboard only briefly." Reducing your app's launch time covers measuring and shortening that wait. TN3118 also suggests state restoration, "so that the launch screen is used less often." For a full-screen image like yours, see the Human Interface Guidelines for Launching. They suggest: "If you need a splash screen, consider displaying it at the beginning of your onboarding flow." That puts the image in your app's own first screen rather than in the launch screen.

Please file a bug report in Feedback Assistant about the previous launch screen still appearing after an update. Include two builds or a small project with two different launch screens. Also give the iOS version, the device model, and whether the update came through TestFlight or the App Store. Attach a sysdiagnose captured right after launching the updated app and seeing the old launch screen. If you're seeing the same thing in your own app, please file a report too. Post the Feedback number here, and I'll check its status next time I do a sweep of forums posts where I've suggested bug reports.

Thanks for checking the compiled storyboard, Assets.car, and the Info.plist keys first, and for asking before shipping the change.

Library/SplashBoard isn't documented. Using the file system effectively describes the directories an app uses for its own files, such as Documents, Application Support, Caches, and the temporary directory. Library/SplashBoard isn't among them, so its contents and how the system uses them are implementation details that can change in any release. Deleting it isn't a supported technique.

I didn't find a supported way to make iOS regenerate a cached launch screen. TN3118: Debugging your app's launch screen covers an outdated launch screen during development. Its remedy is to clean the build folder, remove the app, and run it again. That doesn't help people who install your update over an existing copy. The documentation also doesn't say when the system refreshes the launch screen it shows, whether after a restart or after some amount of time.

Separately, since your launch storyboard shows a full-screen image: Responding to the launch of your app says, "Don't use a static image for your launch screen. In iOS 14 and later, the launch screen is limited to 25 MB." The documentation doesn't connect that guidance to the cached launch screen.

There's also a way to make a cached launch screen matter less: shorten the time anyone sees it. Responding to the launch of your app also says the system "displays your launch storyboard until your app is ready to display its UI." If your app readies its UI quickly, "the user may see your launch storyboard only briefly." Reducing your app's launch time covers measuring and shortening that wait. TN3118 also suggests state restoration, "so that the launch screen is used less often." For a full-screen image like yours, see the Human Interface Guidelines for Launching. They suggest: "If you need a splash screen, consider displaying it at the beginning of your onboarding flow." That puts the image in your app's own first screen rather than in the launch screen.

Please file a bug report in Feedback Assistant about the previous launch screen still appearing after an update. Include two builds or a small project with two different launch screens. Also give the iOS version, the device model, and whether the update came through TestFlight or the App Store. Attach a sysdiagnose captured right after launching the updated app and seeing the old launch screen. If you're seeing the same thing in your own app, please file a report too. Post the Feedback number here, and I'll check its status next time I do a sweep of forums posts where I've suggested bug reports.