Cross-platform frameworks are supposed to make launching your OTT app quicker and easier. So why do experts say they’re often more trouble than they’re worth?

Since Google and Apple own the mobile device kingdom, you must launch on both Android and iOS to reach the majority of users. But developing an OTT app for each platform means your team needs experience with different programming languages and codebases.

If you’re considering creating two separate iOS and Android deployment teams, you’ll be developing the same app twice (once for each platform) and then maintaining those unique codebases.

But a cross-platform framework promises to knock out both simultaneously with a “code once, deploy everywhere” approach. Your programmers can use a single codebase to develop your app and launch on multiple platforms in less time.

*Record scratch* Or will they?

Despite cross-platform frameworks sounding like an efficient idea, many companies have tried and abandoned them only to return to native app programming.

So in this guide, you’ll find a rundown of:

• the pros and cons of the most popular OTT cross-platform frameworks
• studies comparing frameworks to native apps
• the most important criteria used to evaluate frameworks

OTT content distributors that want to deliver their goodies on all platforms with the least amount of cost investment and dev time must first understand:

the difference between native app development and a cross-platform framework

A native application is a program developed with an official software development kit (SDK) for a particular platform, device, or operating system. For example, if you want to build a native iOS app, you’ll need to use Apple’s official integrated development environment (IDE) known as XCode and Swift or Objective-C programming language.

In a cross-platform approach, your team develops an app using a language other than the native one. Then it either takes an interpreted, cross-compiler, or hybrid approach to running that code:

interpreted approach

In the interpreted approach, an interpreter translates the source code to the native application programming interfaces (APIs) and platform-specific elements during runtime. This executes the source code across different platforms. The app’s back-end (logic) remains platform-independent, and your code runs through an abstract layer.

cross-compiled approach

A cross-compiled approach uses a cross-compiler to convert your team’s code to the native binaries to generate a usable, functioning app.

Frameworks typically employ one of two compilation processes:

• just in time (JIT) compilation: Compiling source code into native code at the app’s runtime.
• ahead of time (AOT) compilation: All the code is gathered at compile time before a user ever starts the application.

Because the code gets compiled into the native binaries, the app has access to native hardware and APIs. This makes the app feel true to a native app, even though it’s just a framework.

However, this also means framework-developed app sizes are much larger than native apps. And basic knowledge of native programming languages is often still required. Performance issues may also plague the app due to problems with code reusability, updates for platform-specific features, and more.

The React Native framework employs an interpreted approach, while Xamarin and Flutter frameworks take a cross-compiled approach. Let’s talk about the advantages and shortcomings found in all three.

top cross-platform frameworks for ott

The three most popular cross-platform frameworks include:

react native backed by Facebook

In 2013, Facebook built ReactJS, an open-source JavaScript library that helps build user interfaces by breaking down the individual components of their app. The success of this strategy led to Facebook introducing React Native for mobile development in 2015.

React Native promised a “learn once, write anywhere” approach, meaning that any developer who could build a web app with ReactJS would also be able to tackle a cross-platform mobile app deploy sans additional training.

pros

The advantages of React Native include:

free and open-source React Native is open-source, so any developer can make a library and publish it for other developers to use. You also don’t have to pay any licensing or usage fees.

high code-sharing percentage Coders familiar with JavaScript and React will find React Native easy to use. Developers claim up to 90% of the source code in React Native can be shared or reused between iOS and Android [*][*]. Your team can create reusable UI components once, such as a button, drop-down list, or other elements, so they don’t have to define these each time one’s needed.

large developer community and third-party ready-to-use libraries and components Github stats show users, contributes, and commits are twice as large in React Native as they are in Xamarin [*]. React Native has also been the second most contributed repository in Github since 2017 [*].

less noticeable differences from native app builds React Native uses the same fundamental UI elements as native apps. Developers use JSX3, an XML/HTML-like syntax, to build the UI. Then, JSX gets converted into JavaScript at runtime. Thanks to the interpreted approach, the JavaScript is translated/interpreted to the native code, ensuring a closer look/feel/UI to a native app.

Hot Reload: faster, shorter, scalable development cycles Hot Reload was introduced by Facebook and is now employed by other frameworks. With this feature, there’s a virtual tree of widgets with individual nodes. Every time there’s a change in the app, Hot Reload compares the nodes on this virtual tree with the originals and only updates those affected nodes.

This reduces communication over the bridge, and the platform renders updated widgets to the display without recompiling the entire code. Developers can see their updated source code in the app in about one second [*].

cons

Disadvantages of the React Native framework include:

slowdowns and bottlenecks on the React Native Bridge

Code translations happen at JIT with the help of the React Native Bridge. This back-and-forth bridge allows for communication between the code and the native APIs and platform widgets. Access occurs 60 times per second.

However, this bridge can turn into a bottleneck, slowing down the app and creating performance issues, when translating from the native realm (where all the views and UI is rendered) to the JavaScript realm (and vice versa).

That’s why performance is often called the “Achilles heel” in React Native. Bottlenecks cause lackluster performance of elements such as:

• Animations
• Navigation between screens
• Swipe-able containers
• User-interaction behavior
• CPU-intensive tasks
• Start-up time

developers must focus more effort on optimization to overcome performance issues To bypass the bottlenecks, developers must keep passes over the bridge to a minimum, which isn’t easy to do. They’ll need to focus on optimizing code all the time to ensure decent app performance.

you may still need a native developer on your team

To develop a React Native library, coders must create one for both Android and iOS in native before bridging them for use in React Native. However, there’s a high probability that a developer is more experienced in one platform than the other, resulting in inconsistencies and bugs when using it for the other platform.

Platform-specific coding may also be required to work around certain APIs that are not supported/cannot be accessed. Plus, you often need to maintain three codebases (React Native, iOS, and Android) to ensure the highest functionality.

Android integration is also much more challenging than iOS when using React Native. This could make synchronized development times less likely.

platform updates and version-mismatching could break your app and quickly outdate it If the updates Facebook makes to React Native are inconsistent with the libraries your team used, your app may break. Then you’ll need to wait for these open-source libraries to catch up to the latest platform update.

Additionally, since there are few official components for React Native, dev teams employ several third-party components written and maintained by unknown developers. If these third-party components don’t frequently update, unexpected issues may arise and cause your app to break and become outdated. Fixing these issues could drain your resources.

Airbnb’s real-world experience with React Native

Even though Airbnb isn’t a player in the OTT realm, this enterprise-level company thought a cross-platform framework would be faster, easier, and better than developing a native app. However, they soon learned that React Native wasn’t the solution.

After a few years, the hospitality giant abandoned React Native and switched back to a native approach because [*]:

• refactoring became a “nightmare.” Airbnb forked their own branch of React Native and had to develop the infrastructure themselves to avoid the frequent updates deployed by Facebook that would break their app [*].
• platform inconsistencies. Despite the promise of React Native delivering the same experience on both platforms, Airbnb saw significant discrepancies due to the JavaScriptCore. They said this often supported one environment better than the other, which caused two different behaviors.
• codebase maintenance. Instead of maintaining two different code bases (original source and React Native), they ended up having to maintain three (React Native, iOS, and Android).

Xamarin owned by Microsoft

Microsoft released Xamarin in 2013, making it the oldest framework discussed today. Using a cross-compiled approach, it supports iOS, Android, and Windows devices.

pros

The advantages of Xamarin include:

large community of over 1.4 million developers Since Xamarin has been around for so long, many developers continue to share their knowledge and support each other in forums and online codeshares. You can almost always find a solution to a problem because someone else has probably experienced the same issue before. Xamarin also boasts better documentation than other frameworks.

100% shared UI code using Xamarin.Forms To shrink development time, Xamarin introduced a toolkit called Xamarin.Forms for UI. This allows dev teams to develop UI with a shared codebase. They also have access to all native APIs while using Xamarin.Forms.

close-to-native performance thanks to AOT Unlike JIT, Xamarin helps build fully native apps using C# and a cross-compiled approach. Since the source code is compiled to each platform’s native binaries AOT, performance and UI/UX are very close to a native app build [*].

cons

The disadvantages of Xamarin include:

subscription fees Unlike the other open-source options on this list, you’ll need to shell out a few coins to use the Xamarin framework as an [*]:

• Indie developer: $25/year
• Business: $99/year
• Enterprise: $1,899/year

developers can’t choose their IDE Xamarin forces developers to work with Xamarin Studio or Visual Studio IDE. This means developers may not be working in their preferred IDE. However, official IDEs may offer better integration and support with libraries and tools. Downside: there’s limited access to open-source libraries, so this may not be worth lowering the developer experience.

low code-share percentage Dev teams need a basic understanding of Swift and Java to code for Xamarin. Platform-specific UI coding is required if they’re not using Xamarin.Forms. However, this UI code is not reusable and lowers the amount of code-sharing you may hope for.

Xamarin.Forms is time-consuming for UI development Xamarin.Forms was intended to speed up development. But it’s only recommended for apps using little or no platform-specific functionalities. Here, the shared codebase takes more priority than custom UI.

For example, Xamarin.Forms will not convert C# code into native Android and iOS code. It’s only a UI tool that provides a set of controls for the programmer. So using Xamarin.Forms may create even more work for your team.

doesn’t offer the same look/feel as native apps The controls provided for each platform in Xamarin.Forms are not always identical to the native elements [*]. Since each of these controls comes with its own implementation per platform, using them may make the app feel much different than native.

app may be prone to break by platform (iOS and Android) updates An Xamarin-developed app may break with a platform OS update and crash for users who updated to the latest version. Your dev team will have no way to fix these issues and must wait for the Xamarin team to develop a patch for the framework.

Flutter developed by Google

Google developed Flutter in 2016, and released their beta version in January 2018, making it the youngest framework on this list. However, it’s quickly gaining popularity. LinkedIn reports show that Flutter is the fastest-growing skill among software developers [*].

pros

The advantages of Flutter include:

developer-friendly Flutter is free, open-source, and boasts 100% code-sharing. It also includes detailed documentation with many examples. It offers an integrated IDE for dev teams to design, test, and modify ASAP.

faster than React Native Like Xamarin, Flutter employs a cross-compiled approach. The Dart code is compiled AOT into the native code, bypassing the issue of slow bottlenecks on a React Native bridge.

everything is a customizable widget Unlike other cross-platform frameworks, the UI in Flutter is all built with widgets. These widgets are the most important elements when making an app in Flutter as they affect and control the view, interface, and layout.

Flutter widgets supersede native platform widgets and make native UI elements unnecessary. Since Flutter uses its own widgets over native ones, the only requirement for coding on this platform is a simple canvas. Then, Flutter renders all the UI elements within the canvas.

The widgets appear on the display and during accessing events (like touches). The interface between a Flutter app and the native platform widgets is fast because it’s compiled AOT into native binaries instead of getting interpreted JIT.

can achieve a similar look/feel to native Though Flutter doesn’t use native elements, widgets are customizable for each app’s requirements. So dev teams can mimic an OS scrolling model, typography, messaging behavior, icons, etc. Developers can employ either Material Design (a design language developed by Google) or Cupertino Design (iOS design language).

Flutter also uses Skia. This C++ 2D graphics library (also used as a graphics engine in Chrome and Firefox browsers) helps Flutter render widgets smoothly so the UI and animations feel seamless and fast.

improved Hot Reload Google improved the Hot Reload feature in React Native by creating a similar virtual widget tree and named it Stateful Hot Reload [*]. When a change needs to be made in the canvas, only the affected widgets will be updated. Stateful Hot Reload also preserves the current state of the app. So if an error occurs, your team can fix it and continue where they left off as if it never happened.

lower chance of platform updates breaking the app Compatibility is less of an issue for Flutter-designed apps because the widgets are part of the app, not the platform. Visual experience and UX are not device-dependent, so users running older Androids and the latest versions will have identical experiences.

Plus, since widgets are customizable, anyone in the Flutter community can update them for a new platform release. And since Google is Flutter’s biggest consumer, you can expect fast updates from them first.

cons

The disadvantages of Flutter include:

larger app size Because the widgets and renderer are moved from Flutter into the app, the app size is typically much bigger than native apps.

Dart is a little-known programming language Despite the Dart programming language being mostly unknown to veteran developers, stats show it’s considered one of the most in-demand languages of 2019. You may have trouble sourcing experienced coders with this knowledge. It also means there are fewer third-party and ready-to-use components and libraries.

This may be why this relatively young framework hasn’t been used by many big companies yet.

surveys agree that native apps outperform cross-platform frameworks

Research comparing various cross-platform frameworks with native app performance shows native apps are still the reigning champ because:

• Cross-platform apps receive more user complaints than native apps [*].
• Native apps outperform frameworks for calculation-intensive apps [*].
• Cross-platform tools negatively affect app performance [*].
• Native app performance is still better than React Native despite its similar look and feel [*].
• Cross-platform frameworks which use JavaScript are more resource-consuming than apps developed with C and C++ [*][*].
• Xamarin has a negative impact on CPU and memory usage, and on how apps look and feel [*][*].

So how should you decide which framework to use, or if you’ll even use one at all?

the most important criteria to consider for brands and dev teams

To help you decide whether to use a cross-platform framework or native app build, you need a set of criteria to compare apples to apples. Studies and community posts agree that these criteria fall into three main categories:

1. Non-Functional criteria

Non-functional criteria evaluate the constraints put on the practical part of development, including the:

developer experience and environment. What does the framework or build offer developers? Will it be complicated, hard to maintain, and force your team into an IDE they don’t prefer? Choosing their preferred IDE improves dev experience and may speed up build time/deployment.

learning curve. Every time a developer needs to learn something new, they must deal with a learning curve. Depending on the evolving technology, tools, and software, this learning curve may be steep or manageable. Since each framework and native app build require separate languages and IDEs, which will be the easiest for your team to pick up and run with?

market, community, and support. Larger dev communities mean it’s easier for your team to get help and find solutions when they’re stuck.

documentation. When documents are well-written and continually updated, your team will have fewer problems learning, implementing, and troubleshooting builds.

ready-to-use components and libraries. Dev teams don’t have to spend time, effort, and resources to “reinvent the wheel” when they can employ components already in existence.

code sharing. How much code sharing can you expect to achieve from each framework? Is relying on a single codebase even realistic, considering you may have to maintain separate codebases for each platform anyway?

native look and feel. How similar will the app look and feel compared to a true native app build with official SDKs? If the difference is noticeable, will it be worth sacrificing native functionality and UX?

licensing. If budget is a consideration, you may need to opt for a free, open-source framework instead of one like Xamarin requiring a yearly subscription.

2. Functional criteria

Functional aspects cover the practical part of cross-platform frameworks, such as:

compilation time and development speed. How fast can your team develop the app? How can you reduce the dev cycle and still accomplish all tasks?

code deployment and app performance. As mentioned earlier, cross-platform frameworks perform much worse than native apps.

testing. Will your team be able to test tools, elements, and other codes easily and quickly?

3. Video specific features

Arguably the most important for OTT app developers, video-specific features could make or break your decision to use a framework instead of going native. The most essential video app features include:

video player support. Overall, frameworks are still too immature to guarantee solid video player support.

in-app purchases. Do the frameworks support IAP (for SVOD and TVOD customers)?

VOD advertisement. Can the framework implement CSAI and SSAI (for AVOD customers)?

analytic tools. To understand your OTT app’s engagement and growth, you must continuously monitor 9 KPIs related to its performance and user interactions. Tools like Google Analytics will help you measure how many times videos have been viewed, how many users run the app, how many hours users spend in the app, etc. Does the framework support these necessary analytical tools?

user management. Can the framework handle the ability for user authentication, users to favorite content, access their watch history, etc. These are essential for an OTT application. But these functionalities may not be available in certain frameworks.

final thoughts on ott cross-platform frameworks

Even though React Native may be the best choice among the mentioned frameworks for developing OTT video-oriented mobile apps, cross-platform frameworks are still too immature to deliver the same video-specific functionalities and support as native app development.

Still have questions? The team at Zemoga are standing by to discuss all your options for getting your OTT app to market like a pro. [Get in touch now!](/contact?utmsource=blog&utmmedium=blog&utmcampaign=ottcrossplatformframeworks&utmcontent=contactform)_