We’ve got a new dedicated team within Monzo who are going to be focusing on the iOS version of the app and I thought it’d be great to introduce them in a bit more detail to you. Say hello to @iOS_Health
First up we’ve got @leewatkins who has been floating around on the Community for a while and he’s been kind enough to give us a little bio below:
Hi, I’m Lee. I’m an iOS engineer at Monzo. I’ve been at Monzo for just over 3.5 years now. I’ve worked primarily in two parts of the app;
Signup and onboarding (for new customers,) building things like:
• the new, compact header on the Accounts List and
• some other stuff that most of you veteran Monzo users won’t see
Improving some of our core app features, especially Pots. I’ve worked on things like:
• Salary Sorter,
• the Feed/Manage tabs on accounts and Pots,
• the Pots feed,
• virtual cards on Pots and
• paying from Pots
In addition to being an iOS engineer, I’m also a coffee lover and huge Formula 1 fan.
We’ve also got @MikeMurray who has been with Monzo for a while but this will be his first proper visit to the Community. Mike’s written a little intro for everyone to read here:
Hello, I’m Mike I’m one of the iOS Engineers at Monzo. Been here coming up for 2 years, in that time I’ve worked on a few things:
• Shipped the first version of Monzo Flex
• Worked on some improvements to our existing loan application flow
• Shipped the new top-up and debt consolidation loan flows
• Worked on some new Open Banking features
I’m quite passionate about Software Engineering, and spend time outside of work tinkering with technologies that interest me. Most recently Elm, Elixir, and Haskell.
I’m also a huge petrolhead, and have recently got into the world of 1:10 scale radio control car racing.
Overall we want to improve how these bugs get picked up and resolved creating a slick feedback loop
To do this, we may change the format of what we require in bug reports but if there’s any questions feel free to ask @iOS_Health or me
Yes & yes, that’s a great way to share crashes because TestFlight includes crash logs (if you’ve give permission to share those) which help us a huge amount. If you’d be able to include a brief description of what you were doing at the time in the notes, that helps us group crashes to see which are happening most often.
It’s up to you - we’re just happy to have the data to help find the problems. I think that the forum will likely be the most convenient place to share the details because:
it’ll be easier to share those details here rather than in the tiny text box on the TestFlight report form, so feel free to share long-form information with us here.
if you can provide a date/time we can always go and look through TestFlight data and match up the crash report there with your report on the forum.
sharing on the forum also gives you the opportunity to come back and write up extra info when it’s convenient for you rather than having to do it on the go or while you’re busy with something.
What to share: if you’ve noticed specific usage patterns that cause crashes, that makes it much easier for us to replicate that problem and therefore fix it.
We’re focussing on things that get in the way of users doing the job that they set out to do.
We’re starting with:
then we hope to move on to slow app performance (slow scrolling, glitches that make you miss buttons, taps that don’t take you anywhere or don’t give you any feedback, those sorts of things)
and then (later) broken flows (things like back buttons not working, screens that don’t auto-dismiss, that sort of thing.)
Fortunately, I’ve not experienced any of the first ones - so that’s not something I can help with. Gladly will share all of the TestFlight crashes I have from the others though! If I notice anything out of whack, I’ll share them here too - so that you’re aware
Heart Rate monitoring when payments are taken, or when received.
Two things - I made the right connection but could I suggest iOS performance team @AlanDoe?
Secondly be really interesting to hear what happens in the depths of the coding. For example do you guys use any form of automated testing/TDD (I might have asked this before) and other quality engineering practices so where possible things get picked up early stages?
This sounds great, but I do have a few questions about it.
Firstly, how detailed do you want our bug reports to be, in general? Are you just looking for trends or do you want us to document specific bugs in detail (I usually do this on Testflight but I’ve never been sure if I’m being helpful or not)? Do you want all Testflight users to do this (even iOS beta users) or are you more interested in users on stable/current releases? In the past, I’ve submitted detailed reports and then re-submitted short reports when the same issue occurs again. Do you want us to do that every time?
Also, I think it would be helpful for the team to set out a “how to write bug reports” post which, rather than generally telling us how to write reports, tells us how to write them specifically how the Monzo team would find most helpful. Sort of like Apple’s guide below, but specific to Monzo. Is that something you might be interested in doing?
Example - here’s Apple’s advice for submitting bug reports properly, from the summer 2021 iOS 15 beta
When and how to submit feedback
File whenever you encounter a problem. If something you have used in the past doesn’t seem to be working now, or a new feature doesn’t seem to behave the way you thought it would, or you’re finding that apps are quitting unexpectedly (“crashing”) or becoming unresponsive (“hanging”) or simply running too slow to be useable anymore, that’s a problem!
**Start your feedback as soon as you can.**The Feedback Assistant app collects time-sensitive logging when you start a new feedback, so it can help if you start your feedback report close to when you saw the problem. You can always start and save your draft immediately, then finish and submit later.
Protip: If you can tell us, in your feedback, when the problem happened, it will help us pinpoint, in the log files, what was happening on your device at the time. If you can tell us the date and time it occurred, that’s great, but even an estimate of how many minutes or hours before you started writing your feedback will help tremendously.
Give your feedback a clear and specific title. If you had to describe the thing that went wrong in a single sentence, what would it be? You’ll have a chance to go into more detail in the description, but a title that quickly tells the story really helps us know what kind of investigation is going to be appropriate.
“Cannot download attachments from Mail messages”
“Safari quits unexpectedly when loading front page of apple.com”
“AirDrop on my iPhone no longer sees my iMac”
Provide as much detail as you can in the description. What were you doing before the problem occurred? What were you expecting would happen, and how did the problem differ from your expectations? Have you seen the problem occur more than once? Are you able to make the problem happen every time? (We call that “reproducing” the problem.) What are the shortest or simplest set of setups you have to go through to make it happen?
Protip: Depending on which area (feature or app) you select while composing your feedback, we may ask a few more questions to get even more specific information about the problem.
Consider screenshots and screen recordings as a way to show as well as tell. Pictures are worth a thousand words. Screenshots and recordings can be very helpful for understanding a bug when there are many different words you could use to describe a symptom you are seeing or set of steps that you are going through. Detailed descriptions of how to capture screenshots and screen recordings are available on our support pages:
Include all of the relevant file information that is needed. Depending on which features of the OS you are sending feedback about, there may be additional, specific logs or files that we ask for. When using Feedback Assistant on iOS or iPadOS, before you hit “Submit”, if you see a “Gather” link in the File Uploads section of your feedback, click on it to include additional logs that are relevant to the type of feedback you are reporting. Using Feedback Assistant on macOS, before you hit “Submit”, if you see items in red in the File Uploads section of your feedback, click “Previous” to return to the Attach Files page and then, for each greyed-out item that remains, click on the question mark to see how to gather that information.
Make sure the information you want to submit is uploaded. Once you hit “Submit”, your feedback and any files or logging you’ve collected will begin uploading. This can take some time, depending on your network connection and the amount of information, but it should continue with uploading in the background as long as your device is awake and connected to the Internet.