Automagically: Easy Splash Screen (Default.png)

In my recent post about reducing load time for iOS apps, I discussed the importance of a proper Default.png. In the past I’ve made my Default.png “splash screen” image manually from mock ups and screenshots from the simulator — it can be very tedious with mixed results.

There is another way.

Before I show you, you need to know something — it uses a private API function. What does that mean? You need to remove this code before you submit your app to the App Store or it will be rejected. Private APIs are functions not to be used by anyone but Apple. So without further ado:

[[UIApplication sharedApplication] _writeApplicationDefaultPNGSnapshot];

That’s it. You should put this code somewhere in your viewDidLoad function before you load all (but after you load some) of your UI elements. You’ll have to be the judge of the appropriate timing. Once this function is run, it’ll store a PNG screenshot of your application in the following location:

Library/Application Support/iPhone Simulator/VERSION/UDID/Caches/BUNDLEIDENTIFIER/AppSnapshots/

QUICK! Get the screenshot and get outta there — then remove that function.

Post-Release Development Bundle Identifiers and Display Names

So you’ve released version 1.0 and it’s in the App Store but you’ve noticed a few bugs and there are still those features you were holding out until 1.0.1. You tweak some code and test on your device but now you’ve lost the current release version because they both have the same bundle identifier. Sometimes …most of the time, as a developer it’s important for you to have both the current release version AND the current beta version on your device. Project’s aren’t configured like this out of the box but it is certainly possible to make this happen without manually changing the bundle identifier every time by way of User Defined Build Settings and variables.

If you take a look at your Application’s plist, you’ll see your bundle name, and bundle identifier along with other information about your app. You’ve probably seen a few fields that include variables that look like this: ${PRODUCT_NAME} or ${EXECUTABLE_NAME}. We’re going to use that system to change the bundle identifier and the bundle display name dependent on the build-type (Debug, Release, Ad Hoc, etc).

To get started, open up your Application Target and click the Build Settings tab:

Once you have this open, click the “Add Build Setting” button in the lower right corner:

Then click “Add User-Defined Setting”. You’ll see XCode adds a section named “User-Defined” and a new setting for you to type in. Type in BUNDLE_DISPLAY_NAME_SUFFIX and hit enter. We’re going to use this as a string to append to our bundle display name (the name of the app that shows on the springboard). Now you should see this:

You can enter in whatever value you like for debug, a few common or recommended ones are “Beta”, “B”, ß but you can use whatever you want. Don’t enter a value in for release as we don’t want to append anything when we build for release as that build should be headed for the app store.

Next, let’s add another User Defined Setting and called this one BUNDLE_IDENTIFIER_SUFFIX. For this you can, again, enter any value you like for Debug. This is appended to the bundle identifier and since an iOS requires unique bundle identifiers this beta version of the app needs one different than the release version. I usually use ‘.dev’ for this field but you could use something like ‘.beta’ or whatever you’d like. So now your settings should look similar to this:

Now that we have the variables set let’s go to the application’s plist and use them. In the bundle display name field simply append ${BUNDLE_DISPLAY_NAME_SUFFIX} to whatever is already there. Move on to the Bundle identifier field and add ${BUNDLE_IDENTIFIER_SUFFIX} and append that to the existing data there. When complete, you’ll see something like this:

Now you’re set. When you build for Debug releases your app will be named with your appended string as well as your bundle identifier. You’ll be able to keep the current release from the app store installed as well as your development build build XCode or TestFlight!