Writing Apps for Apple TV for fun and (no) profit

A new AppleTV

On 9th September 2015 Apple announced a new version of Apple TV, the fourth-generation, and it brings a long awaited feature: Apps.

Many times I asked myself why Apple didn’t enabled Apps on Apple TV. Advantages are obvious to me: iOS is one of the most widespread mobile OS and the one with highest number of Apps. Porting Apps to Apple TV can be really simple and this make it the platform for TV with the higher number of Apps.

Eventually Apple did it and better than I could imagine. Apps for Apple TV can be made with classical approach, like we develop native Apps for other iOS devices, or in a new way based on a specific markup language and JavaScript. The latter is really interesting and at the same time strange for Apple standard, what I’d like to do in this article is make a simple example to explore this new way.


Apps made with this new way use three new technologies, precisely TVML, a markup language made to create the UI (TVML stands for TV Markup Language). TVJS, a  JavaScript API to display and interact with TVML, and TVMLKit, the native layer to combine all together.  I’m a big fan of learning by examples approach so let’s start with a sample.

A simple tvOS App

Sample tvOS App

Before starting make the example a few words on TVMLKit App’s architecture, this kind of Application is made of two parts: one native and one JavaScript.

TVMLKit App Architecture

In a nutshell native code is something like a container which load startup JavaScript and give control to it. JavaScript and resources can be loaded from a remote server (ie a web server) so our App can be remotely updated after released on the App Store without making a new submission (this is one reason because I wrote this model is strange for Apple). So we’ll start making the native part, I assume You have XCode 7.1 or higher.

Launch XCode a choose tvOS Single View Application.

tvOS App template

Standard template for tvOS Application includes some files we don’t need, so first operation is to trash ViewController.swift and Main.storyboard, these will be not used in our example. We need to change some settings too, default template is made to use storyboard UI, we removed Main.storyboard and so delete “Main” in Main interface setting (You can also remove this by opening Info.plist file and removing “Main storyboard file base name” key). Project settings

Last operation is to permit to the App to make HTTP requests to outside world, with iOS 9 Apple introduced transport security setting and by default it blocks all networks requests. So open Info.plist file and add App Transport Security Setting like in the following image (“Allow Arbitrary Loads” set to YES is the mandatory part).

App Transport Security Setting


Let’s write the code

Now it’s time to modify AppDelegate, we have to delete all methods put by XCode, import TVMLKit and make AppDelegate class conform to TVApplicationControllerDelegate.

import UIKit
import TVMLKit

class AppDelegate: UIResponder, UIApplicationDelegate, TVApplicationControllerDelegate {
    var window: UIWindow?

In this state our App isn’t able to do much so we need to add the code to bootstrap the JavaScript which represents the real core of the App. What we need to do is create a TVApplicationController giving to it necessary info to load the JavaScript code which handle UI.

import UIKit
import TVMLKit

class AppDelegate: UIResponder, UIApplicationDelegate, TVApplicationControllerDelegate {

    var window: UIWindow?

    var appController: TVApplicationController?
    static let TVBaseURL = "http://localhost:9001/"
    static let TVBootURL = "\(AppDelegate.TVBaseURL)/app.js"
    func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
        window = UIWindow(frame: UIScreen.mainScreen().bounds)
        // Controller context for loading JavaScript
        let appControllerContext = TVApplicationControllerContext()
        // Url from which to load javascript
        appControllerContext.javaScriptApplicationURL = NSURL(string: AppDelegate.TVBootURL)!
        // BASEURL variable will be available in the JavaScript code
        appControllerContext.launchOptions["BASEURL"] = AppDelegate.TVBaseURL
        // Standard controller for tvOS Apps based on TVMLKit
        appController = TVApplicationController(context: appControllerContext, window: window, delegate: self)
        return true

First we set two variables with the base URL where to load scripts from, TVBaseURL, and the URL of the bootstrap script, TVBootURL. After we need to implement didFinishLaunchingWithOptions, this method is called on Application start and here we did two logical operations:

  1. Create a TVApplicationControllerContext used to load JavaScript
  2. Create a TVApplicationController, passing to it the previous TVApplicationControllerContext, to handle Application lifecycle

That’s all we need for the native part of our App, now it’s time to move to the JavaScript side.

The JavaScript side

Native part of App loads a simple JavaScript, creates a new folder in the root of the project where to put the code. Call it “js”, now creates a app.js file and put the following code in it.

App.onLaunch = function(options) {
  var menu = mainMenu(); 
var mainMenu = function() {
  var tvmlCode = `<?xml version="1.0" encoding="UTF-8" ?>
         <img src="https://c1.staticflickr.com/7/6050/6350327968_33f008d9c2_b.jpg" />
    var parser = new DOMParser();
    var menuDoc = parser.parseFromString(tvmlCode, "application/xml");
    return menuDoc

As I already wrote JavaScript is the real core of our application. App.launch is the entry point of the code, it’s called when the script is loaded by TVApplicationController. In launch there is a first interaction with TVJS API, navigationDocument. This object is used to present views on the screen in few different ways, it’s something comparable to UINavigationController if You wrote some native code for iOS.

The code is pretty simple, launch method calls mainMenu function, this function uses DOMParser to make a document object starting from a TVML template. The interesting part is tmvCode variable which contains TMVL code to make the user interface. TVML is a custom XML which defines the UI elements, it starts alway with <document> element and contains many different children elements who renders on the screen in different ways. In our simple case we used <background> to put an image on the background and <menuBar> for the menu on the bottom of the screen (menuBar is a complex element with a three of children for define the inside items). A full documentation of TVML is available on Apple Developer Site.

Now we are ready to try our simple App, in the native part we used an URL to load app.js, so we need to serve this script using a web server. The simplest way to make this is to use python which is installed by default on Mac OS X. Before running the App from XCode launch the Terminal and go in the folder with app.js, from here type the following command

python -m SimpleHTTPServer 9001

This command runs a simple web server listening on port 9001 serving files from current folder. Started the web server run the App from XCode the App and it’ll be executed on Apple TV simulator or on the real device if connected to the Mac.


This article is a simple introduction on how simple can be write Apps for tvOS, make real applications it’s obviously more complicated than this. In a future article I’ll describe how to use NodeJS as backend for a TVMLKit App using a template system to handle dynamic TVML generation.

Source code of the app can be found here.

Linking iOS App from Web

Nowadays almost all web sites  match with a mobile Application. Users jump from web to Apps and back, making this experience as fluid as possibile is becoming really important. In this post I’d like to explain the standard approach to this problem and how I get an enhanced solution to it.

Redirect to store to download the App
Redirect to store to download the App

Standard approach

Before describing the standard approach we need to explain how an iOS App can be launched from a web site and how this is typically used.

iOS Apps comes with a configuration file named Info.plist who gives all the parameters needed by the iOS runtime to execute the App itself. Some of these parameters are  App name, supported screen orientations, default language and many others. One of these is URLscheme  who is a powerful system to launch the App from outside.

Looking to a snippet of Info.plist took from my App Pushetta it looks as follow:


What this mean? It simply says the App can be executed with a custom url, in this case the url is pushetta://. So first step is now clear, if a web page has a link with this url schema, loading it on a device with the App installed and using the link the App is started. WOW this is great!!! But wait a moment, if the App isn’t installed? Ehm, we get an error.

Url scheme error
What happen when App isn’t installed?

Error is self explaining, we tried to open an url Safari doesn’t understand. This freezes our initial enthusiasm.

The standard solutions comes in mind is to check if the App is installed before running the custom url. BEEEEEEEP!!! This isn’t possible! For (obvious) privacy problems a web page can’t inspect the device to known if a specific App is installed.

Ok, so we are at dead end, we know how to execute the App from web page but we don’t know how to be sure is installed before this.

Some clever people made a work around to this problem with a trick based on JavaScript setTimeout function. The idea behind the solution is: we start a timer that when expire executes a function whose redirects the user to a predefined url (it can be for example a landing page with info about the App and a link to the store). Right after the start of the timer the script try to launch the App with the custom url, so we get two scenarios:

  • App is installed: it runs and the timer never fires (this because running the App brings the user outside the browser)
  • App isn’t installed: we get the error but after awhile we get redirected to a predefined page

The code for this solution is

                window.location = "http://www.pushetta.com";
              }, 1000);
   document.location = "pushetta://";

The code make exactly what we described: it sets a timer function that after one second (1000 milliseconds) redirects the user to http://www.pushetta.com. Next it tries to run pushetta:// custom url scheme and this implies the two scenarios described.

This is a pretty poor solution, it works but with a bad user experience. This is where I started to look for a better solution, googling around wasn’t productive so I decided to make some tries. My starting point was: I can’t check if the App is installed but if I could handle the error on opening a wrong url this would be enough to resolve the problem. This is simplest to say that to do, window.location gives an error when we try to open a wrong url but it seems not trappable by code. So how can we do? The solution I used is based on a iframe. As many know an iframe is something like an hole (squared) inside the page who loads another url, the idea is: if I create an iframe in the DOM with it’s src set to the custom schema, will it show the error popup when the schema is wrong (ie the App is not installed)? Luckily enough this doesn’t happen and so we can implement the right solution based on this behaviour.

   // timer func to bring the user to a web page if App isn't installed
            document.location = "http://www.pushetta.com";
        }, 1000);

   // put an iframe in the DOM with "pushetta://" as src (and 0x0 dimensions)
   ifrm = document.createElement("IFRAME"); 
   ifrm.setAttribute("src", "pushetta://"); 
   ifrm.style.width = 0+"px"; 
   ifrm.style.height = 0+"px"; 

The solution seems to work well but I consider it a test to be verified with various scenarios.

VoCore as smart sensor

Some days ago I received my VoCore, this device is amazing it’s a full embedded Linux device with  OpenWrt, WiFi and Ethernet on board and many I/O (i2c, GPIO, SPI, UART, ..). Its main strengths are size and WiFi on board. About size look at the following picture.

VoCore size
VoCore size

For a maker a device like this is awesome, combine connectivity and power in a so small size can open infinite possibilities but the first that comes to mind is smart sensors.

Smart sensor is a generic term, my own interpretation is about a device can acquire some physical data, elaborate it and communicate over the internet. What I’d like to present in this post is a simple use of VoCore as smart sensor.

Configuring OpenWrt

Before starting we need to configure OS, I chose to use Python for implementing the smart sensor logic.

VoCore is shipped with a release of OpenWrt doesn’t carry Python, so here the step to install it, I skip basic VoCore setup because can be found on VoCore site. Next steps assumes You are able to connect via ssh to VoCore and it has a internet connection enabled.

OpenWrt uses a package manager called opkg, like many others it uses a list of repositories urls where look for packages. These urls are defined in /etc/opkg.conf and in default configuration isn’t present the repository for python.

So first step is to add a new repository url, add the following line to the end of /etc/opkg.conf

src/gz cheese_packages http://downloads.openwrt.org/snapshots/trunk/ramips/packages/packages

After this we need to update opkg cache with following command

root@OpenWrt:~# opkg update

And finally we are able to install python

root@OpenWrt:~# opkg install python

Ok, less is done 🙂

Making the sensor

Now it’s time to work on hardware, what I’d like to make is a simple intrusion detection system that sends a push notification when someone get in the room. To send push notification I’ll use Pushetta, a service I made specifically to solve this task.

A PIR sensor is used to detect movements, this kind of sensor use infrared radiation to detect temperature changes in a specific range.

PIR Sensor
PIR Sensor

PIR sensors are cheap and really simple to interface with a microcontroller, there are only three pins. Two are VCC and GND and the last one is the OUTPUT.

In the following video I show how it works, I’m using a portable oscilloscope connected to the PIR sensor. As You can see when something move in sensor’s range output level goes high (+5V) and return low after a while.

What we want to do is read PIR output and send a push notification when it changes to high.

Sending notifications with Pushetta

To send notification we’ll use a web service I made called Pushetta, this is made of a web site and two Apps (one for iOS and one for Android).

First we need to register on Pushetta web site, it’s free and it’s a mandatory step to be able to send notifications.

Pushetta signup
Pushetta signup

After signup process we need the API key, this is the key used to call Pushetta service and send notification, it’ll be used in code we’ll write after.


Last step is to create a channel. Channel is something like a topic used to send notifications. User want to receive notifications have to subscribe channel interested in, using Pushetta Apps. More informations about how Pushetta works can be found on www.pushetta.com.

Channel creation
Channel creation

Now we are ready for the last step: connect PIR sensor to VoCore and write a few lines of Python code to handle all the logic.

Schema PIR - VoCore
Schema PIR – VoCore

In the picture there is the schematic used for our experiment. Connecting PIR sensor is really simple, I used GPIO0 as input in the VoCore module. Whit this circuit GPIO0 is put to low when PIR signal is up and vice versa. Must be taken into account that PIR sensor require +5V as power source, on VoCore can be used USB+ pin.

Before writing full Python program is better to test that everything is working as expected with a simple shell script, first step is login on VoCore via ssh and change directory to GPIO0 sys filesystem as follow.

root@OpenWrt:~# cd /sys/class/gpio/
root@OpenWrt:/sys/class/gpio# ls
export      gpio13      gpio18      gpio21      gpio24      gpio7       gpiochip0
gpio0       gpio14      gpio19      gpio22      gpio25      gpio8       gpiochip22
gpio12      gpio17      gpio20      gpio23      gpio26      gpio9       unexport

If we see an output like the one above we are in the right place and next step is to change dir  to gpio0.

root@OpenWrt:/sys/class/gpio# cd gpio0/
root@OpenWrt:/sys/devices/10000000.palmbus/10000600.gpio/gpio/gpio0# ls
active_low  device      direction   edge        subsystem   uevent      value

Two files are important for us, direction is the first one. We need to put the string “in” inside to this to set GPIO0 in input mode (we need to read from it). The other one is value, value is 0 when GPIO0 is low and 1 when high.

Coming to the script we can use the one below, it simply read value every second.

while  [ 1 ]
  cat value
  sleep 1

Executing it console shows something like:


0 mean PIR is sensing motion, else nothing is moving around it, all works fine!

Becoming a smart sensor

Now the code, I found an already made wrapper for interacting with GPIO made by Stefan Wendler and to not reinvent the wheel I use this, is called DigitalIO and I put it on github with all the code of this article.

This wrapper makes really simple to read GPIO status, with the following five line of code we can print on console the GPIO status read every half second (something like we made with shell script).

pin = DigitalIO.get_input(GPIO0)
while True:
    read = pin.state()
    print "GPIO0 state = " + str(read)

Last piece of code we need is the one used to send the notifications, we make a function to solve this task later used in final code.

def sendNotification(token, channel, message):
	data = {
		"body" : message,
		"message_type" : "text/plain"

	req = urllib2.Request('http://api.pushetta.com/api/pushes/{0}/'.format(channel))
	req.add_header('Content-Type', 'application/json')
	req.add_header('Authorization', 'Token {0}'.format(token))

	response = urllib2.urlopen(req, json.dumps(data))

With all piece in our hands it’s time to assemble all together and make real our smart sensor.

pin = DigitalIO.get_input(GPIO0)
while True:
    read = pin.state()
    if read == 0:
       print "Something move"
       # NOTE: API_KEY and MYCHANNEL name must be updated with values
       #       created in pushetta web site in the previous steps
       sendNotification("API_KEY", "MYCHANNEL", "ALARM!!! Something move")
       print "No motion" 

Isn’t a “production ready” software but a good starting point to make the real one. A small problem with this code is it send a push notification for every motion it detects. This can generate many notifications and Pushetta protects for this problem blocking requests if these are too frequent. This can be simply addressed recording last notification sent and send another one only some time has passed, I leave this as an exercise for the reader.

Here the full code.

Push notification from Arduino Yún

I have often wished a system to send notifications to cell phones without paying for it (ie SMS) or using emails.

Major mobile operating systems include those that are commonly referred to as push notifications and slowly these are getting available also on Desktop system. The use of push notifications is not trivial because every system (or at least the major ones) requires to develop a custom App as receiver of notifications.

Simply put, notifications aren’t like SMS, where knowing the phone number is enough to send a message, no!! You need to develop an App and use a server provided by manufacturers of mobile operating system (ie Apple, Google, Microsoft, …) but this isn’t enough there are also some security requirements like digital certificates and other pagan rituals.

Back to the top what I needed was a simple notification system and looking around I was not able to find one, so I made Pushetta. The opportunity came from the integration of my pellet stove in Domitio, my home automation system. One of objectives was to get notified when pellet level was below a threshold, this information is important because some stoves fails to start,  when refilled, if pellet has been previously completely exhausted (mine is one of these).

Pellet Stove
Pellet Stove

So, Pushetta is a simple system I made to send notifications to mobile phones (and also desktop in future), components are:

Typical use case is:

  • User interested in send notification register on pushetta.com
  • He /She defines a Channel, that is a node where send notification
  • User wants to be notified downloads the App
  • By the App he seeks interested channels and subscribes them
  • Every time a message is “pushed” to a channel subscribers receive it

Back to my stove I made a custom shield for my Arduino Yún to interact with it, this interfaces Arduino with a ultrasonic sensor that measure pellet level and some relays to controls start and stop of the stove.

Stove controller
Stove controller
Ultrasonic sensor
Ultrasonic sensor

So, stove controller continuously measures pellet level and when under a threshold uses Pushetta to send a notification. Sending notification from Arduino it’s really simple, nothing can explain it better than show a trivial example.

Sample sketch
Sample sketch

Example shown in picture is a modified version of the “Button” example found in Arduino IDE, in this version (made for Arduino Yún) when button connected to pin 2 is pressed a push notification is sent. In my stove automation system I use the same code to send notification when pellet level goes too low.

Pushetta isn’t limited to Arduino, it can be used virtually from any system can make an http post with a json payload. I used it also in an experiment with Raspberry Pi where I made a simple face recognition software who sends a push notification if I’m the subject in the camera.

I’m looking for beta tester because Pushetta is a “spare time” project but I would like to transform it in a production level software, look at www.pushetta.com if You can help me.

Apple WWDC 2014

Apple developer event of this year was really rich and for the first time after many months I see a revamped strategy in Apple plans.

The strategy is clear: focus on ecosystem!


Yes, a great advantage of Apple on concurrents it’s a large and consistent ecosystem. Making it more integrate can overtake other ones (Google in primis). Increasing cooperations capabilities of two main platforms can give to end user features that other (aka Android) can’t reach out.

But, letting marketing strategies to Apple, I’d like to point attention to the shift to the new language for App development: Swift.

I spent part of night reading the free eBook downloadable from itunes, and a thought flashed in my mind: is this an Apple’s try to make only one language for client Apps and backend?

Swift appears more suitable of Objective-C in a server side use, and a big problems of today App developers it’s backend. Many App developers can fluently write client software but at same time it can be really problematic for they to write backend one. So what if Apple will offer a backend solution programmable with the same language we use for writing clients Apps? How many developers will use this service? I think many, or rather MANY!

The idea it’s only speculation at this moment but there are some good reasons to let me think can be real in near future:

  1. Apple announce also CloudKit, so backend problem is clear to Apple
  2. Controlling backends of Apps can enhance security
  3. New services can be developed and offered in a straightforward way using internal Cloud
  4. Giving developer a good environment it’s the best way to keep them

It’s not only a language problem, Android is Java based and Java it’s perfectly suitable for server side development. It’s, again, ecosystem related. Backend it’s problematic because it needs system related skills, also using one of many cloud solutions. Developer needs to known about systems and all architectural decisions  are up to him.

What I imagine from Apple instead it’s an integrated solution where developer doesn’t need to care about server system. I imagine an Xcode release where You can write client software together with server one and publish App and server software will be a matter of some clicks.

I really hope these speculations will be real in a near future, work in a so integrated environment will be a big boost in developer’s productivity and I can’t wait to try it 🙂


Making a simple Robot

Making a robot is a big challenge, also when You say to yourself “I make only a simple robot” simple will be not so simple.

I started making the “simple robot” mainly because I like to make things, and I like more to make things that move. For the first version I decided to concentrate my efforts in electronic and software, for this I bought a cheap robot platform for mechanical platform (this one).

I gave to myself some goals:

  • Make a WiFi connected robot
  • Make use of websockets for the control interface
  • Make the robot speech
  • Use some simple form of shape recognition

I made many projects based on Arduino but this time I looked for something more powerful, looking in my “stuff drawer” I found a beaglebone (white one) and I choose her for the brain of the robot.

BeagleBone is an incredible platform, it can run various OS like Arch Linux (default), Ubuntu and many others. One thing that made BeagleBone a little “special” compared to others it’s expansions capabilities (65 GPIO, 8 PWM, 7 Analog input, …) and a feature I found only in this board : PRU.

PRU is acronym for Programmable Realtime Unit, BeagleBone has two of them. Essentially PRU are autonomous chip with a specific assembly instruction set capable of performing realtime task, they run separately from main OS but can communicate with it using shared memory.

PRU are essential to make tasks with high precision time constraints, like make a pulse wave modulation or, as in my case, to read short pulse from a PING))) sensor.

PING))) sensor from parallax is cheap and theoretically really simple to use, this is true for example with Arduino but using it with BeagleBone make things a bit more difficult. This sensor works emitting an ultrasonic signal when the board send a short signal on trigger pin (40Khz), to misure distance board have to read the echo response duration. Here is where things get complicated.

Using a GPIO to read an hight frequency signal and pretend to precisely measure it is really optimistic. Isn’t a hardware problem but more a software one. GPIO on BeagleBone are handled by operating system (Linux), this is not a realtime OS so software scheduler can’t grant a precise response time to an hardware event.

In a next post I’ll show how to use PRU in BeagleBone, stay tuned!

A Raspberry PI based Arcade

Word “videogame” is for me a big piece of my youth. I spent many hours playing with arcade games when I was young and many of them are still impressed in my mind.

For other like my grew up in the 80s a screen like this:


are immediately are commented out with something like “AHHH!!! Bubble Bobble what a great game!!”. Yes it was and in a nostalgic day I decided to bring these day to a new life.

Today it’s really simple to play with these old games, You can install MAME in one of it’s flavours and look around for game’s ROM (note: isn’t legal to own ROMS file of games You don’t own). But I was looking for something more, I was looking for reproduce THE FULL EXPERIENCE.

What I wanted was to reproduce the experience of arcade game and for this was mandatory to make one. So I made a custom arcade game cabinet, indeed I made a miniature version of it.

In the Internet there are many projects about making a custom arcade machine but I tried to make one from scratch. As hardware platform I used a RaspberryPI with a custom Linux distribution specifically made for this kind of games : PiMAME. I made the cabinet laser cutting some MDF wood, I don’t own a laser cut machine so I made the CAD drawing and I used vectorealism, a really good online service for laser cut and also 3D print.

First prototype isn’t really cool but making it gave me a lot of satisfaction and experience, this is only a starting point because I’m planning to make a second version with two player support and more attention to aesthetics.

This is not the end, this is only a starting point. With experience I gave making the first prototype now I planning to make a second device with more ambitious targets:

  1. Two player
  2. More powerful board (I’m evaluating many like BeagleBone Black, Phoenix A20,…)
  3. More attention to cabinet esthetic
  4. Simple to build, I’m thinking about a system where cabinet can be assembled like an Ikea one

I’ll post in my blog progress of this second phase.



Domitio is a classic always open project with a no real end. Its purpose is to automate some house tasks like:

  • Handling sprinkler timers
  • Handling house temperature
  • Managing electrical power

Some tasks already works some other partially and others are still in development. Domitio is deliberately an heterogeneous system, I used (and presumably I’ll use) many different devices and technologies for many reasons. First because advancing slowly technology evolve and solutions used in past are overcome by new (and often cheap) ones.

An example of this is the sprinkler controller, this was made (about three years ago) using a Fox Board G20, today most likely I would choose a different hardware and maybe a different approach. Evolving speed of technology is a common problem in industry, in my case without market requirements I can choose what I like when I like it, but in a industrial approach this isn’t the right way.

Working with different technologies which contribute to the same goal it’s a good challenge because I need to face many problems. First I need a “glue” to make different parts communicate each other, this glue is made by protocols and software.

For the software I chosen  Python as main language, but I used also C/C++ for some parts. Talking of protocols I started looking for one specifically made for domotics, I found many but  I got the impression that often are vendor specific, closed or based on obsoletes ideas. Out of curiosity some of these are X-10, UPB, Z-Wave, Insteon… Abandoned these protocols I decided to use the today ubiquitous TCP/IP as transport and web protocols as Application layer.

At this time Domitio is made of these components:

  • Sprinkler control (fox board G20)
  • Gas boiler controlled by Arduino with bluetooth shield
  • Pellet stove controlled by Arduino Yún