Rob Howard

The Top Five Reasons to Upgrade to the Google Cast SDK v3 for iOS

At L4 Digital, we’ve been working with the Cast SDK from the very first version, well actually a little earlier than that, and we were thrilled to see that the Cast SDK V3 launched earlier this week.  From an application developer’s point of view, this version is a significant improvement over the last.  We have added cast features to several apps in the market and now we would like to share our experiences with the top five reasons to use the new iOS Cast SDK:

1 – Simple Device Discovery and Session Management

If you walk through the previous version of the Cast SDK, there are five steps to complete before you can get media playing on a remote device.  Most of those steps are with device and session management. They include things like device scanning, device selection, media session creation, and event handling.  Many of those involve creating new UI screens and views in your application specific to handling cast only features.

In the latest Cast SDK, Google has reduced or eliminated much of this work.  The SDK eliminates the need for device scanning, includes new view controllers for device selection, and also includes automatic handling of session creation / teardown logic.  This single update to the SDK gives the most in terms of time saved and reduction of potential bugs introduced.  More logic and UI provided by the Cast framework means less test cost when the QA teams take a look, less code to review during implementation, and less of an upgrade cost when future SDK versions are released.

Pasted image at 2016_06_28 04_00 PM


2 – The New Cast Dialog and Media Controller

In the latest Cast SDK, Google replaced the Media Control Channel class with a new Remote Media Client class (GCKRemoteMediaClient).  This is a more convenient interface for interacting with media and it’s functions.  They also introduced a new UI Media Controller class (GCKUIMediaController) to make it easy for developers to bind UI controls in their own views with the Cast data sources.  Binding the UI controls to the Cast SDK methods is a pretty helpful and powerful function.  It removes the polling methods developers have needed in the past, making things easy to keep in sync.  If you have or are looking to implement the autoplay and queueing features for Cast, this UI binding is almost a must have.  It will keep your views up to date when you start testing with multiple senders, a pretty difficult work item with the previous SDK.  If you’ve already implemented a previous version of Google Casting in your application, get ready to start removing old code that was tough to debug and feel good that your application is more simple with these new updates.

3 – Cast Persistent Controls

Cast applications should always allow the user to control content when casting to a receiver.  In order to accomplish this, one of the components to a sender application must be through persistent controls.  These controls should appear whenever the user navigates away from the current content page or the expanded controls.  Before the latest Cast SDK, persistent controls were something that application authors had to implement themselves.  This work includes new UI components, event handlers, and messaging to the receiver for updates.  It’s yet another thing that is specialized for Google Casting that introduces more scope, more potential for bugs, and maintenance in the future.

Thankfully, the version SDK v3 introduces its own built in container view controller that has sender persistent controls.  It shows the controls only when casting, hide when not; It takes nearly all of the work on this feature away from developers implementing Cast in their own app.

4 – Cast Button

Maintaining state with Cast sessions and devices, as seen from reason #1, was one of the most costly components for implementation.  The new SDK provides a Cast button class (GCKUICastButton) that extends UIButton.  This new Cast button will do much of the work that developers were required in the previous Cast versions including hiding when there are no Cast devices available, showing the proper connection states, and even providing the animations for when a sender is connecting to a cast session.  One other nice to have feature with the new Cast button class is that you can override the default images with your own to match the styles and colors of your own application.

5 – Cast Introduction Dialog

In the Cast Design Checklist, one of the first things that you need to implement is an introduction to the Cast Button. The screen should show the app is Cast-enabled and visually highlight the Cast Button, which is helpful for new users.  The developer must interpret how to implement the workflow and language support.

With the Cast V3 SDK, the Cast Button is included with a simple call to the cast context with a method, presentCastInstructionsViewControllerOnce, to present cast instructions.  A built in view controller with highlighting will load in addition to instructions that are part of the library.  It’s yet another item that app writers won’t have to worry about or maintain for the Cast features.



All of us at L4 Digital are excited to see the advancement and improvements in the Google Cast product and SDK.  The latest version, Cast SDK v3, provides new opportunities for teams to implement Cast features in their own applications.  For application developers that are looking to work with casting for the first time, it’s going to be a lot easier than in the past; and for the apps that already support casting, we’ve found a few good reasons to upgrade.


Image courtesy of Thomas Kvistholt for Unsplash.

Rob Howard

As Director of Technology at L4 Digital, Rob has built digital solutions on all major platforms. His team focuses on solid development practices, keeping up to date on the latest and greatest mobile and digital development technologies and ensuring clients have a successful execution of their digital strategies.

Share this:

More Posts

Want Alerts When We Post New Stuff?
L4 Digital. All rights reserved. All wrongs reserved. © 2008-2017