Chapters
Chapters

Chapters

Hide chapters

Kotlin Multiplatform by Tutorials

Third Edition · Android 15, iOS 18, Desktop · Kotlin 2.1.20 · Android Studio Meerkat

Before You Begin

Section 0: 5 chapters
Show chapters Hide chapters

Section I: Beginning Kotlin Multiplatform

Section 1: 5 chapters
Show chapters Hide chapters

Section II: Kotlin Multiplatform: Intermediate

Section 2: 5 chapters
Show chapters Hide chapters

Section III: Kotlin Multiplatform: Advanced

Section 3: 5 chapters
Show chapters Hide chapters

Section IV: Appendices

Section 4: 3 chapters
Show chapters Hide chapters

7. App Architecture
Written by Saeed Taheri

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In the previous chapter, you started creating the Organize app. However, you didn’t make it to the organization part. In this chapter, you’ll lay the groundwork for implementing a maintainable and scalable app.

Anyone who has ever played with LEGO bricks has tried to make the highest tower possible by putting all the bricks on top of each other. While this may work in specific scenarios, your tower will fall down at even the slightest breeze.

That’s why architects and civil engineers never create a building or tower like that. They plan extensively, so their creations stay stable for decades. The same applies to the software world.

If you remember your first days of learning to program, there’s a high chance that you wrote every piece of your program’s code inside a single file. That was cool until you needed to add a few more features or address an issue.

Although the term software architecture is relatively new in the industry, software engineers have applied the fundamental principles since the mid-1980s.

Design Patterns

The broad heading of software architecture consists of numerous subtopics. One of these is architectural styles — otherwise known as software design patterns. This topic is so substantial that many people use software design patterns to refer to software architecture itself.

Depending on how long you’ve been programming, you may have heard of or utilized a handful of those patterns, such as Clean Architecture, Model-View-ViewModel (MVVM), Model-View-Controller (MVC) and Model-View-Presenter (MVP).

When incorporating KMP, you’re free to use any design pattern you see fit for your application.

If you come from an iOS background, and you’re mostly comfortable with MVC, KMP will embrace you. If you’re mainly an Android developer, and you follow Google’s recommendation on using MVVM, you’ll feel right at home as well.

There is no best or worst way to do it.

Next, you’ll find an introduction to some design patterns many developers take advantage of.

Model-View-Controller

The MVC pattern’s history goes back to the 1970s. Developers have commonly used MVC for making graphical user interfaces on desktop and web applications.

avkufu ulim opsaiq emqoji vurimy gevjwuwhil duqas vuir
Cux. 0.2 — NLW yiasfux

Model-View-ViewModel

As the name implies, MVVM is a great fit for applications with views or user interfaces. Since the concept of bindings is prominent in this pattern, some people also call it Model-View-Binder.

Clean Architecture

In 2012, Robert C. Martin, also known as Uncle Bob, published a post in his blog at https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html explaining the details of a new design pattern he came up with based on Hexagonal Architecture, Onion Architecture and many more.

Jekerug Fecejikq Olzimsab atbabcumog Xcebednotd Cosrvoqbabx Inu Moput Dan TC AO Axtasiax
Sir. 8.5 — Fdeoy Uzyroxinpugo Gjufj

Sharing Business Logic

KMP shines when you try to minimize the duplicated code you write. In the previous chapter, you wrote the logic for the About Device page twice. That code could easily be inside the shared module and all the platforms would be able to take advantage of it.

Creating ViewModels

Open the starter project in Android Studio. It’s mostly the final project of the previous chapter.

Gip. 7.8 — Octoud+Viwofs uq urduxd rsakl tuda
Pex. 3.0 — Igkeuq+Betuzl id avcebn ktupp jutu

Creating AboutViewModel

Now that you have a base viewmodel, it’s time to create the concrete versions. Start by creating a file named AboutViewModel.kt in the commonMain folder inside the presentation directory.

Using AboutViewModel in the View Layer

Android

Open AboutView.kt inside the androidApp module.

Pek. 8.8 — Npe Eroib Gaxaha wajo is Awrojoxe uy Owzyeit zoigl ukamv PiebPulod.
Qup. 2.3 — Zqe Opuiq Wehixi jodo ig Acyuziva aw Uncxaem gaerl ohelj VaibLonax.

iOS

Open the Xcode project and switch to AboutView.swift.

Lur. 8.8 — Nbu Ujeux Zefeme gipo eh Ayfiwaza ov aIN puuyg ivazs MiuzRakuk.
Siq. 3.2 — Qze Iqoup Moziju qufo ez Uvviduqi ut eOQ soern adokv KaicJuxal.

Desktop

You’re now familiar with the process. Since you created the desktop app using Jetpack Compose, even the function names you need to change are the same or very similar to the Android version. Remove the unneeded function for generating the data and replace the ContentView method in AboutView.kt in the desktopApp module. Finally, don’t forget to import the needed package.

Jud. 2.8 — Rlu Ehues Zobige woba oh Alzekijo iq recnbes keafw upilc WeepCujux.
Nel. 6.2 — Shu Udeez Nemope yiju ez Ejnazodi uy buxvcur qeusy ipebz YaeyHakaq.

Creating Reminders Section

Until now, you were working on a supplementary page of the app. There was a reason for this: You wanted to avoid redoing everything for all platforms. However, now you know what the app’s structure is and where you could put the shared business logic.

Repository Pattern

A first idea for implementing the RemindersViewModel might involve directly creating, updating and deleting reminders and exposing the data and the actions to RemindersView. This design works, but by using it, the app becomes more and more difficult to maintain as it grows. It gives too much responsibility to the RemindersViewModel class, which violates the separation of concerns principle.

Creating RemindersViewModel

Inside the presentation directory of commonMain module, create a new class named RemindersViewModel. Update it with the following:

Updating View on Android

Open RemindersView.kt inside the androidApp module. In the beginning, add a parameter with a default value for the RemindersViewModel to the RemindersView function. Then, pass viewModel into the ContentView method.

Dij. 1.8 — Nru Fugiryugw betcy soha ih Etnboiz
Zuz. 9.2 — Xnu Wesacpogr wubyx weju ay Ujqhaor

Updating the View on iOS

For the reactive nature of data binding to function effectively, SwiftUI heavily relies on the Combine framework or, as of iOS 17, the Observation framework. If you are targeting iOS 16 and earlier, you may have used @State to annotate value data types, and @StateObject or @ObservedObject for external reference model data. With the advent of iOS 17, Apple has simplified state management. With the assistance of the Observation framework, you can now utilize @State for all data types, whether they are value types or reference types.

Gux. 0.7 — Kno Boqacsaxz tascr nipa oq iOK
Sel. 2.6 — Qsa Xayoqnanp joyzm teqa um eEH

Updating View on Desktop

Since the desktop app is using Jetpack Compose, you can literally copy and paste the updated code from RemindersView.kt in the androidApp module to the same file in the desktopApp module.

Xid. 6.0 — Cle Mehokxidl xuvnz cowu iz hucpkeg
Tud. 6.2 — Rhi Xuxagtahp lofcm pere ew citlciw

Sharing Tests and UI

By sharing business logic, you reduce the code you need to write for each platform to their respective UI code.

Challenge

Here’s a challenge for you to see if you mastered this chapter. The solution is waiting for you inside the materials for this chapter.

Challenge: Moving Page Titles to Viewmodels

As viewmodels are responsible for making everything ready for views to show, you can make the viewmodels provide the page title to their respective views. This way, you can transfer one other point of code duplication to the shared platform and prevent wrong titles for pages or typos.

Key Points

  • You can use any design pattern you see fit with Kotlin Multiplatform.
  • You got acquainted with the principal concepts of MVC, MVVM and Clean Architecture.
  • Sharing data models, viewmodels and repositories between platforms using Kotlin Multiplatform is straightforward.
  • You can share business logic tests using Kotlin Multiplatform.
  • Although possible, it isn’t always the best decision to share UI between platforms.
6. Connecting to Platform-Specific API
8. Testing
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now