How to Succeed (or Fail) with Your Apple TV App Release Process

by: | Nov 11, 2015

We’ve been building apps since the original iPhone was introduced, and have seen many mobile platforms come — and some go — in that time. And with each new platform comes a new app store to go along with it.

The process of submitting new releases to each app store, as you might expect, is different. Each app store has its nuances that can surprise even the most experienced developers. And these surprises often cause frustrating delays at the very end of a project, a time when project stakeholders are eager to see their apps appear in the app store and in the hands of their users.


BUILDING ECHO: A blog series on developing for the Apple TV


If you’ve been reading our series of blog posts about our Echo game for Apple TV, you’ve read about some of the unique design and technical challenges that Apple’s new living room operating system presents. Today, I’ll share what we learned about the Apple TV app release process, including some things that surprised us. We hope you’ll be able to benefit from our learnings — and our mistakes!

The ArcTouch way: Continuous integration and automation

Before we get into the nuances of Apple TV, it’s important to understand how our development teams typically create new mobile app releases — regardless of whether it’s iOS, Android, Windows, or now tvOS. In all of our projects, we use Jenkins as our continuous integration (or CI) platform to ensure that any changes to the code are regularly tested for functionality, logic and syntax. CI and this automated testing ensures different members of our development team don’t add a new feature that breaks some other aspect of the code. Like any robust CI server, we use command line tools instead of a single GUI to build a new release.

iOS to tvOS: Same code signing keys, different provisioning profiles

If you’re already an iOS developer, as my colleague Andre wrote, you’ll see a lot of familiar features as you start working on tvOS apps.

When it comes to the Apple TV app release process, this is mostly true, too. The code signing that takes place between the software and the app store — which ensures an app that gets to the app store is from a reliable source — uses the same encryption keys as iOS. So, established developers can use their same certificates from iOS as tvOS.

But the provisioning profile — which is the secret sauce that allows software to work on its intended devices (e.g. Apple TV) — is unique to tvOS. We would have expected either the code signing and provisioning to both be the same from iOS to tvOS, or both be different. A developer who works on both MacOS X and iOS would have unique code signing key pairs and unique provisioning profiles on the two different platforms.

So, in order to deploy our apps to our AppleTV devices (and later to the AppStore), we had to generate new “tvOS” provisioning profiles.

No transparent layers on Top Shelf images

As my colleague Salvatore mentioned in his post about Apple TV app design, tvOS projects need a Top Shelf image that displays atop the Apple TV main menu. However, it can’t just be any image. We had a transparent layer in the .png file of our first Top Shelf image — which caused it to fail. After submitting the app we got an error message complaining about this:

Apple TV app release error

So, don’t make the same mistake we did — remove that layer before you submit!

Avoiding legacy SDK references

Soon after we’d realized we needed a unique provisioning profile, we went ahead and triggered a first-run test build. But we made the mistake of keeping some of the common code from our iOS profile in our CI scripts. We compiled the app using the “iphoneos” SDK — which caused our build to fail while it compiled.

After we identified the problem, we found within Apple’s documentation that for deployment builds, you need to specify the SDK as “appletvos.” And for simulator builds, you need to point to the associated SDK, “appletvsimulator.”

No more IPA packing: A challenge for CI

One of the last steps of the iOS app submission process involves packing the app bundle into an IPA file. This IPA file can then be used for installations over the air or for iTunes Connect submissions using Application Loader, depending on the app’s provisioning profile.

However, when it came time to go through our first Apple TV release process, we were surprised the binary we used for iOS that bundles files into an IPA, called PackageApplication, was nowhere to be found within the tvOS SDK. We tried to hack the scripts to use the iOS version instead, but that didn’t work because of the tvOS file structure.

Our next step to overcome the packing issue was to generate an Xcode Archive instead of an IPA. Small teams that don’t use CI and automation commonly use archives to submit apps directly from their machines to the App Store. Apparently, it was the way to go to release Echo on time. But since our Jenkins has a few virtual machines as executors that change dynamically, this wasn’t an option. Generating a bundle that our PM team could easily submit to the app store is imperative for us. So we set our scripts to archive the project first, and then export it using the “exportArchive” option from xcodebuild to generate a deliverable IPA. It worked like a charm. Problem solved. About 23 hours after we submitted to the App Store, Apple approved and Echo was live on Apple TV.

This is what success looks like for an Apple TV app release:

Apple TV app release successWe made it through the process of building (and releasing!) our Echo app for Apple TV in three weeks — and learned a lot in the process. We hope you found this post helpful, and that you’re enjoying playing Echo on Apple TV. But let us know what you think of Echo. Comment below or tweet to us using #EchoGame.