39 Challenges on Building Mobile Apps at Scale — Part 4: Languages and Cross-Platform Approaches

This article includes 25–28 challenges from the book.

Mücahit Eren Özkur
DigiGeek
4 min readFeb 26, 2024

--

(This series is a summary of what I understood and considered as important from the book “Building Mobile Apps at Scale: 39 Engineering Challenges”.)

Previous article → 39 Challenges on Building Mobile Apps at Scale — Part 3: Challenges Due to Large Engineering Teams

25. Adopting New Languages and Frameworks

Resource

At what point should we adopt a new language? Is it advisable to begin utilizing a promising, emerging framework? Regrettably, finding clear-cut answers to these questions is challenging, and even after thorough research, the decisions made may lead to regret.

The greater the complexity of your application, the higher the risk associated with adopting a new language or transitioning to a different “core” framework.

The aspects you wish to assess align with the criteria used for evaluating cross-platform frameworks. In addition to those considerations, it’s important to take into account the following areas:

  • The maturity of the language/framework.
  • Code migration.
  • Engineering enthusiasm.
  • Risks.

26. Kotlin Multiplatform and KMM

Resource

Kotlin Multiplatform stands out among various methods for creating cross-platform features or applications, as it enables the sharing of code using the Kotlin language. Its distinctiveness in the realm of cross-platform feature and app development is emphasized due to its widespread adoption by significant apps and developer teams.

What you can achieve by writing Kotlin and build are:

  • JVM libraries for Android, or backend services.
  • Native framework for iOS and desktop.
  • JavaScript artifacts for frontend web or backend services.

What can it provide for platforms are:

  • Rich IDE integration.
  • Better debugging capabilities for mobile apps.
  • Good support for Cocoapods.

You can reach for more and detailed information from the book here or Kotlin documentation webpage.

27. Cross-Platform Feature Development

Resource

Creating the shared components of a mobile application once and utilizing them on both iOS and Android is a clear optimization strategy that brings numerous advantages.

  • Minimize the time required to implement features by executing the business logic just once. However, it’s essential to note that the time savings in this aspect are often overestimated. Even during the initial development, thorough testing on both platforms is still necessary.
  • Avoid inconsistencies between iOS and Android. When handled separately, iOS and Android teams frequently adopt different or inconsistent approaches to implementing business logic. Utilizing shared business logic prevents such differences.
  • Decrease the time spent on maintaining shared logic. Maintaining a single codebase is more efficient than managing two separate ones.
  • No more silos between iOS and Android development. Engaging in cross-feature development, even on a small scale, breaks down these silos. Communication between iOS and Android engineers increased.

28. Cross-Platform App Development versus Native

Resource

A great way to enable native mobile UIs while sharing business logic code is to write business logic and libraries in a common language. You’ll need to share the UI layer of the app if you’re using cross-platform app development frameworks such as Flutter, React Native or Cordova. However, cross-platform business logic solutions may be more appropriate for more sophisticated applications or those that require more control at the native UI level.

So what is the real motivation to use cross platform languages instead of native ones? Let’s have a look:

  • The longing for increased speed in feature development is driven by the frustration of the time-consuming process of building features on both platforms. It would be highly beneficial to adopt an approach that promises faster development while catering to both platforms.
  • The aspiration to have a single engineer handle shipping for both platforms is motivated by the inconvenience of requiring two engineers for even the simplest UI changes. Coordinating separate changes on both platforms, testing each, and ensuring synchronized rollouts could be streamlined if a single person could manage both tasks.
  • The wish for consistency between iOS and Android apps stems from the common occurrence of subtle differences between them. Bugs may occur on one platform but not the other, and having both apps operate in an identical manner would be highly desirable.
  • The goal of unifying the appearance and experience of iOS and Android apps is a logical evolution, as the design team often advocates for a shared UI/UX approach over time. This not only aligns with the brand identity but also reduces the design workload by consolidating efforts on a unified platform.

In the next part, I will mention about Stepping Up Your Game.

See you soon.

--

--