Dynamic Mobile Apps

Is your mobile architecture preventing innovation, causing delays due to an overwhelming complexity? Are there parts of your codebase everyone is afraid of? Is your development process too convoluted leaving little space for continuous improvements?

If you answer “Yes” to any of these questions, keep reading.

These series of articles will demonstrate that native mobile-apps development is something trivial, if the correct strategy is chosen.

Mobile native development matters

Modern mobile apps can be developed using multiple technologies.

The best User Experience (UX) can be achieved by using a native approach, making the whole app much more efficient, where it can truly “flourish”, taking advantage of multiple hardware features, without compromising on security.

Unfortunately, this approach is rather expensive since you need dedicated teams for each platform: Android and iOS — and this does not guarantee the resulting mobile-app will be:

1. Efficient — cpu, memory, network usage
2. Effective — provide the best UX for each use-case, support different devices / hardware-profiles and take advantage of its features (tablets / dual-screens, home-widgets, notifications, geo-location, etc)
3. Easy to maintain and support — mobile-apps are continuously evolving

A bad / wrong architecture → failed project

This is true for any project. Bad / wrong architectures result in rigid structures, libraries, and services, where developers implement workarounds everywhere, adding more complexity and technical debt.

The main challenge is about defining an architecture that can fulfill all requirements, without compromising any features, UX design, and delivery times, in a cost-effective way.

Many organizations tend to invest heavily on native mobile-apps, but the challenges related to high-complexity, high-costs, and slow delivery, make them switch to other alternatives that have a higher ROI (return-of-investment), often a web-like approach, in detriment of the entire user experience.

There are multiple vendors that will promote their products and frameworks, how easy to use it is, and outsell the premise that it can actually solve all your problems. Some of them may actually be the right fit for your project. But, beware! Your organization will be locked-in with such technology, spending thousands, if not millions, maintaining and supporting all the infrastructure behind it.

After a few years (even just months!) somebody will realize that additional features are required and another migration project will take place.

If you are investing in a solution, make it agnostic to any proprietary technology — of course, this is easier said than done.

Choose wisely

Why do most native-app projects take so much time ? Is it because the target platforms are too complex? Are developers lacking some skills?

There are several reasons:

• Wrong architecture or design patterns: MVVM (Model-View-ViewModel) is a design pattern that is supposed to separate logic from UI — unfortunately, the design guidelines are somewhat lazily enforced. Another example could be managing remote services as a pure data-layer, forcing “clients” to continuously apply transformations / formatting to such data.
• Bad UX design patterns: people think that UX design is just UI design — nothing further from the truth. UX = UI + behavior, covering for ALL aspects related to a module:
  - how data is retrieved;
  - what to do if there are errors — any error: business rules, network access, invalid request / response, etc;
  - what pieces of content could be potentially retrieved in parallel;
  - visual cues that something is being loaded;
  - accessibility features;
  … and the list goes on.
• Bad technical choices: for example, on an Android project, somebody may decide to use dependency-injection (Dagger, Hilt) — while this could be correct for some scenarios, injection makes very easy to “instantiate/pass” something to other components that developers will use it indiscriminately— spreading everywhere, breaking any attempt to enforce the Separation-of-Concerns principle. At the end, the resulting codebase will be so intertwined (spaghetti-code) that adding new features or modifying existing ones will be impossible without having to perform major code refactoring.

The solution

While most articles in this series will be Android related, the same fundamentals and principles can be applied to an iOS project — actually, any project.

I will provide key aspects, benefits, challenges, takeaways on what I refer as a Dynamic Content Strategy, highlighting the differences between imperative vs. declarative UI.

By choosing the correct architecture,

• Development will be easier and faster
• Reduce the number of bugs
• Easier test, support, and maintain
• Proper planning on future releases
• Developers will enjoy participating on a fun to work project
• Users and customers will enjoy using your mobile-app!

Building complete modules / flows / screens dynamically

Next: Dynamic Content Strategy