5 Tips about developing for the new Apple TV (tvOS)

We’ve been working on games for the Apple TV for some time and we’ve attended Apple’s tvOS techtalks. Based on these experiences, we’ve learned a few tips that we would like to share with you:

1) The Apple TV is not a giant iPad /iPhone

While there are many similarities between tvOS and iOS at the code level, the user interface is significantly different. For starters, the TV screen is far larger and is viewed at a distant. Apple has spent a considerable amount of time in developing fonts and UI elements that are legible at considerable distance. Furthermore, you only have to concern yourself with a single resolution when developing for tvOS.

Input is through a remote that controls what Apple calls the ‘Focus Engine’. At any one time, one of the elements will be in focus and its size will change so it’s clear to the user which one it is. By swiping, the user can move between the various interface elements. Porting an iOS app that uses multi-touch might require a careful rethink of the way the user interacts with it.

There are also specific features such as ‘Top Shelf’: If the user places your app in the top shelf, you’re allowed to provide content that is visible in the top carousel of the main Apple TV page. This is a great opportunity to increase retention of users. 

2) The TV is often used in a group

A phone or a tablet is a very personal device: It is seldom shared with other people and it’s used up close. This means that the apps are focus on that single user and the interaction is primarily through touch. On the other hand, a TV is usually used by various members of the house, sometimes as part of a group. It’s in a sense a more social device, there is no privacy given that other people can easily see your screen.

When designing for the Apple TV you need to think about ways a group of people can use your app: For example, the famous karaoke app ‘Sing!’ allows a group of people to participate by sharing an iPhone that is used as a microphone. In cases where the app is meant to be used by a single user at a time, an account system might be necessary to differentiate from the various household members that share that common TV.

3) Apple TV apps can be great companions to existing apps (sort of like the watch), further promoting your iOS app.

You don’t need to port your whole iOS app to the Apple TV. In many cases, the  TV might not be the right fit for your app. However, a tvOS app can be a great companion to an existing iOS app. It might also provide a less risky way to get into Apple TV development. A companion app could share media such as images or videos. If it was an exercise app it could share maps or reports.

4) Assume the Apple TV is constantly and reliably connected to the Internet

One of the things that Apple constantly stressed at their conference is that you should assume that the Apple TV is constantly and reliably connected to the Internet. This is important because Apple TV apps are restricted to a binary of just 200MB. Any extra content needs to be on demand.

Furthermore, you can only store 500kb of user data on the NSUserDefaults database. Any larger amount of storage would require the use of iCloud KVS or iCloud CloudKit.

All of this means that if your app contains a significant amount of content, it will have to depend on that reliable internet connection to work properly.

5) The tvOS AppStore is still in its infancy

The Apple TV’s App Store is missing many of the features that we have on both the Mac and iOS App Stores. Chiefly among this is the lack of link that takes the user to your App’s App Store page. This makes it harder to drive installs as well as to track where are users coming from.  On top of that, the user must use the cumbersome remote, selecting one letter at a time, to find your app through the App Store’s search. Because of this, keywords are even more important than on iOS for discovery. To mitigate this issue, the best practise is to explain on your website how to search for your app. A distinctive, yet brief name is helpful in order to reduce the amount of text the user must type.


In spite of the limited features of the App Store, don’t despair just yet. Since it’s original release Apple has added Analytics, App previews and Top lists. At the time of publishing this post, the next release 9.2 is in beta and will allow users to use VoiceOver to dictate text. This is a huge improvement from having to use the remote to select letters to fill in text in places like the search of the Apple TV’s App Store. Finally, it’s worth noting that this is a new platform, and a such there is limited competition, so publishing your app at this stage can increase visibility and hopefully shape the future of the Apple TV.

6 tips about adopting Swift in your company

We’ve been using the Swift language since the end of last year, when it reached version 1.0. Initially, we included Swift code in existing codebases but we have now moved to using almost exclusively Swift for new projects. The following tips are based on our experience in working with the language

1. Swift is still a fluctuating and changing language

Even though Swift has long reached version 1.0, it’s still a language that’s very much in development. This means that its syntax and structures can change with every new release, breaking existing codebases. Apple provides an automated conversion tool, but it seldom solves all your problems. The example below is from a medium-sized project written in Swift 1.2 and converted to Swift 2.0. Even after the automatic conversion, there are still 48 issues left.  Swift is a fluctuating language, so new versions can break existing code bases. 

2. Get your developers to follow news about the language’s development

Apple is usually good at discussing changes to the language before they’re actually implemented. Getting your developers to follow their official swift blog and look through the documentation of early beta releases. In this way, they’re more likely to be prepared to adapt your codebase when a new version is released by apple.

3. Use it for new projects

Swift 2 has recently been released together with iOS 9 and watch os 2. Many features that were missing have been added and the language feels a lot more polished. It definitely makes sense to start using it for new projects. There is now plenty of documentation and help available given that it’s been more than a year since the first stable (1.0) version became available. Using it for new projects will also avoid the need to work with legacy objective-c code. 

4. Avoid rewriting existing codebases

If you have a large, existing project you could start using Swift for new features first. The interface with Objective-C is good and well-established (as Apple uses it for their own frameworks), so try to avoid the temptation to rewrite large chunks of your battle-tested code. Over time more of your project will be in Swift as components that require changes are slowly improved and rewritten. Have a look at the concept of strangling vines if you have a large code base that will need be maintained for several years: 

5. Sell it to your clients / managers

In the long-run, Swift will replace Objective-C. There are now four platforms Mac, iOS, Apple Watch and the new Apple TV where Swift can be used. Given that the last two are very new, it makes sense to invest now in using swift there for new projects. Furthermore, Swift is a much safer language than Objective-C, which means less bugs and more time to concentrate on features.

6. Take advantage of the playground to prototype ideas

Swift has a powerful ‘playground’, a feature that allows developers to write code and see a preview of the results. This can be used to prototype all sorts of ideas including animations. By using this tool, you can discuss new ideas with your team, including designers, more effectively.

Join Devices in the Circle of Care

The Internet of things is a technology with a lot of potential in improving health and social care. We are currently working on a prototype that is funded by the Department of Health to allow different services and devices to connect with Jointly, an app that we developed with Carers UK that makes caring for someone a little easier, less stressful and a lot more organised.

The main use case is to connect use of drug dispensers with a circle of carers. We are creating an API that allows 3rd party services to create a circle of care, invite members and post messages back and forward from the device to Jointly. Technically we needed to do this while causing the least disruption possible in PivoTell’s product.

We opted to do it using the most ubiquitous Internet technology, namely, email. We setup a mailgun route to capture and process the emails and turned them into a nicely structured JSON format. Mailgun contacts parse.com where we have a cloud function to validate and authorise the request. From then onwards everything is handled as before, in iOS, android and web clients. We had to battle with some DNS settings and communication incompatibilities but as a prototype we are in good position to continue.