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!
Why do we expect developers to work across Android and iOS?
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.
Do we develop native apps or use cross-platform technologies?
Ultimately, because they were developed as native apps first, we develop native apps. 😄
But seriously, there are a few advantages:
- Things like charting are complicated and best suited to native apps.
- Native allows us to make the most of the platforms without having a translation layer.
- It means we can take advantage of new tech in the platforms without having to wait for React Native or Flutter to implement them first. For example, our iPad Split View would've been much harder without using native directly.
- It means we have fewer tech choices to make and maintain – instead of developers needing to know React Native and native to implement our more complex features.
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.
Why do we use Rx?
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).
Do we use SwiftUI or Compose?
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.
Why don't we use Android/iOS specific APIs often?
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:
- Views in Android are in XML because that is how everyone does it. This means it is easier for engineers to find tutorials or Stack Overflow questions if they're stuck.
- Dependency Injection is different because Dagger & Hilt avoid some boilerplate for us on Android (although definitely adds some complexity). iOS doesn't really have a DI framework with such strong support as Dagger does.
What is our approach to automated testing?
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.
This should not be read as personal investment advice and individual investors should make their own decisions or seek independent advice. This article has not been prepared in accordance with legal requirements designed to promote the independence of investment research and is considered a marketing communication.When you invest, your capital is at risk. The value of your portfolio can go down as well as up and you may get back less than you invest. Past performance is not a reliable indicator of future results.Freetrade is a trading name of Freetrade Limited, which is a member firm of the London Stock Exchange and is authorised and regulated by the Financial Conduct Authority. Registered in England and Wales (no. 09797821).
