John Yorke here, I am an iOS engineer on the newly-formed core experience squad. We’re rolling out a couple of new features and wanted to give you a heads up.
- We’re replacing “Payments with friends” with a more granular “Profile Privacy” system
- We’re replacing the monzo.me link builder screen with a QR-focused experience
I won’t spend too long on this one (as it’s arguably less exciting than #2!) but we ran some user-testing sessions late last year and one of the main bits of feedback we received was that people wanted (and have come to expect) more granular privacy settings than we offered at the time.
To use our social features (Bill Splits, Shared Tabs, Monzo.me) we required the user to have opted into ‘Payment with friends’ and have given Monzo access to their contact database on their device. Right off the bat, this was with good intentions. We thought it was simpler to have just one toggle and we went out of our way to never extract full phone numbers from the device (this is still true by the way). For all the simplicity - it was a bit of an all-or-nothing approach.
Introducing Profile Privacy. This new system allows you to control how people can find you - via username/QR/monzo.me or via the privacy-focused phone number matching service. It doesn’t control who you can find - ergo, it does not require access to your contact database.
This means you can take part in Bill Splits, Shared Tabs or share monzo.me links with other friends that are happy to do so. If you allow yourself to be discovered by phone number, then you will appear in the results for the partial phone number your friend sends up. Change your mind and want to stop appearing in those results? Head to Profile Privacy and flip it off.
All-or-nothing approach is gone, privacy is now in your hands.
Monzo.me QR codes
Monzo.me allows you to receive money easily via a dedicated web address for your account (in fact it’s even easier now we’ve enabled Apple/Google Pay on there ). You can request specific amounts and add a reference too so the recipient of the link knows what you’re requesting it for (and yes it supports emojis ).
Thanks in large part to COVID, QR codes has now become ubiquitous in this country and help seamlessly bridge the gap between physical and digital. So in an effort to offer yet another way to get paid ~early~ on time, we’re keeping the same great link builder but adding a beautiful Monzo specific QR code alongside it too.
You can still set a custom amount and add a reference, and when you do so you will see the QR update ready for your friend to pay-up. If they’re on Monzo, they can scan it and go straight to the Monzo-to-Monzo payment flow, if they’re not on Monzo they will go to the web address where they can pay via bank details or Apple/Google Pay.
Don’t worry, sharing a link is still a thing too. You can always share your amount and note-less link by tapping your profile icon at the top, or if you want to share a customised link then you can tap “Share a link instead” button at the bottom.
‘Nearby’ is also still there for when you’re part of an exclusive all-Monzo collective, but QR helps bring some of that magic to non-Monzo friends too. We’ve been testing it for a while and we love it! We think it’s the fastest way to get paid back.
iOS and Android nuance
Early on in this project, we faced a bit of a crossroads when speccing out the QR code generation. iOS has a nifty CoreImage “filter” to generate QR codes quickly and natively, where Android sadly does not.
We investigated some 3rd party libraries on Android that could help us do it all ‘on-device’, but nothing met our criteria when selecting 3rd party dependencies. It needs to be well-supported, secure and do its one thing well (ie. not introduce 100s of classes we won’t use). We weren’t fully convinced by any of the libraries we saw.
So we took a decision that we don’t take often at Monzo, and opted to deviate in terms of implementation. The iOS client will render the QR fast and do all the computation on-device, the Android client will hit an endpoint and request the QR graphic over-the-air.
As with everything, there are pros and cons to both approaches. On iOS, if we discover a bug in the QR code (perhaps we miss the “.” in the URL) or that the code doesn’t scan well in certain environments - we’ll need to submit a new version of the app and wait for weeks for it to propagate down to our customer’s devices. That same situation on Android can be fixed on the backend and a fix deployed within hours.
What do you gain from doing it on the device however? Speed. The iOS code generation is so fast it can pretty-much keep up with your typing and it means your code is always available, even in rough network situations.
Doing it on device on iOS also freed up the engineering effort to add some nifty real-time effects to the code - move your device to see a shimmer move across the code as if it were printed and shiny. The Monzo logo in the centre too reacts to the movement of your device. Whimsical touches perhaps - but fun!
Android on the other hand, has a super robust and much more flexible and readily upgradeable solution. We put great effort into updating our existing backend QR image generation services (used in Business Banking) to produce fancier graphics with subtle gradients and light/dark mode support. We also made it faster, so when you’re generating a code you should see the response come back and the screen update super fast!
Everyone is a winner! And we’re not overly committed to either approach. If we get feedback that people love how fast iOS feels, we might re-consider 3rd parties (or write our own) on Android. If Apple break or drop support for the QR code filter, we might want to avoid being exposed like that again and switch to backend generated codes.
Thanks for lending me your eyes. I set off to write something “quick” for the community post and have instead given you a rather large peek behind the curtain of our product and engineering mentality.
I hope you enjoy this write-up as much as I enjoyed writing it. Can’t wait to hear your thoughts and ideas.