Samsung TV - BODi App

About

BODi already ran on web, mobile, and Chromecast. The gap was the living room: a native app on Samsung's smart TVs, where a large share of the audience actually wants to work out. The Chromecast solved a big part of this problem, but having a native experience is always better than a casted one, and the team wanted to ship it.

I led this one from an empty repository. Tizen OS runs web technologies, so the language was familiar — but almost nothing else was. This was the first time our team had built for a TV platform, which meant part of the job was the app and part of it was getting everyone else comfortable with a platform none of us had shipped to before.

The proposal

In October 2025, the directors came with the idea of building a BODi app for Samsung TVs to me: The goal was to create a minimum viable app, but still considering the size of the company, so a very simple MVP was not in the picture: The project should have less scope than the other web/mobile apps, but still be a complete experience for the users, with the main features of the product.

The goal: Release the Samsung TV app ASAP and communicate all the findings with the team. For me, apart from using web technologies, everything else was new: The platform, the hardware, the store, the signing process, and the certification process. I had to learn all of that and communicate with the team about it, so we could make decisions on what to build and how to build it.

The project

Building for a TV forces you to rethink a lot of web habits:

• There is no pointer. Every interaction is a directional pad and an OK button. Focus management stops being an accessibility checkbox and becomes the entire navigation model — if focus can get somewhere the user can't back out of, the app is broken.
• The hardware is modest. TV hardware is not phone hardware, and it is certainly not a laptop. Animations, list virtualization, and image sizes that are free on the web are not free here.
• The distance is different. Everything is read from across a room, so type scale, contrast, and focus states all have to be much louder than they would be on a phone.
• The platform has its own rules. Packaging, signing, certification, and the store review process are all Tizen-specific, and none of them are things you can discover at the end.
• Accessibility is not optional. The platform has a built-in screen reader, and if you don't support it, your app may be rejected.

The planning phase

The approach I took was to ask for at least 3 weeks of research and prototyping before giving an estimate for the project. I couldn't give an accurate estimate without studying the platform and the Samsung release process first. The initial estimation was 4 months. I was the only developer; the team was very small and I was still working on the web, video player and Chromecast apps, so I needed to be very careful with the estimation and the scope of the project. I also needed to communicate with the team about the platform and the challenges we would face, so every blocker or challenge was known by the team. I decided to create a Slack channel to communicate about the progress every day, and also a shared document with "TO DOs" pending for the project.

Since I had years of experience working on the BODi applications, creating this new project didn't really need detailed Jira tickets, at least not in the beginning, so I could start researching and working on the project right away, suggesting less bureaucracy in the beginning since we MUST move fast.

This was also an opportunity to use AI and put this into practice: Use AI as my copilot to make this project happen, since without it, this project would probably have taken way more time, perhaps almost a year to be completed and perhaps not even considered a viable project if the time to be developed was too long.

Development phase

I have years of experience building projects for thousands/millions of users, but this was the first time I had the chance to build something from scratch within a company and working completely alone in the development part, which means that any problem is my responsibility to solve and I'll take credit for good or bad work. As you can imagine, this project taught me a lot about project management, communication and how to set expectations with the team and the stakeholders.

During the first weeks, I made good progress that surprised the team (and even myself, to be honest), since I had a very basic application running. A few days after starting working on this completely new platform, this is what I had running:

And these were my updates during those first weeks:

In two weeks, I had a basic app running, already validating the navigation and integrating with APIs.

Note that one of the requirements of the application was to identify if it makes sense to reuse our custom video player project, reusing it and just adapting the controls to work on the new platform, or rely on the native AVPlay video player provided by the platform. Using AVPlay could provide the best performance, but that would also mean losing VHS, Conviva, Datadog and Chromecast integration logic already implemented in the custom video player. Luckily, the custom video player was working really great on the platform and just needed small tweaks to adapt the UI and controls to the new platform.

That was a good way to validate that the video player project we maintain is really good and works well on different platforms, being extensible and adaptable to what we need.

The authentication is handled by Auth0, but instead of using their SDK, we needed to integrate with their API directly, since the web-based Samsung app is a filesystem app, not running on a server, and the current implementation of this SDK used on the web is completely different. The Tizen simulator helped to test that even before testing on a real device:

While focusing on developing and testing how things work on this new platform, I was always showing new components and testing concepts at the same time. A good example is the "Jump Back In" feature: This component implemented how horizontal scrolling would work, along with the focus management, but is also a main component on the home page that the product/stakeholders would be happy to see on the initial phase of the implementation, leading me to put a big effort to make it work fast, to show real progress:

I set the dev-ready date to January 16th, 2026, since that was the date after estimating and validating each major feature to be implemented. Spoiler: I completed the scoped version before it!

The performance challenge

Until this point, I didn't have a real Samsung TV yet; the initial implementation was using the Tizen simulator. After getting a TV and debugging on a real device, the main problem arose: The TV hardware is slower than I expected. This led me to put a big effort on performance improvements, something that we don't really need to put a big effort into while working on web apps, at least not as much as I needed to put on this project: Add more caching layers, virtualization, and even using CSS properties which tell the browser if an animation is about to happen, then the browser computes the UI shifts ahead of time and provides a more fluid experience to the user. Even with years of experience, this kind of optimization was new to me, and showed me that browsers can do way more than we can imagine nowadays.

Using an actual device also allowed me to test and confirm the experience on some key features: Authentication, video player, transition between pages, etc.

After the initial implementation and proving some concepts, I started to include some Tizen SDK integrations to grab the device's language, the device's model, and other information that could be useful for the app. This allowed us to provide an app that supports the three languages that our digital experience supports: English, Spanish and French.

Focus on moving fast

As you can imagine, putting a big effort in the beginning of the project brought a lot of optimism and expectations to the project, although the detailed updates were exactly to set the expectations at the right level. I decided to move as fast as I could, but never hurting the good practices.

The upcoming weeks were focused on implementing the features as needed, such as Search API (Algolia) integration, to show our catalog of Programs and Workouts, implementing infinite scrolling, pagination and caching strategies. Another important part of our project is the CPDs, where we show a program and all content related to it. This page has animations that differ from the regular web app, which brought some challenges, like making this animation smooth, which meant rendering 3 layers of the page and transition between them, to achieve the expected results. At this point, I was mainly debugging using the actual TV, catching performance or usability issues earlier in the stage when implementing new things.

Scope updates

As we moved fast, the product team decided to include new features in the project, even before releasing it. After meetings talking about it, we decided to postpone the app submission to Samsung review, with the goal to release to Prod, in order to include these features. One of them was the program enrollment, in which users could commit to a program, resetting their progress and updating some API calls and cache in the background, along with other improvements like Fitness Quiz, support for more content types, etc. Instead of delivering on January 16th, now the estimation was postponed by almost 2 months, since I also started to split my time with the other projects.

Reaching the completion of the app

This was a recording from the app's general state a couple of weeks before completing its implementation, about 3-4 months after the initial implementation from zero. This shows the navigation between the main pages, along with running on a low env device and using APIs from the QA environment (this explains the slowness when navigating between pages, a topic for another conversation :D).

And not only humans were excited about the new BODi app:

At this point, my focus was on figuring out what was the correct way to build the app, how to manage certificates, how to prepare the app to be published on the TV store, how to better rank the app, etc. I worked along with the DevOps team, showing the team how to create the GitHub Actions files to properly build the project, using a certificate that was stored in a secure place.

Documentation and knowledge sharing

I spent a couple of days just focusing on the CI/CD process, ensuring we have a project that could also be built and maintained with me :) All the certifications, pipeline and documentation should live in a shared place that other devs could help maintain, and during the entire development process, even though I was the developer behind this project, I always requested code reviews, shared my findings with the team during our tech sync meetings, along with Q&As about the project and how other devs will help maintain it in the future.

We also started to notice a slow response from the Samsung team, mainly regarding alpha or beta testing, and their documentation was not clear, which led us to figure out processes by ourselves. This was not a blocker to continue to have progress in the app:

Completing the app development and testing

In a little more than 4 months, we went from a meeting with an idea to an actual working project, fully tested and ready to be released to our users. This project wouldn't have been possible without the amazing team we had, along with AI. This was a good example for me that AI can speed up the development process a lot, making projects possible in a reasonable time.

Conclusion and learnings

You may ask, "How is the app doing now in Production?" and unfortunately, we faced several problems with the store, mainly related to strikes at Samsung that delayed their review by months. This was not expected and the team lost trust in delivering a project to Prod for which we couldn't ensure a fix or improvement would be delivered in time.

The company decided to hold the publication until today, but this project is still a case of success within the company, even though we decided it would be too risky to release it with such a big interval to receive the approvals from Samsung. I tend to agree with the team and this taught me that even big companies have problems like that, which sometimes is out of control.

I think the biggest mistake we made was to not "test" this workflow with Samsung before having the app in the desired state. That would have caught this slowness on their side way earlier, which would have allowed us to understand if it made sense to keep working on the project or abandon it. Remember, the team was small, and this project would increase the company's market presence on TVs, but not exactly bring new money to the company, since most of the TVs also have Chromecast embedded and we already support that type of streaming.

As you can tell, this project taught me a lot, not just about code and working on a new platform, but also the limitations, which tools to use for analytics and monitoring, how to better communicate with stakeholders to better set expectations, and also put myself in an uncomfortable situation for months, to move myself out of any comfort zone, which I always think is the best way to learn and grow as a person and as a professional developer and problem-solver. Thanks for reading until here :)