Kotlin in Xcode? Swift in Android Studio?
By: Eric Silverberg
Tags: Reactive Programming, Kotlin, Mvvm, Swift, Rxjava

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.

Facebook on using UIWebView

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.

The Original

Source: Google Guide to App Architecture and Microsoft Paint

We can synthesize both into this diagram below:

The colors match uncle bob’s 🔵🟢🔴🟡

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.

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.

More in the series

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.