The Fourth Platform: How Vega Got Us Surprisingly Close to “Write Once, Run Everywhere”

The fourth platform, however, got a surprising close to WriteOnce, RunEverywhere, and Promise. This is a case study from Zotoo, where you're going to learn how this fourth platform reshapes it the way we shape the other three. Because of over a decade, we onboarded applications to the different platforms, to the web, Android, Apple, and each with its own code base, its own team, own release schedule, which were very fragmented and different and hard to think.

A few years ago, Amazon showed us Vega, a new operating system where React Native is a primary UI framework. And we took it as an opportunity to build over it something that is truly multi-platform. And now, this totally changed the way how we shape other three. Today, we have one code base on every screen, shaped at every sprint. And this story is impossible to tell only from the technology perspective. So, you will see also product and organization point of view.

Hi, I'm Bo. And I'm a principal engineer at Zotoo. I'm also co-organizing the React Berlin meetup. And I'm proud of daughter and son. And I'm enjoying hiking with my wife wherever she brings us. And I wanted to say I own the dog, but it's kind of vice versa. So, yeah, you can also notice some anime style of this presentation. I took it as one of the most fast-growing content we distribute. So, who is Zotoo? And what we are doing? Our product is streaming. We are a streaming company. And we are trying to make it easy for our customers and users, whatever device or technology they bring. And this literally means meeting people in their moments they live. And I will give you an example from my life or my family life. Where we gather on the Christmas Eve to watch our favorite Christmas movie on the big screen.

Or when I'm on the go, watching the favorite football match and cheering and supporting my team on the mobile. Or if you're on the long trip and kids are super bored and would like to watch their favorite show on multimedia screens. And basically in any situation from any device. For example, when I'm sipping morning coffee and could see news on a fridge. Literally one day we put our application into the fridge and it worked. And this comes, of course, with challenges.

To meet people in their devices, their life. Because it could be anything, right? It could stream a video. And in our case, we kind of separate it into two experiences. One is mobile, when you have something in your hand. And other is big screen. And this is more niche. Also more broader portfolio of devices. Where we have unique expertise. Will it be smart screen? Or, I don't know, a gaming station like Xbox. Or plug-in devices like Chromecast or Apple TV, Fire Stick. And of course web browsers.

And mostly all of these devices are working on the three platforms. Apple, Android, web. And we recognize some clients that we are distributing unique applications to. For instance, for Apple it could be TVOS. And iOS for Android is Android TV, Android mobile, Fire OS, set-up boxes, some Android tablets. Very diverse comparing to Apple. And web, you know, is just crazy. Whatever can have a browser inside, it can stream a video. And it could be, I don't know, Chrome Safari, Firefox. But it could also be a smart TV with web-based operating systems. Or Fridge that I mentioned on Chromium browser. And we are known not only as the tool in the DACH region, but as a white-label solution for customers all around the globe.

And we are known not only as the tool in the DACH region, but as a white-label solution for customers all around the globe. And in the end, like if you multiply everything, it's hundreds of applications to ship. And this is challenging on this scale. And over the years, every new platform multiplied our effort instead of extending it. We always wanted to be somewhere on the site where everything is shared. However, the situation a few years ago was like that. We had existing applications with own application logic, with own testing layers and suits, with own technology inside, driven by own team. So imagine to onboard something else to that. That would require quite a significant budget and will overcomplicate alignment. And it would be super great if the teams, for example, that were working on the quarter one on one feature, quarter two on another, quarter three, let's say on favorites, could actually free up their resources and don't care much about technology specifics, but rather focus on their features, on their stream values. And over the years, there was several failed attempts for us to reach this. And it's impossible to just take all the different technology engineers and put it into one team. Otherwise, it will be just engineers sitting in the same channel still shipping three different applications. People need to talk the same language. And we tried to find a way how to do it.

In 2019, 2020, we just shipped the PWA application. And this was super promising technology. And Google invested a lot in Project Fuga. And we had some success story. For example, we were able to replace this PWA, our Windows experience, built on the C Sharp. And it wasn't that good for others. For example, Android Mobile, despite we built PWA or TWA in this case, and we were able to show like provide it to our customers with full feature parity, some things were not accessible to us. For example, DRM. If you're in the streaming business, you have different DRM protection levels. And for a browser, unfortunately, there is only shallow level available. And there is no way how you can get hard DRM protection, for example, to protect your Hollywood blockbuster streams or some unique sports events. And of course, performance was a bit different, especially with animations. So we got another round, this kind of hybrid approach, and take a look on if we can build, for example, playback experience in native and have a rounded web experience. But still, it wasn't matching our quality and performance expectations. Then in 2021, 2022, we take a look on a multiplatform solution like Kotlin.

It was in beta at the time, I guess. And the Flutter, but the story was the same. The amount of devices we covered just wasn't there. They were good with mobiles, but not with big screens. And kind of similar story was with React Native.

However, there was Community Fork supporting Android TV and TVOS. However, at the time, that was not really looking credible to us because there was only a couple of enthusiasts supporting it. And then there was a catalyst. Late 22, we received an invitation from Amazon alongside with other streaming developers for a demo in Berlin office. And what they showed to us was quite mind-blowing.

So first thing they announced that they're going away from Android-based first. They're going to build a new system based on the Linux and C++ as a native layer. But the most surprising thing for us was that this is going to be a system that's based on the React Native as primary UI framework, bundled into the operation system. Meaning unlike Android or TVOS with React Native, there is no bridge between. It's just direct translation of React Native into close to hardware code.

And we took a look at that and made some aftermaths, which was a SWOT analysis and highlighted some strengths for us because we already have a good web ecosystem, which is very close to React Native. Also, it was on the React, right? We have senior engineers with some strategic mindset eager to try it out. From weaknesses, we don't really have React Native specific expertise. And also, it seems like to us in the way how we approach the problem before, we will have to budget new Vegas squad to support this platform.

But there was opportunities and very good ones like Majin are willing to have a cross-platform unification. And there was like hesitation and big threat if you are not going to support this one because Firebase is one of our biggest clients, and this is also a rare opportunity to pioneer something like that new. So we wanted to take this chance. And not only take it as a chance to build for Amazon, but we saw it as a chance to build with them. Because for us, it became a point where we're shifting from another platform to actually build on this platform, multi-platform solutions.

And for Amazon, of course, they could get our application in their portfolio or the feedback as we know, as pioneers in many different directions. For instance, we were one of the first who shipped together with Google Chromecast. And strategic importance was clear, but the roadmap was full and engineering capacity was already allocated. So we received kind of no from our management. But we still see this is coming and started a little bit preparing for a possible direction. And we just allocated one engineer for sprints to try it out, to build a proof of concept, like to check if we can do very basic stuff.

And that was provided and it actually worked. So we took web and Android TV and built them together with an existing code base. And this proof of concept showed us that we can log in and authenticate in our system, also start talking with our backend. And most importantly, can play our streams with the same quality as we had in our live application. And not just we could build this as a React Native prototype, we were able to integrate it into the existing code base.

And then suddenly, we got the green light. And it was not actually related to the proof of concept, but to other things. We just became operationally slow and like this alignment, these differences in the technology ecosystem was a pain for us. And our new CTO, when he joined, declared our frontend resource intensive and wanted to change it. And then obviously, proof of concept was on the table and pick it up as a risky bet, but a very promising thing that could change the way we work in a good way.

So migration at practice, how we did it. UTV, and when I'm going to refer to UTV, that stands for a universal TV project. And we put the word universal in mind that it could ship anything. So we started it and plugged it into our monorepo code base, web code base. It already served different projects like web application, PWA that I mentioned before, smart TVs application, Chromecast, many, many others. So React Native started as yet another project there, piped in in the existing infrastructure.

And that also allowed us to use the business logic and the shared layer configurations as well that other projects were using because of JavaScript. And our business logic is written in pure JavaScript. It doesn't matter where you pipe it in. And what helped us and especially in this building up together with Amazon where we built together application with operating system, which changed it and wasn't like immature enough or production ready a few years ago.

Build time overwrites when we market our files and resolve it on the building level with specific platform or alias of platform. So we were able to skip some things that were not ready and still ship other platforms, but also treat like some platform specifics in a good way where you can strip it down and don't ship it as you would do in runtime to specific bundle. And generally the biggest surprise for us in all this development, like some specifics, platform specifics were very thin layer.

For instance, like I guess the biggest was Android, maybe Apple, where you need to for some models build it in the native language. For instance, for Vega, it was layer of Metron Bundler, but all the rest was resolving as a regular non-model. So React Native models. Yeah. And Web, obviously we already had this in the system. And then in summer in 2024, and I remember this moment where we spent two nights and two days with one engineer trying to buy in Vega, because it has like a different resolving mechanic than the Metron Bundler.

But in the end, we figured it out. And what you see on the screen is the very first view of Vega. Nowadays, everything is much more easy. Amazon has amazing instruction. We can do multiplatform and like examples that you can just copy and plug in.

Other thing for us that was quite challenging, I would say, is that there was no multiplatform testing solution. So every system shipped with its own thing, and like developing something like multiplatform is resource extensive. So you can get quickly to the degradation if you don't look on all the four platforms, but it's also hard. So if you have some test layer that's ensuring it for you, that is great.

And we built such thing in-house. We call it Universal System. This framework already covered web and Android and still building Apple. The whole point of it, we're still writing play-write test. Maybe this is a little bit more abstract syntax. Kind of compared React to React Native.

And then we're waiting for it in the platform-specific engines, like a web driver or Appium. And what's interesting, if you are familiar with Convince law, all this transformation technology was also connected to organization transition that I will touch on a little bit later. So Convince law says that any organization that design a system will produce a design whose structure is a copy of the organization communication structure.

So Convince law says that any organization that design a system will produce a design whose structure is a copy of the organization communication structure. And this has happened for us. So within the years we shaped our organization differently. And it was reflected in the code base which allowed us to isolate some domains owned by teams. So within the monorepo they could be autonomous and move fast.

What was the product look for this migration that allowed us to build it up? One of the most important strategic decisions for us was like keep user experience consistent. Don't try to change technology and also experience. Because we wanted also to measure how this new technology performed. And if you perform something that is different, it's hard. So we restricted redesign on purpose.

However, there was some things we couldn't resist and added some small incremental improvements that wouldn't affect user experience much, like habits I mean, but would improve something that was always a struggle. So for instance, whenever our users were forgetting passwords, restoring them on the big screen was a pain because of the debug typing. So we just introduced a QR code. And there was several other things like that that we did all over.

And when we released our first beta, it was quite positively accepted by our customers. And if you ever ship a new technology or rewrite everything from the scratch, you know how people, how our users react on changes. And this transition was quite smooth and matching the experience they already love. And one interesting topic in this one is how we transition our technology kingdoms into stream value organization. And there is a very interesting book I would suggest to read if you are in this topic. It generally can apply to any company on any scale. And it describes different topologies of teams and how they could be mixed together.

Our journey was over the years. We started in 2023 with some foundation team to try out things. And then brought our first external expertise because we didn't have React native expertise in-house. And then it helped us also to scale and bring others to this transformation. And in the end in 2025, the whole organization moved to stream-aligned organization. So it's shaped us not only from the technology but from how we align with each other. So let me dive into that. We started very humble, as I mentioned. In 2023 we formed a UTV team, which wasn't much different from the projects team we had before. We were doing everything, like platform things, feature development for feature parity, video, all the infrastructure. But for React native.

And this team gained some expertise. And after the team was confident to work on, we split it. And half of the team get new team members from existing engineers and started to help them to onboard to the new technology. And we also added principal engineers to support these teams and this transition by mentoring them. So we started a little bit accelerated. But still it was kind of two projects team doing the same, but still owning everything. And then in 2025, we started more interesting things. We started to locate some domains. So these teams that were previously working on everything started to focus only on the feature development. While we added another team that took all the platform specific and also added a team that offloaded others from the infrastructure or code quality topics. And, of course, principal engineers were still supporting all of this alignment, which worked. Some were good, some were not.

And then after through the learnings of 2025, we came to the model as of today, where everything worked pretty smooth, I would say. Teams could focus on their area of responsibilities. We recognize the domain of ownership and specific topics. For instance, we have a team playing watch, which is in the video domain and handling everything around it. Like video obviously, playback, OSD, video us. On another side, we have content, finding discovery team that takes care on bringing users to the videos through the collections discovery. We also have format platform chapters to have this expertise that we gained. And also transferring our native developers with their unique expertise to the platform-focused teams. And we extended infrastructure and code quality team and platform team into front-end technology chapter, which takes care about everything else.

And, yeah, what we learned from that? Three things that we will defend without hesitation is that we were going to the brownfield solution at the greenfield. We didn't fork it into another platform or didn't try to recreate everything from scratch. We bundled in and it saved us a lot of time and a lot of bugs. We definitely go for domain organized code-based structure, because it works great and creates this isolation where teams are autonomous and could move faster and not depend on each other. And more like a niche technology thing is build time overwrite, of course. This is pretty common pattern that is, I'm not sure if it's like very popular in React Native, but for instance, in the C Sharp or others, such things help to really isolate some specifics. So having this one from the beginning, yeah, was very helpful.

And there was some things that we could do different, and if we would know it, we would definitely invest into infrastructure earlier and, of course, bringing some React Native expertise earlier without trying to figure it out everything on ourselves. Having someone who already has and gain this expertise is very important because it can accelerate teams significantly. One of the technology findings was that Vega and Web are pretty close to each other. And that was basically JavaScript layer translated directly into hardware specifics. From the product learning, I would say we made some mistakes changing experience, and it was very harshly perceived by the user. So even minor UX change triggered like a masher of feedback. The reality is that we have to shift all of our screens, all of our applications. Android was definitely one of the most challenging because of fragmentation and amount of devices and their variations, unlike Apple or Fire OS, where we have a long list of devices. But overall, one of the prominent product outcomes was that this technology innovation accelerated our ability to ship. And this bet paid off in the numbers. We are already a year in production with our first applications. And this is very comparable to our native application that we are gradually replacing using the same crash rate. There was zero major incidents. There was zero capabilities we couldn't deliver.

And if you compare, for example, last quarter from last year and quarter one of this year, our performance and ability to deliver features grow like 25% quarter almost. Of course, there is some percent here from like a greater AI adoption, but we already had this in the previous. So you can literally feel how it's more energizing everyone, how everyone could ship and focus on their own things.

And from another angle, like this journey showed us that the community and overall outer world still think that React Native is only about mobiles, about iOS or Android, which is clearly not because there is much more to this world that we can do with these amazing things. Hopefully, with Amazon as a big player joining this race, we'll have more standards, more recognition, and more universality.

In September last year, we shipped our first Android TV, and then in October, we fulfilled our promise to Amazon to deliver an application for them. Later, in April this year, we also started to replace our legacy fireware systems with Android. So Android and Android. But we are also just now shipping Apple TV as beta and looking forward this fall to have smart TVs. Next year, we are planning to get into the mobile devices, choosing not to build yet another project but aim for a universal approach with a responsive strategy.