Here at Freetrade we highly encourage engineers who are more familiar with backend work to work on our mobile apps. This allows us to share knowledge, develop features end-to-end, and get closer to our users.
However mobile development can be daunting, especially some of the design choices that come with it. To make these decisions more obvious, we wrote this handy guide to answer some of the questions we mobile-first developers often get asked. And then we figured – why not make this visible to everyone?
Importantly, these questions are also a great insight into how working on mobile is at Freetrade. Like the look of it? Come join the team!
In previous roles I have found that cross-platform development builds a more consistent product and reduces feature disparity. Given we want our product to have the same features on each platform, we believe that we should use Conway's Law to our advantage – by having teams that own both their features across Android and iOS, they will build a more consistent feature.
Ultimately, iOS and Android are not as different as you may have been led to believe. There are a lot of APIs which are nearly one-for-one equivalent across the platforms, and they are used in a very similar way since we use Kotlin and Swift – two pretty similar languages.
Ultimately, because they were developed as native apps first, we develop native apps. 😄
But seriously, there are a few advantages:
There are of course disadvantages, one of which being writing the same code twice. Where we can, we try to push logic we would write in each app into HTTP APIs – this allows us to hotfix issues quicker too.
We're going to investigate using Kotlin Multiplatform in the future as it allows us to keep the native apps, while sharing business logic.
Reactive coding is a common pattern in mobile development and a lot of developers are familiar with it. Reactive coding is also common on the web – because ultimately a Promise is reactive.
Rx allows us to make data manipulation and business logic clearer as a series of steps (although it definitely has a steep learning curve). It also makes threading easier which is very important in mobile development so the app doesn't freeze.
A key strength of Rx is that it has a (relatively) similar API across all platforms. This means the business logic can be consistent across Android and iOS (and potentially Web in the future).
We don't use either of these tools yet. We can't use SwiftUI yet as we need to support older versions of iOS.
We could use Compose but it has only just entered Beta. We will certainly open up the discussion when it is more stable.
Right now, for iOS we write UI in code using UIKit. For Android, we use XML.
Ultimately, it is easier for developers less familiar with mobile systems to get used to our platforms when they're two sides of the same coin.
We don't really want our iOS and Android apps to have different behaviour (see above), so making them as similar as possible helps this. This is why we don't use Android-only APIs like Data Binding (in preference for hand-rolling it), or iOS-specific architectures which would then be unfamiliar to Android (like VIPER).
Where we do have differences, they are explicit and for a decent reason:
We have our brilliant QA team who build automated tests so we no longer develop UI tests within the projects.
However we have a pretty great set of unit tests across both platforms. You can write your unit tests to be as small or as large as you like – there are no hard and fast rules here! We rarely test our Android/iOS components because we aim to have as much business logic in our View Models, which are tested.
