Useful Tips for Product Teams working on Samsung Smart TV apps

If you are a Digital Product Manager or Lead Developer in charge of video streaming apps, you probably have worked on your company’s OTT apps for the most popular platforms like Apple TV, FireTV and Roku. But what about apps that run directly on the TV such as Samsung Smart TV?

I want to share some tips we have learned the-hard-way while developing apps for Tizen, the operating system of Samsung Smart TVs. Unlike the app platforms operated by Apple, Google, and Amazon, the Samsung / Tizen platform is less known by the developer community, has less up-to-date documentation available and relies on more manual (less automated) certification and app release processes.

If I had to describe Tizen in the OTT apps space, I would say it is “a wolf in sheep’s clothing”.

If you read the documentation about it, you will get the impression that you just have to build a simple HTML5 browser app… easy!. That sounds like a quick project, “build once and run on any browser”. I am sorry to tell you that nothing could be further from the truth.

As a Product Manager, you want to be able to budget the right amount of time and resources for development, testing, certification process and maintenance of your app. The initial impression of an “easy HTML5 browser app” causes many issues if you are not aware of the nature of the platform and the work it takes to get from DONE on the development environment to LAUNCHED on the actual physical devices.

For that reason, we have compiled a short list of tips (in no particular order) to be aware of before you embark on a Samsung Smart TV app project.

If you take these into consideration, you will save yourself a significant amount of time, money and frustrations.

1. Don’t trust the Tizen Studio simulator, test on physical devices

The development tool used for the Samsung Smart TV apps is called Tizen Studio. It allows you to create the project, run the app on a simulator which is basically running on a Chrome browser on your development computer. Everything (or mostly everything) runs pretty smoothly on the simulator, specifically HTML transitions, animations, scrolling between rows, video playback, etc. The simulator uses all of the resources of your development computer to run the HTML/JS/CSS app and this usually means that everything will run without a glitch.

Now, the next step on the development process is to test on the physical devices. The first step on this process is to send the code directly from the development computer to a TV. Tizen studio allows you to connect a TV to the development computer easily via the local network and send the app to it. This is when you start seeing the actual experience of running your app on the TV, which is not as resource-rich as your computer. You will notice transitions, load times, scrolling and other key user experience aspects of your app performing poorly.

We recommend, pushing your app directly to the TVs as soon as possible, not waiting until you have a complete feature set done. Instead, you should push often and test on the TV.

Also, you will find significant performance and rendering differences between models, which go all the way back to 2015. The app will behave differently on each model, so in order to be sure your app will pass the certification process, you need to have at least one physical device of each model year (2015–2019) or make the decision of not supporting older models early on your process, that way you don’t have to budget for time and costs for specific compatibility issues you will discover along the way.

2. Share the specs of your video streams with Samsung and test playback of those on your physical devices

One of the first steps that your Samsung contact will provide you with is a document requesting specifications of your app and video streaming format, codec, bitrates, and other details. Make sure you provide this information early on the process and as soon as you have developed the basic video playback functions of your app (using the Samsung recommended player, AVPlay) test playback on the devices, specifically:

  • Video starts and buffering
  • Uninterrupted playback of a single content for 30 minutes
  • Pause, Fast Forward, Rewind and resume (re-buffering) of content
  • If your app supports Ad Breaks, be sure to test those transitions between main content and Ads
  • If your app supports both VOD (Video-on-Demand) and Live streams, test both independently
  • If your app supports tve (TV Everywhere), test both gated and ungated content independently.
  • Make sure closed captions are supported on your video streams and render correctly during playback (when turned on)

You could find scenarios where your video streams don’t work at all on the devices while they work perfectly on the simulator or cases where they work correctly on some models (2015–2016) and not on others (2017–2019).

If you spot these issues and have shared your video streaming specs with Samsung early in the process, you will be able to adjust without compromising your timing and deadlines too much, while at the same time create support tickets with Samsung’s engineering support team to help you solve the issues.

If AVPlay doesn’t work for your specific case, there are alternatives like HLS.js. However, if you chose this route Samsung will not be able to help you on any support issues for that particular video library. They only support AVPlay officially.

3. Certification Process and Launch

Unlike the Apple or Google app stores, where the certification process for apps takes a couple of days and in most cases just hours, the Samsung Store (Seller Office) usually takes between a one and two weeks for the full certification of an app. The app is manually tested by the certification team on physical devices, usually 2 to 3 models per year (years from 2015–2019).

In our experience, the first time you submit your app for certification you will most likely not pass right away and you will receive an initial batch of issues that you need to fix prior to release. Some issues are classified as Critical, focus on those first since these will block the release of your app.

It’s highly recommended to submit an early version of your app even if you are not done with all the features so the initial issues are brought to your attention sooner rather than later. Since each model behaves slightly differently, most issues will apply to all models but some might be specific to just a few models and require extra effort to work on a special-case solution.

It also helps if you plan your launch strategy prioritizing the most recent models for initial launch (2019, 2018, 2017) and then continue with older models. If possible, don’t commit to a release on all models simultaneously, as one minor incompatibility issue on an older model could end up blocking the whole release.

Before submitting your app for certification, double check the items on this list:

4. Don’t assume you will be able to apply hotfixes quickly

The Seller Office (Samsung’s app store) doesn’t have an expedited process for testing. Even if an update is minor and very focused on just one issue, it will go through the regular testing and certification process.

We have had situations where a minor code error goes live and the impact of this mistake is big in terms of reporting. Usually, you’d want to rollback the version and/or immediately release a hotfix within the next 12–24 hours. This is not possible on the Seller Office, any update to the app requires a new build and version number to be submitted and processed on the regular one to two week period, so make sure your internal QA processes are thorough as you will not be able to quickly fix any issues that go live on a release.

Having said that, even though the Seller Office doesn’t have an official self-service option for this, you will most likely work with an assigned technical account manager from Samsung’s side and he or she will be able to help out expediting the process. In our experience, this resource has been able to help speed up the process in such special and urgent cases, but you can’t rely on it consistently.

5. Give special attention to Accessibility features

If you want your app to pass the certification process, then you should be aware that Accessibility features such as Text-to-Speech (TTS) and Closed Captions are a top priority for Samsung and issues detected on these are release blockers.

Make sure that during the discovery stage of your project, you budget enough time and resources to plan and discuss TTS with the product team, developers and testers. Specify a general guideline for its implementation on every element of the UI and add specific instructions about it in your user stories. Every element that is visible in your app (nav bars, menu options, messaging, player controls, loading / buffering indicators, video metadata on tiles, etc) should be readable by the Audio Guide accessibility feature when turned on by the user.

As many other OTT platforms, closed captions support is a base requirement. However, Samsung also requires that these are customizable by the user in terms of font-face, size, color, opacity, and other visual attributes.

You can choose to use the built-in captions controls of the TV or implement your own (App UI) for better user experience. There are tradeoffs with each option, make sure you evaluate those, discuss with your Samsung account contact and confirm the support for the specific captions implementation on the video streams you will be consuming.

6.SmartHub Preview and EDEN

Samsung Smart TVs main interface is called EDEN, however, we have found that this name is not mentioned on their public documentation, it is the name that your Samsung account contact and support engineers will use to refer to the main interface elements such as the SmartHub Preview, Universal Search and Deep Linking functionalities.

Make sure you understand the requirements for the SmartHub Preview and plan on including this feature from day one on your app. This will allow you to expose the content of your application on the home screen of the TV and deep-link directly to videos from the preview shelf.

7. Performance of UI and navigation elements

Remember the first point about not trusting the Simulator? One of the main differences between running the app on the simulator and running it on the actual TV is the processing power of the device.

When you run the app on the simulator, you have the CPU and GPU of your high-end computer working on all visual elements of the app: image resizing, opacities, transitions, animations, and other smooth UI eye-candy.

You will not have such a smooth experience on the physical TV device if you abuse the use of animations, on-device image resizing, opacities and transitions between screens.

One specific and simple thing that will help with performance on the device is the proper handling of the images. Most OTT apps have a very similar layout: a big HERO image at the top and then a series of rows with content tiles (thumbnails representing shows, movies or videos). Make sure that the content thumbnail source files provided by your content API are sized as close as possible to the size you will be rendering them on the device.

For example, if your content tiles will be rendered at 200px width (on a 16x9 aspect ratio) on the TV device, try to get the actual JPG or PNG files served from the content API at the same size or as close as possible… let’s say 300px and not something like 1080px wide. This will help the device with performance because no client-side resizing of each image will be required.

Imagine what happens when a low power CPU device has to download and render 20 or 30 thumbnails at once … the app will be slow and unresponsive while these http requests get queued, files downloaded and then resized for rendering.

Closing thoughts

I hope these tips are useful for your current or future Samsung Smart TV projects. This list is not intended to be comprehensive and is based in our experience developing apps for clients in the TV industry, but there are always many new tricks to learn and improve depending on your specific case.

Whether you are working with an internal development team or an external vendor, make sure that these items are included in your conversations, analysis, estimates, and budgets… if not, then probably the team is not fully aware of the challenges that they will be soon facing and might underestimate the project.

Related Posts


What we have worked on

See some examples of the types of projects and ongoing clients we work with.

See our Work
< back to blog posts