Micro-Frontends applied to mobiles? We’ll see!

When I heard about this new style of architecture, it sounded tempting to bring your app to mobile clients.

However, Micro-Frontends is an architecture style that was born for web client applications. For now, it can be applied only for this type of solution since in mobile applications with current technologies, we could have an approximation to the concept, but not 100% compliance.

Below I will explain the reasons why I have come to this conclusion.

First, let’s review what this style of architecture looks for when applied to web clients.

In a simplified way, this style of architecture aims that the solution is designed to combine different types of frontends in an agnostic way. Thus, you can integrate each micro-frontend into the application regardless of the technology with which it is built.

To illustrate a little, let’s see the following image:

It simply proposes a main frontend capable of orchestrating multiple sub-components representing micro-frontends with their independent business logic and technology.

Under this understanding, is it possible to bring this style of architecture to mobile clients?

The quick answer is:

Not yet.

Thinking of having the UI layer composed of multiple independent UIs is convenient. It could be considered for web-type client layers, but let’s remember that not everything that is applied in web clients is viable to be applied in mobile clients.

A misconception that could lead to wrong decisions is to believe that the architecture of web clients is similar to the architecture of mobile clients and that a solution built based on one will replace the other.

But what is the difference with mobile solutions so we cannot apply this type of architecture style yet?

Let’s start with the current topologies and technologies for a mobile solution.

We currently have the following categories of solutions:

• Cross-platforms (Cordova, React, Ionic, Xamarin, Flutter, and others)
• Multiplatform
• PWA
• Natives

Cross-platforms

In this category, you will find the solutions supported by a framework to share and deploy the solution from a common code in iOS and Android.

It is essential to mention that although Flutter belongs to this category, it has a technical feature that distinguishes it from the others. Flutter does not require web views for view rendering, which, in practical terms, removes the dependency on both the iOS and Android web view engines.

Teams familiar with cross-platform technologies can gauge the concerns that arise every time Google or Apple decide to make a change or discontinue a component in such engines.

The point is that using cross-platform technology; the view components could not be agnostic since there is a dependency on the framework used to interpret the views in a single technology, be it JavaScript or Dart. So it is not possible to combine UI components designed with different technologies in one view.

Someone here might ask, what about iFrames or deep-linking?

Well, to begin with, let’s accept that it is practical to use this type of component to enrich the front end, but let’s also accept that it is not the best way to build the capabilities of what a micro-frontend architecture promises. To begin with, managing to orchestrate and communicate multiple components of this type is challenging.

Not to mention the user experience that is not the best and the integration and security challenges that its implementations entail.

Multi-platform

The Kotlin ecosystem offers this technology and is known as KMM (Kotlin Multiplatform Mobile).

This platform allows for centralizing and sharing business logic so that it can be used by multiple types of clients, including iOS and Android mobile clients.

Is not that the same function that cross-platform solutions fulfill?

Nope.

KMM technology seeks to share business logic that can be integrated and reused by different types of clients with the great advantage of maintaining its native nature in the view or UI components. That is, it does not require including the dependency on a framework to share and reuse components on multiple platforms.

That, of course, brings many advantages to the solution. However, similar to the cross-platform case, there is no possibility of including different technologies in a component view.

Although it is currently in an Alpha state, it is worth mentioning that this technology is promising for designing reusable components for multiple clients.

I entirely agree with Gergely Orosz’s reference to this technology in his book Building Mobile Apps at Scale: 39 Engineering Challenges as follows:

“Among all the cross-platform feature development approaches, I see Kotlin Multiplatform and KMM as the most promising.”

The excellent news is announcing the Beta version of KMM for Spring 2022.

PWA

I include PWA (Progressive Web Apps) technology in the list to mention it since, in practical terms, PWA is a web application, not a mobile application.

It is just a web client that provides a better user experience than Response Designs Webs when entered from a mobile device.

Because it is precisely web technology, it could be designed with micro-frontends, but I insist it is a web solution; therefore, the comparison in this article dedicated to mobile phones does not occur.

Native

What about native technologies for building micro-frontends?

Well, native technology is always the complete option in the entire ecosystem for designing high-demand mobile solutions at scale. It offers other alternatives for organizing and sharing UI components, functionalities, and business logic.

These alternatives are given in each of their native scopes; that is, there is no such concept of having a view based on Jetpack Compose with UI components written in SwiftUI or vice versa. That is, there is no such possibility of combining micro-views with different technologies.

But what does exist are approximations.

Let’s see what kind of designs on mobile could come close to a micro-frontends style.

With the introduction of declarative views in iOS and Android (SwiftUI and Jetpack Compose), the UI layout can be composite. We can have views composed of micro-views.
It does not mean that it was impossible to do this type of design before; it is done through fragments or sub-views(i.e., xibs), only that the level of flexibility is more significant now with declarative UI.

Declarative UIs are now also available in cross-platform technology like Flutter, in which case they are called widgets and make up the view.

But aren’t these then examples of micro-frontend design applications?

Nope.

It is a view composition design, and it is not the same concept as micro-frontends because each is designed with the same technology, either with Jetpack Compose for Android, SwiftUI for iOS, or Widget/Dart for Android. iOS on Flutter.

By grouping these declarative views with their respective ViewModels, with their separate Repositories, they could form a functional module and later be extended to a modular feature.
The modular features could, in turn, be static or dynamic. And stop counting!

Dynamic modular features, for now, would be the last level of abstraction that a mobile solution could have, thus allowing functionality to be added dynamically at runtime. But, it is clear that Dynamic Feature Module is an acceptable practice in Android, but not in iOS, since Apple considers it a security risk to add dynamic code to the solution without being reviewed and approved by the publication process.

In conclusion

I consider that since combining views with agnostic components is impossible, it would not yet be possible to talk of a total application of the micro-frontend architecture in mobiles.

However, a modular design supported by declarative views allows a strategy to provide the solution with view components and reusable functionality using a single technology. Under these terms, we could say that a modular architecture composed of micro-views or micro-functionalities in the field of a single technology would be more feasible on mobile phones.