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
This is awesome, so glad that the issue(s) with iOS have been identified as a key point, and thereās a dedicated team for this - I know @N26throwaway throwaway will be happy too!
@iOS_Health - how can we, as iOS users help most? Should we just be using TestFlight & reporting every crash through there? Do you read them? Would it be better for us to duplicate issue(s) here?
Additionally, what key areas have you identified as the initial area to focus on?
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:
forced logouts
crashes
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.
This is brilliant. Loving the ambition to include broken flows. That would help a lot.
(Depending on what Apple come out with, Iām potentially eyeing up an iPhone next time. But Monzo being a bit meh on iOS would genuinely keep me on Android).
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?
Performance issues aside I hope it doesnāt cause a further imbalance. Of course Iām bias to Android but iOS have some pretty cool things (like advanced search) that Android doesnāt.
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.
This is awesome, so glad that the issue(s) with iOS have been identified as a key point, and thereās a dedicated team for this - I know 
)
