Mobile app cross-platform, how it works

Preamble

Have you ever wondered why

Flutter and React Native (RN) can build apps for both Android and iOS.
Supporting "hot reload" to quickly show affected code changes.
Performance is still not as good as native.
You’ve heard somewhere that says Flutter has performance close to native because Dart code is compiled to native code, while React Native has less performance because it has to go through the bridge (which sometimes has bottleneck).

To come clean, we're going through their architecture & compilation process.

Before starting, you can simply understand that the compilation (or interpretation) process will convert your programming language (e.g. Kotlin, Swift, Dart, JavaScript...), finally into executable machine code (which the CPU can execute).

And for me, calling a language interpreted or compiled is not a well-defined concept. Technically it all matters depending on the implementation, not part of the language specification. Let read to the end of this article and you know why I said that.

We should go through native app (Android, iOS) compilation process to overview behind the scenes, then you’ll get about cross-platform (Flutter, React Native) easier.

Android

Android can be written by Java or Kotlin, so the Android compilation process, in short, is based on Java/Kotlin compilation process.

File .java or .kt is compiled by JAVAC (Java compiler)/Kotlin compiler -> Java byte code (file .class).
With a normal Java app (e.g. run on Windows, Linux), there will be a JVM (Java virtual machine) converting these files to machine code and running by CPU.
But with Android, this .class file will be minimized by proguard, then is compiled by Dex compiler -> Dex byte code (file .dex) -> .apk.
When you launch (start up procedure) an Android app, file .dex will be converted to machine code by DVK/ART, and fed into memory, then executed by CPU.

DVK (Dalvik Virtual Machine) or ART (Android Runtime) is a virtual machine available on OS, to help you run Java bytecode on Android devices.

The difference between DVK vs ART is that ART (introduced from Android 4.4) was built as a replacement for DVM because it uses AOT (Ahead Of Time) compilation, while DVM uses JIT (Just-In-Time). JIT compilation does the compilation during the execution of a program (every time you launch an app). While AOT compilation does the compilation when the app is installed -> this is key point ART makes an Android app startup faster than DVK.

You notice that, when installing the apk on the device, the app is still in bytecode, meaning the system has to take at least one step (with ART) to convert bytecode -> machine code.

iOS

iOS compilation process, in short, based on Swift compilation process (actually there was some previous step with Xcode, but we won’t focus on this article).

The swift compiler has two dimensions: Frontend and Backend (and don’t think this is web client and server).

Frontend: does lexical analysis, parsing and semantic analysis from frontend and passes rest of the phases to the backend.
Backend: SwiftC (swift compiler) converts code to the form of AST (Abstract Syntax Tree) -> then goes through semantic analysis and is converted into Swift Intermediate Language (SIL).
This code goes through analysis and is optimized along with LLVM IR (Intermediate Representation).
Finally, LLVM converts them into assembly code and finally ends up in an executable file -> .ipa

LLVM (Low Level Virtual Machine) is a library for programmatically creating machine-native code.

iOS app is fully machine code when installed to the device, this is an advantage of iOS optimization compared to other platforms.

From native's perspective, all React Native/Flutter screens just only take an Activity/View Controller. It means when you navigate between React Native/Flutter screens, you're moving inside React Native/Flutter's navigator, not startActivity or pushViewController in native code (conceivably it is similar in-app webview in this case).

Flutter

Now it also supports web and desktop app, but in this article, we just focus on mobile apps (Android & iOS).

We know that developers can write Flutter apps by Dart, but Flutter compilation process will be a little bit different because not only Dart is compiled, but also C/C++ and more, why?

Architecture Overview

You’ll see that Flutter has 3 layers that were written in different languages, and they will explain how a Flutter app works.

Embedder is written in a language that is appropriate for the platform: currently Java and C++ for Android, Objective-C/Objective-C++ for iOS and macOS, and C++ for Windows and Linux. Embedder provides an entrypoint, coordinates with the underlying operating system for access to services like rendering surfaces, accessibility, and input; and manages the message event loop.
Engine, which is mostly written in C++ and supports the primitives necessary to support all Flutter applications. The engine is responsible for rasterizing composited scenes whenever a new frame needs to be painted. It provides the low-level implementation of Flutter’s core API, including graphics (through Skia), text layout, file and network I/O, accessibility support, plugin architecture, and a Dart runtime and compile toolchain.
Framework, where most developers work, to build a Flutter app.

Different from React Native (which converts your JS component to native component), Flutter uses Skia (a graphic engine, recently Impeller) to render an entire UI widget by itself. So it means you can layout the same UI for both Android & iOS (including UX).

When comparing between Flutter/Skia and RN/native component, although I haven't done specific measurement statistics yet, but if you come to my articles flutter-fb-reactions-animation & react-native-fb-reactions-animation, you can feel that Flutter brings to a smoother animation than RN.

This happen because React Native have to calculate animation value at JS thread then send to Native (UI) thread on every frame, if JS thread is blocked => drop frames => cause jank. Using useNativeDriver could help, it move all steps to native, but not support all cases.

How does hot reload work? Because Dart support both JIT (debug mode) and AOT (release mode), so:

When debugging, Flutter uses Dart VM with JIT mode, in short, it means that the developer can change the code at runtime, and only the new code that has been changed/inserted will be changed at the app, without the need to compile it again.
When apps are ready to be deployed to production, the Dart ahead-of-time (AOT) compiler can compile to native ARM or x64 machine code. Your AOT-compiled app launches with consistent, short startup time.

This couldn’t happen in AOT languages (like Java/Kotlin on Android & Objective-C/Swift on iOS), since there’s no runtime environment to handle it.

Flutter compilation process basically means compile 3 layers we mentioned above, and will be different in Android and iOS.

Compilation process

Flutter Android

The engine’s C and C++ code are compiled with Android’s NDK.
The Dart code is ahead-of-time (AOT) compiled by Dart Compiler into native, ARM, and x86 libraries (most current android devices run on ARM, the latest x86 device is Asus zenfone 2 with intel Atom released 2015).
Those libraries are included in a “runner” Android project, and the whole thing is built into an .apk.
When launched, the app loads the Flutter library. Any rendering, input, or event handling, and so on, is delegated to the compiled Flutter and app code.

Flutter iOS

The engine’s C and C++ code are compiled with LLVM.
The Dart code is ahead-of-time (AOT) compiled by Dart Compiler into a native, ARM library.
That library is included in a “runner” iOS project, and the whole thing is built into an .ipa.
When launched, the app loads the Flutter library. Any rendering, input or event handling, and so on, are delegated to the compiled Flutter and app code.

Performance

App built by Flutter not only includes your logic code (Dart) but also includes Embedder & Engine, so the app size will increase by around 5 MB compared to native (Android/iOS). Check the section App size comparison.
Even though it's built into native code, Flutter still need engine (role as a bridge) when (and only, not all cases like RN bridge) handling task which connect with native API (camera, audio, sensor...) through platform channels, and it's asynchronously.
Using Skia to render UI, still cause jank animation at "first run" on iOS.