Those of us in the payTV business know that the industry is going through unprecedented changes along multiple vectors. One of the vectors is driven by the desire for consumers to consume content on devices that are convenient for them. Offering services to multiple devices means that operators need to support applications in multiple application stores from Android to Amazon to Roku to Apple. This blog discusses the key challenges and considerations associated with delivering a TV service to applications across multiple app stores.
Breadth of devices and operating systems to be supported
Devices and their operating system ecosystems are continuously evolving. Samsung introduces a new device; Roku introduces a new operating system version; Apple issues a fix for a security issue; Google requires that software libraries are at a certain minimum version. These are some examples, but this is relentless and unless your application keeps up then it may not be permitted to be placed in the app store or it may be removed. So even if there are no new features and functions in your application you need to keep monitoring, testing, and updating on an almost continuous basis.
App store policies
App stores require applications to adhere to their rules (policies) to be posted. These policies can relate to issues such as the type of content shown, rights to show content, user privacy, advertisements, or monetization. For example, in 2021 Apple made major changes on their platform related to user privacy, requiring that users opt-in to any sharing of data for advertising. This required application developers to provide evidence to ensure their applications were in alignment with the policy. Awareness of the requirements and timely responses were required to ensure the applications could remain on the store.
UX considerations
With a TV service, there is a desire to ensure it is consistently delivered across all devices. But it is unlikely a completely consistent application across all devices will satisfy users for a couple of reasons. Firstly, the form factors and interaction models differ between devices – for example, mobile devices have a smaller screen with a swipe interaction model whereas an Amazon Fire stick has a ten-foot experience and a remote control. Secondly, device ecosystems have different nuances and consumers used to specific device ecosystems expect applications to “fit” with the model. So, an Apple phone user expects that the swipe patterns they are used to will work for the application. Ensuring that applications offer the user a compelling experience means always staying aware of changes and updates to each platform and reacting to these changes.
App store submissions
App stores have streamlined the app submission process over the years, and it is generally highly automated – and this is generally good. The challenge comes if the app submission is rejected for some reason – in these cases, the feedback can be very terse making it difficult to know why a submission may have been refused. Clarification is possible but it is via a web dialogue and responses may take some time and these responses may also be terse. This means that it may take some considerable time to really understand what has happened so the app can be updated for a successful submission.
App store behaviours
Legacy STB software delivery was under the control of the operator – meaning they would run tests and plan deployment at a time that suited them. With app stores the app is available immediately when it is posted on the app store, but, with some exceptions, users may choose when to load the application. This can lead to different users having different application versions on their devices over time. This can also be an issue if you need to push out an urgent change. Applications need to have deployment modes where minimum supported versions are enforced to ensure forced upgrades can be implemented gracefully.
Implications for operators
Trying to handle all these considerations is not rocket science technically but the number of platforms and the rate of change of each means that a dedicated team is usually required to handle this. This team is responsible for monitoring upcoming changes and being prepared for them, testing new application versions, posting applications on the store, and handling any feedback. Maintaining a team like this can be costly and divert skilled resources from other activities. For EspialTV deployments we take care of the app store considerations, so you do not have to.
