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 the project icon at the top of the Project Navigator, select the Pragmatic Podcasts 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 variable. Instead, just change the bundle name to something short like “PragCasts” or “Prag Podcasts” (which just barely fit without truncation when we tried it).

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% feature, that leaves 80% 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 our designer friend Jaleh Afshar ^[5] design a proper icon for Pragmatic Podcasts.

One advantage of bringing in a designer who is specifically experienced with iOS design is that you now have someone to deal with 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 now—between iPhones at single, double, and triple resolution, different app icons for iPhone and iPad, additional icons for the Settings app, Spotlight, CarPlay, Apple Watch notifications, and more—it is 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.

Jaleh delivered our icons in the form of an Assets.xcassets file, as seen in the figure. We first saw this file back in ​Image Assets​, when we used it for a default app icon image (which, we can now reveal, was another of Jaleh’s creations). Since we already have a Assets.xcassets file in our project, we took the app icons Jaleh mailed us and added them to our project’s existing assets file.

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 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 use the static image as a “splash screen,” displaying a logo for the app or perhaps its developer or publisher.

The problem with the PNG scheme is that designers had to create static launch images for every combination of screen size and portrait-vs.-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 is a completely empty view with a white background. But it’s a view in a storyboard scene like any other—labels and image views can be added and then set up with Auto Layout constraints. Once fully laid out, the launch screen will adapt to screen size and orientation just like any other scene in the rest of the app. So all we need to do to have a fancy launch experience is to customize this view with colors, images, fonts, 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 website 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 your account (https://developer.apple.com/account) and visit the Certificates, Identifiers, & 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) for use on the developer site, and the app’s bundle ID. We created the bundle ID way back in ​Creating 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.PragmaticPodcasts.

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

Once you create the App ID, a “Registration complete” page says, “This App ID is now registered to your account and can be used in your provisioning profiles.”

App IDs Are Forever

You might notice that the App IDs in the screenshots and bundle identifiers all have a gratuitous ios10 in them. This is just to make the app for this edition of the book unique from previous or future editions. You do not need to fix your App ID to a specific version of iOS, and, indeed, should not do so. App IDs are globally unique, so once we create one, we can’t use it again. That’s why we have to tack on an IOS10 to disambiguate it from last year’s or next year’s example project. 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, & 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 five 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 Podcasts”), its bundle identifier (a pop-up menu that includes the App ID we just made), 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 vs. 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!