The streaming app requirements you didn’t write.

By the time development starts on a streaming app, the product team has usually spent months deciding what the experience should look like. There are designs to follow and technical requirements that describe how the app should behave. It can feel like the specification is complete.

Then there are the requirements you didn’t write. Samsung, LG, Comcast, and other platforms have their own certification criteria and technical constraints that apps must meet to be approved and supported on their devices. Some reach surprisingly deep into how the app behaves, so waiting until submission to think about certification can leave development teams revisiting decisions they made months earlier.

Your requirements are only part of the specification.

Think of your product requirements like the blueprint for a house. The blueprint might capture exactly what the owner wants to build, but the construction still has to comply with the local building code. If you don’t look at that code until the house is nearly finished, seemingly small requirements can become expensive changes.

Streaming apps work in much the same way. Your specification describes the experience you want to create, while the platform’s certification criteria introduce another set of requirements for how that experience has to work on its devices. Those requirements also vary between platforms, so an app that satisfies one vendor’s criteria may still need changes before it can be certified somewhere else.

We’ve been through enough certification cycles at REDspace to see how easily some of these requirements can be overlooked early in development. Clients generally know the product they want to build. They may be much less familiar with the details a particular platform will scrutinize once that product reaches certification.

Late surprises can create bigger problems.

Getting a defect back during certification doesn’t automatically mean something has gone badly wrong. Many defects are relatively small, and the development team can fix the issue before resubmitting the app. The harder situations tend to arise when a requirement reaches deeper into decisions that have already been made about the product or its underlying architecture.

Imagine discovering late in development that a platform expects an interaction your application wasn’t designed to support. Adding it may require more than another ticket in the backlog if the architecture makes the new behaviour difficult to accommodate. The team can find itself refactoring existing code to satisfy a requirement that could have influenced the original implementation.

Ali Hashemi, a Team Lead and Staff Developer at REDspace, has seen that distinction during certification work. “Most of the time, those defects are easy,” he says. “But if the app is architected in a way that can’t support the requirement, then we may need to do a lot of refactoring and change the code to support it.”

There are also practical consequences when a certification submission comes back with a long list of defects. Each individual issue may be manageable, but working through dozens of them takes time and can push out the next submission. Certification becomes much easier to plan around when common platform requirements have already influenced the UX and technical decisions made earlier in development.

Questions worth asking before you build.

There isn’t a universal certification checklist for streaming apps. Requirements differ between platforms, and even similar features can behave differently depending on the device you’re targeting. Still, there are several questions worth asking while you have room to make decisions about how the app will work.

• How will your app handle accessibility requirements? Accessibility is one of the areas where seemingly minor details can lead to certification defects. If someone is using a screen reader, for example, highlighting a piece of content may need to communicate more than its title. The user might also need to know where that item sits within a larger collection. Every interactive element needs to provide enough information for someone using accessibility features to understand what’s happening on screen.

• What happens when someone changes a device-level setting? Viewers make choices outside your app that can affect how it should behave once it’s running. Someone might change the language of the device or adjust how subtitles appear, while another viewer might disable access to an advertising identifier. Depending on the platform, the app may be expected to detect those settings through device APIs and respect them while the viewer continues using the experience. These requirements are particularly easy to miss when the team is focused primarily on settings controlled from inside the app.

• Can the experience run reliably on the hardware you’re targeting? Some set-top boxes have limited processing power and memory, including devices that have been sitting in customers’ homes for years. At the same time, platforms can set specific expectations for how quickly an app launches or responds when someone presses a button on the remote. Loading too many large images can create memory problems on constrained hardware, while a player that performs well elsewhere might struggle to meet time-to-first-frame expectations on an older device. Performance testing needs to reflect the actual hardware the app will encounter rather than relying on assumptions based on newer devices.

• What happens when someone enters the app through a deep link? A viewer might find a movie or live event from the television’s home screen and expect to land directly on that content inside your app. The path becomes more complicated if the viewer still needs to authenticate or choose a profile before playback can begin. The app may already be running when a second deep link arrives, which means it has to recognize the new destination and navigate accordingly. These states need to be accounted for if deep linking is going to behave reliably during certification.

• Does your UX account for the quirks of each platform? Even familiar interactions can carry different expectations from one device to another. Voice commands on a remote may need to trigger playback controls, while LG’s pointer-style remotes introduce behaviours that don’t exist on every television. Exit behaviour can also vary, with some devices expecting an app to close and others expecting it to remain running in the background. A UX that feels perfectly reasonable in isolation can still conflict with the conventions a platform expects certified apps to follow.

Leave room for the requirements you can’t predict.

Asking these questions won’t catch every requirement that could surface during certification. No team is going to anticipate every issue a certification process might uncover, and each platform has its own criteria and edge cases. They do, however, represent a good starting point for catching some of the most common issues that can hold up approval. And a good architecture should give the team enough flexibility to respond when those surprises eventually surface.