DEV Community

Cover image for Navigating the Multi-Platform Maze: Engineering Challenges Unraveled
Oren Melamed
Oren Melamed

Posted on • Originally published at Medium

Navigating the Multi-Platform Maze: Engineering Challenges Unraveled

One of the products we build at Kaltura is an OTT streaming white-label solution that enables telco operators to reach a broad audience with their TV streaming service.

One of the challenges a telco operator may face when trying to reach a broad audience is the need to have a multi-platform solution that allows consumers to watch video in their own comfort and time. This may be at home in the living room, watching video on their big screen TV, in their rooms with an iPad or on-the-go while traveling via their mobile device.

In this post, I’ll look at the challenges a team might encounter when building a multi-platform product. If you’re going to build a team that’s going to build a multi-platform product, this post is for you!

Fragmented Ecosystems: Managing Diverse Platforms

So obviously, there are many challenges a team or an individual might encounter when building a multi-platform product. To name a few:

Diverse skill sets

Developing for multiple platforms, such as iOS, Android, and web, often requires different programming languages, frameworks, and tools. This means that developers need to possess a diverse set of skills or be willing to learn multiple technologies. Managing a team with varying expertise levels and ensuring effective knowledge sharing can be a managerial challenge.

Platform-specific considerations

Each platform has its own unique set of design guidelines, user experience expectations, performance characteristics, and technical limitations. Developers need to understand these platform-specific considerations and adapt their code and design accordingly. This requires coordination and collaboration within the team to ensure consistent and optimal experiences across platforms.

Increased complexity and maintenance

Developing for multiple platforms adds complexity to the process. Each platform may have different APIs, libraries, and features, which need to be implemented and maintained separately. This increases the overall development effort, as developers need to handle platform-specific bugs, updates, and compatibility issues. From a managerial standpoint, it requires careful planning, resource allocation, and coordination to handle these complexities effectively.

Development and deployment processes

Different platforms may have different development and deployment processes. Coordinating the release cycles, versioning, and updates across platforms can be demanding. Managing the release timelines, coordinating bug fixes and feature updates, and ensuring a smooth deployment process requires effective project management and coordination within the team.

How To Survive Fragmented Ecosystems: Managing Diverse Platforms

When we started thinking about how we would build this product, we tried to imagine the key points that would have the greatest effect on the team.

The two that came to mind were the tech stack and the internal structure of the team.

Fortunately, there are various options to address multi and cross-platform apps, like React Native and Flutter, which are two good options. Even fully-fledged native development per platform could be a solution, depending on the product requirement.

Native solution — we didn’t go down this path, as it didn’t provide us with tools to share code between platforms and move team members between platforms according to necessity.

Flutter — the team decided back when we started (more than 2 years ago) that it was not mature enough and didn’t have support for tvOS.

The tech stack we eventually chose was React for web and smart TVs, and React Native for Apple TV, Android TV, tablets and mobile devices.

Back in the day, when we started the project, we reviewed the different tech stack options. We came to the conclusion that React and React Native were adjacent enough to provide us with internal sourcing between FE teams. They were also mature enough and had a good community around them to be reliable choices with a long lifetime of support.

The internal structure we chose for the project was 4 FE teams, one for web browsers, one for Smart TVs, one for Apple TV, Android TV, and tablets and mobile devices (from now on, I’ll address them as RN, short for React Native), and one core team to build the shared logic that would be used across all 3 Platform FE teams.

This structure was decided to support the business requirements of shipping different platforms at different times. Having a dedicated team per platform promised that each team could advance independently, and also be able to have per-platform-specific expertise, such as video streaming, which has its quirks on each platform.

High level system design

Look at me now: What we achieved and learned along the way

Overall, the above structure and tech stack brought us to the production stage with hundreds of thousands of households consuming TV services, each with multiple devices using different platforms.

Among the lessons learned, I’ll share a few, some specific to our chosen structure and some general considerations that need to be taken in mind when coming to build such a product development team:

Avoid bottlenecks, think ahead

The core team’s role is to provide infra and API to all teams, and they are sometimes faced with different dates when a specific platform develops and ships. This means the core team needs to think ahead of how data is consumed in an optimized way between different platforms, each with its own unique constraints (mainly memory related).

Utilizing team resources in the best way possible

One contender when we chose a mixed React and React Native solution was a library called react-native-web, which enables writing with React Native syntax (, , etc.), but compiles to web target. At the time that the project started, it was in its initial stage, and we opted out of going that way. If we were to start a project today with the same requirements, we would definitely research going with a React Native-only project and have react-native-web to compile the web targets (web and smart TVs) too.
This decision has a major effect on the possible structure of the team and its required expertise.

To expand on the above point, there is also good potential in using Expo to eliminate some of the requirements needed to set up the project for native platforms for iOS and Android. It has little support for tvOS out-of-the-box to this date, but hopefully, this is coming soon…

The art of building a multi-platform engineering team

Building a successful multi-platform engineering team is truly an art, requiring a delicate balance of diverse expertise, effective collaboration, and adaptability.

There are various ways to structure your team to handle multi-platform FE development. You will need to find the one most appropriate to your team’s skill level, maturity and size, among a handful of additional considerations.

In Kaltura, we carefully organized the team to align with the unique demands of this product, considering the impact of our chosen technical stack on this decision. Moreover, we recognized that had we commenced this project today, we could have explored alternative options, taking advantage of the existing solutions now at our disposal.

I hope the points shared in this post will help you in your decision-making.

Image by rawpixel.com on Freepik

Top comments (0)