The latest attempt at hybrid development: Electron

Hybrid development against native development. A dilemma that has been happening in the world of iOS development since 2010. And a dilemma that has been in the desktop world for a few years too with a tool: Electron. As praised by some as criticized by others. Electron is the latest attempt by the open source community to leverage all the synergy of web developers to attract them to the world of desktop applications. A flag waving by Microsoft as owner of GitHub and forerunner of this library.

But what is it about hybrid or native development? Why does the former allow you to make an app that works equally with minimal modifications on both iOS and Android? Can’t a native development be cross-platform? Is native development only done with the official SDK of each system, created by Apple or Google, depending on system? Let’s get a little deeper into this controversial topic trying to explain what each thing is.

Hybrid or native development and framework concepts

A library or framework is one that allows us to create an app for some system using its components. In the case of iOS, Apple’s official library for development is called Cocoa Touch and has several components, several libraries: from UIKit that allows us to build interfaces through many other for different functionalities such as sound, network, access to system functions and much more. This library is native. But it is not because it is official created by Apple, it is because of how it is built and how it draws the interfaces.

The fundamental concept that is handled in the common idea is that a native app is the one that is made with the official libraries of each system. If I make the app with Cocoa Touch and use Swift or Objective-C, it’s native to Apple. If I do it with Android SDK and use Kotlin or Java then it is native to Android. But this isn’t exactly the case. We have to understand two fundamental concepts: the first, how we draw the interface of our app and two, does my app allow to be executed on more than one system at a time with minimal modifications?

-We have to distinguish that one thing is a hybrid app and another that is cross-platform. Normally all hybrid technologies are cross-platform, but we also have native technology that is equally cross-platform. In the end, that all systems and hardware work on C makes it easier to execute code on different systems-

Let’s look at the example of a video game with Unity: when I make a game with this tool, what I get is a native development for each supported platform that not only includes iOS or Android, but also all consoles like Xbox One, PS4 or Switch, as well as PC , Mac or Linux. In reality, what Unity does is take advantage of the compatibility of all systems with binary code in C++ to create «a package» of the developed game, which will be read and executed by Unity’s own library that is created for each system that supports it.

-The crude-to-platform execution crude today is that each system creates a library compatible with each system (iOS, Android, PC, consoles…) and launches «a program» that said library can interpret and run independently of the system. This library » translates» or «interprets» the contents of the con-

But execution is native for two reasons: because it runs against the graphical engine of the system directly (either OpenGL ES, Vulkan or Metal, depending on platform or device compatibility) and because calls that may require system components, aretranslated in real time to go against the native components of each system: its official library. If I put a text field in Unity for the interface, it will be translated to the native element of the official library of each system from its call.

In that same premise there is, for example, the Microsoft Xamarin library. It creates native apps, technologically speaking, because what it does is translate the calls of the system. And one of the options Xamarin allows us to use its own components through the Xamarin library. Forms. This type of development performs well and is competent. But it also has something extra: that creates cross-platform (non-hybrid) apps. A single development works on more than one system.

So what is a hybrid app? It is when the app mixes native technologies with an interface that is actually a web page that is not drawn directly on the system. That’s why the word hybrid. It is able to use native components of each system by translation as Unity or Xamarin does, but the interface is being drawn in a browser window, not against a system graphics engine canvas. Therefore interfaces are created using HTML and not with graphical system instructions.

-A hybrid or native app is differentiated by the technologies they use to build the user interface. A hybrid app allows you to make calls to libraries specific to each system, but builds the interface with HTML5, as a web page and on a window that is a «camouflaged» web browser. A native library, it builds the interfaces directly with the graphical libraries of the system-

That a hybrid library is then cross-platform, is a feature of it, but it has nothing to do with each other. There could be a hybrid library for iOS, which only worked on iOS. It would be hybrid but not cross-platform.

The story of the hybrid on iOS

Until 2010, the only way to create iOS apps was using Xcode and Objective-C. No one had ever created another solution, of any kind, that would be able to generate a binary code that could run as an app on an iPhone. But then, at the presentation of the iPad, Steve Jobs began his war with Adobe Flash. Flash was not supported. Running Flash required putting a virtual machine on the computer with iOS system administration rights, which would have had two consequences: the first to hinder system performance (if that library is not well developed) and the second is that any security flaw in the Flash engine would allow you to get admin permissions on an iPhone and bypass all your security. That’s why Apple doesn’t accept virtual machines like Flash or Java.

-In mid-2010, not without controversy, Apple banned for a few months that apps could be uploaded to the App Store that were not developed in Xcode, programmed in Objective-C and using its official Cocoa Touch library-

But at the time Flash had a lot of weight in the industry, so Adobe got to work and created an app called Flash Builder, which allowed you to take a development made in Flash and run it on an iPhone as an app. A translation. Actually a hybrid container that ran the Flash engine in a browser within the app. Upon learning this, Steve Jobs made a blunt decision: App Store rules changed and no app that was not developed in Objective-C and created with Xcode was banned. But most importantly, it required the use of official bookstores as the only option. This happened in April 2010 and this rule did not change until summer. Apple quietly removed this restriction with Epic Games, creators of the Unreal Engine.

The reason was one of weight: the Epic team presented Apple with an incredible technical demo that was then presented at the September 2010 event dedicated to iPods using the trick adobe had used. The game was called Project Sword and was the publication that same day of the technical demo Epic Citadel that a few months later would become the first Infinity Blade (now now gone). A demo that technically ran the Unreal engine against Flash’s Stage3D library, which allows 3D acceleration in games. An engine that ran on iOS against a browser hidden from the user using WebGL 3D graphics technology for browsers. So Apple had no choice but to remove the restriction because it had just been shown that hybrid, cross-platform development and using other libraries (such as Flash itself) within an app, was a future bet they couldn’t turn down. So Apple removed that rule and since then there have been a multitude of tools or libraries that allow you to create apps for iOS, apart from the official Apple.

The hybrid arrives at the desktop: Electron

Why do hybrid apps exist? What’s the point of wanting to create an interface using HTML5 instead of a natively drawn interface on the system? Simple: Almost 72% of the world’s total developers are web. Therefore, the fastest way to leverage that critical mass of developers to make apps for mobile systems was to give them tools to allow them, with what they already know and something else, to create mobile apps. It’s that simple.

But that way, just as a web page looks the same whatever system you see it, a hybrid app will show the same interface whatever system it runs. Even if you do not respect the guidelines and design language of each platform.

-The main problem of a hybrid app, in terms of interface design, is that it does not respect the design guidelines of each platform, which is what makes us know how to use an app intuitively as soon as it is booted-

This whole revolution of taking advantage of the synergy of so many developers also had its translation to the desktop world with GitHub, since it created a need that previously did not exist: to create cross-platform apps for desktop systems that allowed consume services that mainly live in the cloud. Like Slack, Skype, Spotify… or even create text or code editors that also have a single development, such as Visual Studio Code or Atom. And for that Electron was created.

But what is Electron? Well, it’s basically a Chromium engine (the one that uses Google Chrome) that also has a node. js javascript execution layer. It is created by GitHub (now owned by Microsoft) and allows you to encapsulate a web page within a container that allows you to «look» a native desktop app without being a native desktop app. An engine that is now heavily criticized for its high consumption of system resources and inefficient performance, but that allows you to create an app with a single development relatively quickly, that can be run on any Windows, Linux or macOS system. And as a hybrid library, it allows you to connect with some system services that allow you to better integrate into your execution (native components of each system).

But this has a very big problem. Imagine this: we have Visual Studio Code (the most used code editor today) because we are editing code, Slack because we work with a team of people online and Spotify because we are listening to music. Unknowingly, we have 3 Google Chromes open at the same time consuming resources and memory. And if we open Google Chrome, 4. The fact that Electron apps are self-contained does not allow them to share resources.

Because Electron apps are encapsulated for the same development to work on Windows, Mac, or Linux, they can’t share resources. So each app creates its own instance of the Chromium engine attached to Node.js.

If we want to get an idea of the scope of this fact, we only have to look at one case study: a text editor like Sublime Text opening a 4-line C file will need about 40MB of memory to work. With a text editor like VIM, just 5MB. But if we use Visual Studio Code, you’ll need 349MB. It’s crazy.

If we use plugins that increase the functionality of the editor and open a 6MB file in XML format, VIM will use just 12MB while Visual Studio Code 392MB. Apart from CPU consumption. And as much as they try to optimize the code, it won’t do much good because the problem is at the core: in the engine. Create encapsulated a Chromium engine with Node .js and load it with each app independently. All to «save» to make a native development on each platform and take advantage of web developers for all this without having to train them in the technology of each system.

Electron is focused on the companies that use it as a saving attempt on two fronts: the difficulty of finding developers for environments like macOS or Linux (on Windows it’s «easier») and not having to make 3 different apps with 3 different development teams .

These kinds of «problems» do not usually reach the end user and often we blame Spotify itself that its desktop app is so slow and consumes so many resources, or that to show an album and four elements we have to turn on the dedicated graphics of our computer or the CPU gets hot. But in reality, Spotify’s fault is indirect because the real fault of this problem is behind this app.

Better to be native than hybrid

Cross-platform apps can be better or worse depending on the library. There the two big winners are Xamarin and Flutter. One from Microsoft, the other from Google. The problem here is hybrids that to put the interface on a web, consume more resources and do not adapt to the design language of the system or its usability, are slower and also have a hard time adapting correctly to changes like the notch and its safe zone.

In addition, a hybrid app, having the interface based on an HTML5, CSS and javascript interpreter, has a better chance of having security flaws than being exploited they endanger our system. Electron, in fact, has had several historically (already resolved) failures that allowed vulnerabilities that gave full access to our equipment. And a failure of these involves updating the engine by each app independently.

-By using web technology to display interfaces, hybrid apps are exposed to more security flaws than other apps because they have a component more exposed to possible failures-