Edditorial

If you read the Google Cast API, you know exactly why it is called ChromeCast: the receiver device simply runs a boiled-down version of the Chrome browser and listens for commands sent by sender applications. It seems to also be able to run custom applications as the receiver in the device, as long as it is not resource intensive and it's a regular web application. So the important take-away is that there will be two applications at play, most likely maintained in two separate code bases (not to mention the number of programming languages involved).

Saying there is no SDK for AppleTV is misleading: it's true that there is no way to create custom applications to run on AppleTV (yet), but there is an API to use AirPlay/AppleTV as a second screen. The emphasis is on second screen: there is only one app that simply render content to two screens. The app just sees a second UIWindow instance and renders views on to it as usual, and the system takes care of the rest. It's inherently simple, and there is one codebase and most likely one programming language involved. Apps like Real Racing 2 HD and the Redfin app are taking very good advantage of this well-documented feature. With Mavericks, users can set up an AppleTV as a regular external monitor at the system level, so it's even simpler for developers: if your Mac app can deal with dual monitors, you can utilize AppleTV. Compare this to a Google Cast application: to use the receiver device as a second screen, you either create a dedicated receiver application and get the main app to communicate to it by commands, or you have to roll out your own implementation of a virtual screen: have your UI code draw to a virtual screen, encode the screen pixels as video stream and get receiver to play that stream. The former method is too limited and latter is too cumbersome (and likely infeasible without hardware support).