Kotlin in Xcode? Swift in Android Studio?

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

Eric Silverberg
Dec 4, 2020 · 4 min read
The bridge is Clean + MVVM

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.

The Startup

Get smarter at building your thing. Join The Startup’s +792K followers.

Sign up for Top 10 Stories

By The Startup

Get smarter at building your thing. Subscribe to receive The Startup's top 10 most read stories — delivered straight into your inbox, once a week. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +792K followers.

Eric Silverberg

Written by

CEO, Perry Street Software. Developer. 🏳️‍🌈

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +792K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store