Near daily we got emails, messages, telegrams, and feedback at events asking a simple question: When Android?

It was a busy summer! 🌞

This post details our experiences in launching a Blockchain native wallet on top of the Android platform.

First Some Background ✅

Monolith is a non-custodial banking alternative, powered by Ethereum. You can securely store Ethereum-based tokens in your own decentralised Monolith wallet. You can then exchange them to fiat and load them onto your Monolith Visa debit card.

This means that in order to deliver a great User Experience (UX), we have to enable users to seamlessly interact with both the decentralised world of Ethereum as well as the traditional financial world.

Monolith was conceived back in 2016 by our founders, Mel and David. After acquiring the appropriate licenses and partnerships, we set out to build what we thought the bank of the future should look like.

Launching on iOS first 📲

The bank of the future is accessible anywhere, so we started working on our mobile app. We built on iOS first due to its homogenous operating system distribution and the availability of the secure enclave on their devices. It’s a public secret at this point that building on iOS first is generally easier (with some exceptions).

We built our application in a cross-platform way using react-native. Our User Interfaces (UIs) were designed in a platform-agnostic way, whilst still respecting native elements and patterns such as UI components and controls. At such an early stage it made sense to prioritise go-to-market speed and iterative design over a platform-specific design.

We launched our invite-only iOS closed alpha in March, and publicly on the App Store in June. Our time exclusively on iOS helped us really nail down what a good onboarding experience feels like for our product and hammer out the kinks of interacting with something as nuanced as the Ethereum network.

Creation of the Android squad 💪

3rd of June, 2019. We had finally released on iOS and whilst we knew that we could probably get the Android app out relatively quickly. However, we needed to make sure to do in a way that protected our users.

Given the diverse Android landscape, we got a team together and we defined our goal:

Demystifying the Android landscape 🌪

A key assumption in our security model is that customer keys are securely stored in their devices. On iOS, we could rely on the Secure Enclave. However, Android has a number of different Keystore implementations. Some are backed by the Secure Element (SE), Trusted Execution Environment (TEE) and most recently StrongBox. Furthermore, not all manufacturers implement Android APIs consistently. We very quickly had a number of questions to answer. For example:

What type of ECC signature schemes does Android natively support, if any? To generate the mnemonic, we use BIP39 which requires entropy of 32 bits. On iOS, we use the PrimeRandom secure enclave API. What are the alternatives for this on Android? Can we perform feature detection for devices that do not have a hardware Keymaster implementation (that back the Keystore) and restrict based on this? How? What are the different features to consider? Which ones would we restrict? […] etc, etc, etc

So we got busy researching and prototyping:

Given our findings, the minimum OS level that we were comfortable with supporting was Android Nougat (API 24) as it introduced unified support for the Keystore interface in a manner that ensures that users don’t accidentally remove their private key whilst messing around with their biometrics.

But what devices did our users have? ⁉️

To get this answered we had a look through the Google Analytics data for our website. We then manually researched the minimum OS level available for Android for each device.

From this, we concluded that even though the global distribution dashboards estimated that only 58% of global users had Android Nougat or higher, with mostly European-based users, the number was closer to 85%. We also understood that this was going to get better over time, and we didn’t want to compromise on security.

Building, Testing, Fixing 🤖

The road ahead was now clearer. First, we had to make the existing functionality work on Android. While most of the react-native components worked straight out of the box, there were native bridges for a number of APIs including key generation and derivation, transaction signing and customer onboarding which needed to be built.

As soon as July came around, we had a basic version and asked our team members to test it in fury. 😀

Mel, our founder was demoing a (partially broken!) internal Android app on our summer livestream on July the 10th.

This phase of development actually took a bit longer than expected. It turned out that our app looked inconsistent on a couple of devices. Once we were confident with the security aspect of things, we released the app as a beta app to 100 community members in August.

We relied on Instabug and Discord to have meaningful conversations with our customers. Over the summer, product managers at Monolith personally responded to most customer messages, bug reports and suggestions! 😊

Two months and 5 Android app iterations later, we were ready to launch!

Sweet Victory ❤

As a team, we’ve gone through a lot to get here, but it’s clear that this is just the beginning. We’ll keep iterating on our product as we strive to understand our customers, and how they use our Wallet and Card in the real world. 🙏

Our goal is to one day be able to confidently ask them to close their bank accounts and live their financial lives on this new paradigm of Decentralised Finance. 🚀

We want to thank everyone who has supported us on this journey. 🎉

Summary