Skip to content
What it takes to build real-time voice and video infrastructure

In this series, WebRTC expert Tsahi Levent-Levi of BlogGeek.me provides an overview of the essential parts of a real-time voice and video infrastructure—from network to software updates. Check out his informative videos and read how Agora’s platform solves the challenges so you can focus on your innovation.

3.2 Native

Watch time:
Category: Chapter 3: Clients

Understand why native applications are often the best choice for RTE on mobile. Explore the differences between native vs web.

Dive deeper: Agora provides native, mobile and web SDKs for all the major platforms. Explore our tutorials and quick start guides in our Developer Resources.

Transcript

This time, I want to talk about Native clients. What we’re going to do in this lesson is understand real-time engagement support on mobile applications are and we also going to review the PC native applications for real time engagement, so mobile and desktop. 

Read the full transcript

Let’s start with mobile. If you think about it with two native mobile operating systems, we either use iOS or Android, this is what our users are going to end up using anyways. Now with mobile devices, we need to understand the chipset architecture that is being used. What we have today is an SOC approach in mobile system on chip. With a system on chip, what we need to deal with is the fact that these mobile devices are mobile and small, and they need to be lightweight. Which means that at the end of the day, what we have is low power consumption on these devices. And we want lower power consumption so that the battery life will be longer and the devices won’t heat up too fast. To get there, we need to limit the processing power that we have. So, the chipsets for mobile have low power consumption with limited CPU power. This leads to the solution that exists today on mobile devices, which is to use hardware acceleration, for the things that require a lot of CPU and processing power.  

One of these things in real time engagement platform is voice and video codecs, especially video codecs. And what we want to do is to optimize performance and resources in our RTE applications, by trying to offload some of the processing towards this hardware acceleration. That will mean using a bit less CPU on the devices and increasing battery life. When it comes to implementation alternatives on mobile, there’s—first of all, the cross-platform development, where we usually use web views. Web view is a kind of a browser window that renders HTML and JavaScript code. In turn, it can render today web RTC code as well. So we’re going to build the web application, just as like as we would in a web browser. And then we’ll wrap it up in packages as a full application. The other alternative is to go to a full native application, we’re going to have two separate implementations, one for iOS and one for Android and they’re going to be very different from one another. The third option is to use a mobile application framework, something like flutter or React Native or Coco’s. What we’ll need to do is to have bindings for WebRTC. We need to find the React Native binding that includes support for WebRTC and then use that, for example. I’ve seen applications done is with all of these approaches. And all of them work with different levels of success and with different capabilities. We’ll see later the differences between native and cross platform. Let’s move on to see what happens on the PC.  

So, if we’re targeting laptops, and desktops, then the operating system that we’ve got our Windows, Mac or Linux, most of the time, it would be focused on Windows and Macs and then some of the vendors would also prefer to have a Linux application. From an implementation or an alternative perspective, we can go full native and build the full application running on each one of these devices with the API that the operating system offers us. For that we can take something like libWebRTC, WebRTC open-source library, compile and running on on our own or build our own proprietary media engine. We can decide to use Electron and Chromium.  

Chromium is the baseline open-source version of Chrome. Electron is a kind of packaged layer on top of it. That enables us to take a web application running in the browser, and package it and close it as an installable PC application that can run on Mac, Windows and Linux. You will see many applications today using electron. And we can use these also for our WebRTC application. We will write the code for the web, and then package it as an electron application for PC. The third approach, especially for gaming and 3D graphics, is to use unity, again, with bindings for WebRTC. So, what should we do? Pick full native or web native solutions—web based solution that get trapped as an application. So, if you go native, then the time to market is going to be slower than going web native. We are already already writing web applications anyways. Its out there faster to develop and implement. They use JavaScript. 

And that would be faster and going native will take more time. If you look at cross platform support, web native uses web standards, whereas for native we’re on our own. We’ll need to build each and every operating system or application all on our own. From a resource perspective, native is going to be highly optimized for the device, whereas web native is going to take more memory and CPU. Because we’ve got the overheads of web standards and JavaScript on top of what it is that we’re doing. Application side, size or native, it’s going to be small to medium because we can compile and cherry pick only the pieces that we need. For web native, it’s going to be big because we wrap into all of the components of the web, even those that we don’t need or want. From user experience perspective, native is going to be tailored to the platform, while Web native is going to be uniform across different platforms, and willing to try and figure out how to give a more native type of feeling to a web application if we use web native.  

To summarize, richer experiences are enabled by native implementations. If we want to reach experience for our customers, then using web native approaches might not be the best way to do. Native would give us a better solution. That said, it would be harder to implement and will take more time and resources to do. The closer we are to the hardware, especially on mobile devices, the richer the experience can be, which again, says that native should be the way to go there. The mixed approaches of application frameworks such as you know, Flutter and React Native are quite good approaches as well. Thank you.