This is just lazy reasoning, really. Android has sandboxed per-app internal storage/database persistence. If that's not good enough, you have the hardware-backed keystore and you can require the user to unlock e.g. a decryption key. I have no interest in iOS, but I'm sure it has equivalent or better functionality.
In my experience historically working with various financial orgs as a consultant, "security" is often cited as an excuse for poor UX and poor software engineering practices.
My own bank will happily show me the last-retrieved transactions and balance when I'm offline in their app. I have more confidence in their security given their policy of publicly talking about security architecture and use of open source tech than the dozen banks that are still using mainframes at the core of their stack and think that preventing the user switching away from/back to their app helps security.
I never said it wasn’t a stupid reason. Everything you said is accurate but… it’s the reason the decision makers who decide what features the app would have give to us. And so, that’s why our app doesn’t have that that.
"Those who would give up essential User Experience, to purchase a little temporary Security, deserve neither User Experience nor Security." - Benjamin Gates
In my experience historically working with various financial orgs as a consultant, "security" is often cited as an excuse for poor UX and poor software engineering practices.
My own bank will happily show me the last-retrieved transactions and balance when I'm offline in their app. I have more confidence in their security given their policy of publicly talking about security architecture and use of open source tech than the dozen banks that are still using mainframes at the core of their stack and think that preventing the user switching away from/back to their app helps security.