Kotlin in Xcode? Swift in Android Studio?

A series on using Clean + MVVM for consistent architecture on iOS & Android

Published in

The Startup

4 min readDec 4, 2020

Mobile development has aspired toward “write once, run anywhere” since the earliest days of Java. When iPhone first launched, we saw companies like Facebook try to implement a generalized, WebView-based approach, before abandoning that effort and going native. Only a few years later in 2015, Facebook would try again with React Native, adopted with great fanfare by companies like Airbnb only to be undone a few years later.

Dropbox attempted to build a cross-platform C++ mobile library, but concluded that:

…mobile developers simply did not want to work on a C++ project…the associated overhead made the cost of this approach outweigh the benefits.

Other companies like Square acknowledged that “we still build everything twice”, but that mobile development has converged such that:

…we’re asking Android engineers to review iOS pull requests and vice-versa. We’re focusing these reviews on business logic and view models.

At Perry Street Software, we have been writing mobile apps since 2009 and publish two of the oldest apps on the iOS App Store — LGBTQ+ dating apps SCRUFF and Jack’d. We have witnessed every stage of the evolution of mobile development on iOS and Android, though as a small software company, we have had to be thoughtful about how we invest coding time and resources.

We agree with Square — write twice, but aim to align the code that implements “business logic.” But what does this mean in practice, and can you copy Swift code into Android Studio, or Kotlin into Xcode, twiddle your let ↔️ val, and use that as a template?

Google + Uncle Bob = Clean MVVM

There are many design patterns on mobile, among the most popular being MVC, MVVM, VIPER. At PSS, we started out with MVC, and over time have moved toward an MVVM designed informed by the Clean Architecture popularized by Uncle Bob and by Google’s Guide to App Architecture.

Source: Google Guide to App Architecture and Microsoft Paint

We can synthesize both into this diagram below:

We call this Clean MVVM. Data flows up from an injected API, through a Repository layer, Logic layer, ViewModel layer, and ultimately to our Views. Control flows down from the ViewController/Activity/Fragment. These are the primary structure and classes we use for all screens of our app.

In the remainder of this 9-part series, we will share the rules we apply when writing each of these layers as well as side-by-side examples, with a goal of maximum code parity in Swift and Kotlin.

90% of iOS developers get this wrong

What we are about to share will be familiar to many Android developers, because Google (to their credit) took a leadership position on discussing mobile application architecture in 2017. Apple has been a comparative laggard, given they only introduced reactive bindings with their Combine framework in 2019 and have none of the corresponding architectural blogs that Google has written. As a result, ask a typical iOS developer to implement a ViewModel, and they will either write it using custom protocols:

protocol ViewModelEvents: class {
    func changeBackground()
}class ViewModel {
    weak var delegate: ViewModelEvents?

    init(delegate: ViewModelEvents) {
        self.delegate = delegate
    }

    func loadDataFromServer() {
        delegate?.changeBackground()
    }
}

Or they will write it using closures:

private func initViewModel() {
    viewModel.onModelChange = { [weak self] () in
        DispatchQueue.main.async {
            self?.tableView.reloadData()
        }
    }

    viewModel.fetchData()
}

If iOS developers take one thing away from this series, please let it be this: ViewModels must use Combine (or RxSwift or ReactiveSwift). There are plenty of blogs explaining why.

Not a fan of blogs? This Netflix video will change your life, in 28 minutes, we promise!

Next up

We will start by sharing rules for building the ViewModel class, the component with which most developers likely have some experience, in a consistent, cross-platform way.

Other series you might like

Clean API Architecture (2021)
Classes, execution patterns, and abstractions when building a modern API endpoint.

Android Activity Lifecycle considered harmful (2021)
Android process death, unexplainable NullPointerExceptions, and the MVVM lifecycle you need right now

One more thing…

If you’re a mobile developer who enjoys app architecture, are interested in working for a values-first app company serving the queer community, talk to us! Visit https://www.scruff.com/careers for info about jobs at Perry Street Software.

About the author

Eric Silverberg is the CEO and founder of Perry Street Software, publisher of two of the world’s largest LGBTQ+ dating apps on iOS and Android. He has been shipping mobile apps since 2010 and writing code since that english class book report in Hypertalk in 1995.