I recently set out to re-write one of my apps. The app currently supports iPhone and iPod touch screens up to and including the 4″ displays. There are a handful of “Default” launch screens to support essentially 2 screen sizes in 2 resolutions. When looking at also supporting iPhone 6, 6+, and iPad screens for the rewrite, the number of “Default” launch images gets crazy. This model doesn’t scale. Xcode6 introduced the ability to create a launch screen using a XIB file, which has been widely written about. The limitation, or so it is suggested, is that Launch Screen XIB files really are not meant to be used other than for displaying a static screen, and iOS takes care of displaying it. If you want your beautiful launch screen to be more than just a placeholder seen for a split second, keep reading.

Xcode6 has really advanced the state-of-the-art for UI design in the Apple ecosystem. Building on Auto Layout and storyboards, Xcode6 adds something called size classes and this notion of a Launch Screen XIB. In fact, when you create a new project using Xcode6, the template includes an automatically generated Launch Screen XIB with the name of your app and a copyright notice.

There are some great things about this. First off, using Auto Layout in the Launch Screen XIB (which is just a UIView with some UILabel subviews in its most simple form) in combination with size classes means your single launch screen works on every screen size Apple currently has, or will have in the future. Say goodbye to all those “Default” launch images, and hello to a single launch image resource.

Now at first blush, it does seem like this launch screen XIB isn’t good for much other than providing an easy way for iOS to show something to the user while it loads your app. But upon further inspection, the launch screen XIB is just a XIB. Why can’t we use it and manipulate it and show it to the user while we actually do something in the background after iOS loads our app but before we’re ready to have the user start using the app. We can!

Enter a new CocoaPod I’ve created called LaunchScreen. It defines a class, LaunchScreenViewController, which you can instantiate from your app delegate or your initial view controller. Your LaunchScreenViewController can then be used in a couple ways either individually or in concert, as you see fit.

There is only one requirement, which is that in order for your launch screen view to be rendered at the correct size for your device you must add a UIViewController to your storyboard, set its class to LaunchScreenViewController and set its storyboard identifier to LaunchScreenViewController (although you can use an identifier of your own choosing if you like). It was not possible simply to load via UINib the Launch Screen XIB and be left with a UIView of the correct size. Using a view controller in the storyboard with a UIView (and nothing else) provides an appropriately sized base view for whatever device the app is running on.

Once things are setup correctly, you can grab a UIImage snapshot of your LaunchScreenViewController’s rendered view. It’s view has, as a full-screen subview, the UIView (and its subviews, of course) from your Launch Screen XIB. You can do this as many times as and if you require.

More powerful though is that you can take your LaunchScreenViewController’s view and add UIKit elements to it (like a UIActivityIndicatorView) and add it as a subview of your UIWindow or main view controller’s view. When you think your user has appreciated your lovely splash screen long enough (or your app has finished its startup work), simply remove that view from its superview and carry on.

There’s an example project in the CocoaPod github repo for LaunchScreen, along with a detailed README. Enjoy!