Preparing the App for Submission

Currently, our app lacks the polish that we’d expect to see on the App Store. There’s more to address than we can really do in a book of this size—entire books are devoted to iOS app design, after all—but at an absolute minimum, we really need a proper app icon. Since we haven’t created one, what we see in our Simulator home screens is the iOS “generic” icon.

App Icons

By default, our app has no icon, and it has the name we gave it when we created the project. It looks like the figure—not pretty.

Let’s get to work on that. We’ll start with the name being cut off. Click on the project icon at the top of the File Navigator, select the Pragmatic Tweets target, and click the Info tab. We can set some of the app’s metadata here, including the Bundle Name, which defaults to the internal PRODUCT_NAME. Instead, just change the bundle name to Prag Tweets.

Now about that generic icon. The first step here is to bring in a real designer. “Why?” you might ask. Why slow things down by bringing in someone else?

Deadlines are a fact of life. We have all been forced by one deadline or another to do something we didn’t want to do. But when that happens, skip features; don’t skip design. The biggest mistake developers make is not having a designer in the loop from the beginning. The design of your app is the way that users will perceive it. After spending countless hours thinking about the internal workings of your app, you don’t want to leave the users’ interaction to chance. Just as classes need to be designed, user experiences need to be designed.

Interfaces designed by programmers tend to look like programming languages: specific and detailed but tedious. Users don’t want tedious; they want it to just work. If you expose the switch to toggle the 20 percent feature, that leaves 80 percent to wonder at the complexity of the app.

Programmers fight for control; designers fight for the user. Make sure your app has someone fighting for the users. Don’t ship an app that has not been designed from start to finish. If the idea is worth your time and energy, then it’s worth getting a designer involved.

So, eating our own dog food, we had Scott Ruth of BraveBit App Studio^[8] design a proper icon for Pragmatic Tweets.

One advantage of bringing in a designer who is specifically experienced with iOS design is the dizzying number of app icon sizes that are now required for app store submission. In previous editions of this book, we’ve tried to list all of these, but between iPhones at single, double, and triple resolution, different app icons for iPhone and iPad, additional icons for the settings app and Spotlight, it is now far too much for us to cover. Take a look at Icon and Image Sizes in the iOS Human Interface Guidelines if you’re interested. But we’re very much of the opinion that it can and should be your designer’s problem.

Scott delivered our icons in the form of an Assets.xcassets file, as seen in the figure. This file has been present, albeit empty, since we started our app. By default, it has a single entry called AppIcon, with blank spots for all the known image sizes and pixel depths. Aside from providing app icons, this file can also be used for any images shown by the app (such as those used in UIImageViews). Simply add a file at 1x and 2x resolutions to the collection, and they become available to use for image views in storyboards. They can also be read by code by using the initializer UIImage (named:), passing in the filename without an extension.

With a proper name and icon, our app looks a lot more polished on the home screen, ready for our users to open it.

Launch Images

Another bit of visual polish we can attend to is what users see at the instant the app is launched. When they tap the app icon, iOS presents a launch image until the app is fully initialized and showing its first view.

Prior to iOS 8, the launch image was a static png file. Initially, Apple’s guidance was that the launch image should look exactly like the app’s first screen so that the user wouldn’t notice the time it took to create and populate the first view. In practice, though, many apps used the static image as a “splash screen,” displaying a logo for the app or perhaps its developer or publisher.

The problem with this scheme is that designers had to create static launch images for every combination of screen size and portrait-versus-landscape orientation, meaning they potentially needed a dozen or more different, yet related, launch screen designs. And that was before iPhones came in four different sets of screen resolutions and iPads in two.

Clearly, there needed to be an approach that wasn’t tied to explicit screen dimensions. The LaunchScreen.storyboard offers a launch image that will work at any combination of size, resolution, and orientation. The trick is that this file is a genuine iOS view, in a genuine iOS storyboard, just like our app’s Main.storyboard.

By default, LaunchScreen.storyboard has only a title and a copyright statement on a white background. But these labels are set with autolayout constraints, so they will work at any combination of device shape, orientation, and pixel depth. All we need to do to have a fancy launch image is to customize this view with colors, images, fonts and styling, and so on.

We’ll leave that as an exercise…for your designer.

Setting the App ID

Our next step requires a little thinking ahead. We submit apps to the App Store via Xcode, but that won’t actually work if Apple doesn’t know what we’re sending them. It turns out we need to do a little work on the Developer Center to prepare for our upload.

To upload an app to the store, we’ll need a distribution profile. For that, we usually need an App ID. We say “usually” because there are certain edge cases where this isn’t necessary. The trade-off is that while certain features like iCloud require a unique identifier for each app that uses the feature, there are a few scenarios where multiple apps can share a “wildcard” identifier and work together. The latter case is rare and hard to do, so it’s best to just always create App IDs for our apps.

With your browser, log in to the Developer Center and visit the Certificates, Identifiers, and Profiles section. In the Identifiers section, choose App IDs, and press the + button to create a new App ID. We just need two entries here: a name (which cannot have spaces or special characters), and the app’s bundle ID. We created the bundle ID way back in ​Our First Project​, when we combined a reverse-DNS style unique string with the name of the app. You can check the bundle ID in Xcode by going to the .xcodeproj in the File Navigator and looking at the App target; it should be something like com.pragprog.yourhandle.PragmaticTweets.

So, in the form, enter a memorable string for the App ID (we used PRAGMATICTWEETSIOS9), and under Explicit App ID enter the bundle identifier. We don’t need any of the listed App Services for Pragmatic Tweets, but keep in mind this is how you would signal to Apple that your app uses features like Apple Pay or Push Notifications.

App IDs Are Forever

You might notice that the App IDs and bundle identifiers in the screenshots all have a gratuitous ios9 in them. This is because we screwed up by using com.pragprog.yourhandle.PragmaticTweets for a previous iOS SDK book. App IDs are globally unique, so once we claimed that bundle identifier for the previous book’s app, it became unavailable to us for this book. So we had to come up with a new bundle identifier for this chapter to get our app submitted. Two takeaways here: App IDs are universal, and they’re pretty much forever.

Creating a Distribution Profile

Next, we use the App ID to create a Distribution Profile. This is what Xcode’s uploader will send to Apple to prove that we’re a legitimate member of the developer program, authorized to upload apps for testing, review, and sale.

Still in the Certificates, Identifiers, and Profiles section, under Provisioning Profiles choose Distribution. Click + to create a new distribution profile. This lets us choose which kind of profile we want: whether we’re sending an app to the iOS or tvOS App Store, or whether we’re doing ad hoc distribution, which lets us send the app to a limited number of registered devices, usually for testing. We just want the regular iOS App Store, so choose that and click Continue.

Next, we choose which of our App IDs we’re creating the profile for (the one we created in the previous section, of course), and on the following screen, which of our signing certificates will be used to prove our identity as registered iOS developers (there should only be one certificate, so choose that). After these screens, the profile file is created and can be downloaded to your computer. Click the button to download it, and then drag the downloaded mobileprovision file onto the Xcode app icon to install it into Xcode.

By doing these steps, we’ve prepared Xcode to send our app to Apple. Now we need to tell the App Store what we’re sending it.

Creating an App Store Entry

For App Store distribution, we also need to prepare at least a minimal entry in iTunes Connect to tell them what we’re going to upload. Log in to iTunes Connect and visit the My Apps section. The main page here is a list of all apps ever uploaded from your account. It will initially be empty. Click the + button to create a new iOS app.

There are only four fields that need to be set to create a basic iOS app in iTunes Connect: whether the app is for iOS or tvOS, its user-readable name (like “Pragmatic Tweets”), its bundle identifier, and a SKU. The SKU is an identifier unique to you and your organization. It’s not visible on the App Store; it’s just a way to track this app versus any others you put on the store.

Now that we have prepared a distribution profile and an App Store record, we’re finally ready to upload our app!