Goal

• To understand how we arrived at the current state of the mobile app development.
• To also understand what the modern mobile app development is headed towards?

`Web` in this article refers to single page web apps made for mobile. They may or may not be progressive (PWA).

What is a general Mobile [App| Frontend | Client] composed of?

• The underlying platform/toolkit (android/IOS/flutter/react)
• Main() methods
• App logic (X in MVX)
• UI logic (V in MVX)
• Data layer (M in MVX)

Main() methods:
Here we have the UI components and the entry points of the app:

• A UI component is anything that enables you to draw on the device screen. 
  In Android it would be an Activity, Window,Fragment, View, layout xml etc. 
  In Ios, it would be UIViewController, UIView, StoryBoard etc.
  In Web, it would be the DOM Api, html etc.
  In React/Flutter, it would be your composable components and widgets.
  UI Components are very closely tied to the underlying framework and hence they vary a lot in how you use them.
• An entry point is anything that enables your code to start getting executed by the system. Basically the main() methods of your apps.
  In Android it could be Application, Service, Activity, Alarm Manager, Broadcast receiver, AndroidManifest.xml
  In Ios, it could be UIApplication, UIViewController
  In web & ReactJs, it could be onload() and similar DOM events. Or any javascript running on the page.
  In Flutter, it could be your main() method or a custom entry point method.

While it depends on how the app is architected but most of the apps use the navigation framework provided by the underlying platform/toolkit.

App logic & UI Logic
App logic & UI Logic is any logic that is triggered by the main() methods.

• In Android & Ios, AppLogic could be a jetpack’s ViewModel class or the X in MVX frameworks and UI-logic could be the entire View layer in MVX frameworks.
• In Web, it could be the logic triggered by onInput(), onChange(), onBlur() etc
  In React/Flutter, App-logic could be X (in MVX), if you are indeed using an architecture. UI-logic could be referred to as the content defined via render() in react components, build() in flutter widgets or the composable functions in jetpack compose.

I personally see a thin difference between App-logic and UI-logic. 
A single App-logic module generally abstracts out a logical part in the Data layer. 
UI-logic builds on top of App-logic and decides what needs to be shown on the screen.

Data layer

For a poorly architected app, this layer generally lies together with the App Logic.

• In Android/Ios, it basically represents the repositories/service classes that expose various kinds of datasources and also manipulate the data with some embedded business logic.
• In Web, this is generally absent, but when doing React/Flutter, it generally represents Reducer functions, Stores, Repositories etc.

App-logic and data-layer atleast in theory can be platform/franework independent. UI-logic is something that needs to be platform dependent to call the platform specific UI components.

Evolution

I will try to cover my journey around building mobile apps across the platforms.

1. Vanilla way of doing UI

Lets take an example of fetching some data from the network and showing it on the UI

Android

XML:

Activity:

Things look pretty simple in our vanilla style but a bit verbose when we look at the Activity. 
Our UI + App Logic is kind of shared between the Xml and Activity. The data-layer however seems to be pretty separate & connected with the Activity using a callback.

• Now if we imagine this kind of vanilla structure across a very large scale android app, things might become very messy on the UI side.
• Even the services in the data-layer might become problematic because of various callback classes.
• And if we ever think of adding a manual caching layer for the data we are fetching and reporting the cached/cache-updated status to the UI; things will go crazy and a design overhaul might be required.

IOS

Follows almost the exact same path as android. The threading constructs will differ in the service.

Web

HTML + JS

Imagining web based mobile app without a framework seems like a total nightmare. While this may work for very simple apps but as the app scales, the code might become very inconsistent across various screens/pages.

2. state driven [UI = fn(state)]

For most of the experienced developers reading this article, the spot-on development over the vanilla way would be to add a state.

We can have more state vars in the ActivityState class to represent the state of the network result in the case where it is cached in the sqlite db and then returned to the UI. Which means that onNetworkFetchResult() can be called N number of times with some valid permutation of the state vars.

This is something almost all of us have done in the past. One interesting fact about setState() method is that on every state change, we update all the UI elements regardless of the previous state of the UI.

The UI logic is still shared among the activity and the xml (js and html in case of web) where xml defines the UI and activity manipulates the UI in setState().

• Lets say the progressBar is already hidden and we call setState with isLoading=false. progressBar.setVisibility(Hidden) is still called which might be a wasted cycle if lets say we have a lot of state vars and UI components.
• Which means, for the UI to be most optimal we need some kind of UI diffing before the updates are dispatched over to the UI. This is exactly what lies at the heart of all the modern UI technologies: Jetpack compose, Flutter, React etc.

This now brings us to the ultimate Declarative UI paradigm. 
Before we get there, a quick note on the App logic:

For the vanilla , state driven or declarative way, App Logic can either reside along with the UI logic or separately when there is a proper architecture in place like MVX.

3. Declarative

The most important question that Declarative paradigm addresses is: 
Why does the UI logic has to be separate from the UI definition?
The answer is ‘No’, there is not much benefit in having them separate. Having them together and depending upon a common state unlocks a host of new possibilities.

Android [Jetpack Compose]

Declarative UI naturally leads to composable UI components where one component can wrap another one(s) and provide some defaults for the state. Example: