Web Analytics

InPlayer - Content Paywall

InPlayer Video Monetization

API, Knowledge Base, News

How To Develop For The New Apple TV

We did a lot of cool stuff in a very short period of time, so we thought that we could share this great story with you. In short, we meet the deadline for shipping an AppleTV app in just under two weeks, along with in-app purchase and integration into our system of entitlements, as well as supporting Universal purchase from an existing iOS app.

For starters, we definitely see AppleTV as a new frontier in how content is consumed and a place where publishers will most definitely go, so this experience was invaluable, as we wanted to get there first and be ready for the wave of new customers.

apple_tv_front_hero

Approach

The first strategic decision we had to make was whether to choose to make the app native or with the help of Apple’s new scripted server side scripting syntax called TVML. Due to the limited time, we hoped to be faster by using the TVML templates prepared, and additionally use the web developers who were already involved.

However, the TVML templates creation proved to be less than ready and based on our experience, it would’ve been much easier to build a native app. That way we could’ve built the rich functionality and rely on legacy libraries and CocoaPods. However in the end we were able to quickly rise up on the Storyboard and bind the business logic! So we were ready for the next stage!

Tools

Over time, we got up to speed and ramped up the screens, and we got UI and our business logic in place. Xcode worked great since the initial beta, however, we knew right from the start that we were not going to be able to test on Storekit for in-app purchase, since we weren’t “fast fingers” enough to get the dev kit and dev device.

As established programmers already know, you always have to get the latest version of Xcode so that the submissions and signage work without any issue. We had a few hiccups while changing the Xcode version and several failed submits, but nothing too serious.

We were hoping to get the GM, ready on Tuesday before the opening sale, but we were late just for a day which made some of us a bit stressed out! But, as soon as it arrived, one last test and we were ready to go live!

Devices

The biggest pain in this process was that we didn’t have a test device and couldn’t test outside the Simulator. So, we turned to social media. We were able to find a colleague that generously offered to help us with screen share and Quicktime. And as we learned over the sessions, the keyboard input via the remote is quite difficult for the general consumer. In the shiny great universe, that is Apple TV. However, that was the only drawback to our experience, app navigation, and framework.

Code refactoring and publishing

After a few test sessions over Quicktime sharing; we have gone to a few code refactoring cycles. We’ve globalized variables and the observers for in-app purchase. Since, we had to develop Universal purchases for the original iOS9 app, we had to re-sign it with a new XCode and make a slight change in the original receipt validation flow on mobile.

In the apple testing, we had a few random crashes, so we had to make default values for all values that we expected from the external resources, such as IP address resolution, geo-location, localisation strings, configuration parameters. Once we had setup a default template to run the app at first runtime and load it async after that, we were able to move to a better stage in the Apple staging process. Another big point to consider is to always include onscreen instructions for usage (like swipe down to reveal app). This lesson cost us a day of work in testing.

And last but not least, the takeaways:

  • Be the first in line for a dev kit on a new device and framework
  • Use globalized observers for in-app purchase
  • Always include onscreen instructions for usage
  • Be part of the community so you can help and get help
  • When deciding on a new approach, always take new recommendations with a grain of salt and rely on your development instincts
  • Upload Xcode the same minute it has released a new version
  • Re-check native code and Apple platform services, like receipt validation for iOS9 for the mobile app in old apps
  • Always make sure you have a default value for a value you expect from an external service (like an IP address)
  • Take the return from Apple testing as gospel
  • Always make sure you contact and ask for the suppliers of auxiliary services to get you a new update (like crash analytics maker)

Good luck and see you in the app store! 🙂

Other example posts and useful resources:

http://www.raywenderlich.com/114886/beginning-tvos-development-with-tvml-tutorial

https://www.simononstartups.com/developing-for-the-apple-tv-with-tvos-swift-javascript-and-tvml/

http://jamesonquave.com/blog/developing-tvos-apps-for-apple-tv-with-swift/

https://www.quora.com/How-trivial-is-it-to-build-an-app-for-both-iOS-and-tvOS-from-a-single-codebase

http://www.polygon.com/features/2015/10/26/9604068/apple-tv-app-size-limit-technology-slicing-tags-200-mb

http://stackoverflow.com/search?q=tvos

We use cookies to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners. See details