Having worked on a couple of iOS banking apps there’s a few reasons:
1. Additional security frameworks to help with anti-tampering, often from 3rd parties who have little desire to decrease their frameworks size. Surprising amount require frameworks for mapping/location, photos, camera, bluetooth etc due to anti-fraud and fingerprinting checks
2. Many bank apps obfuscate their binaries/code which increases size
3. Many have huge backwards compatibility requirements so end up always having older frameworks or multiple versions in some cases
4. Often large number of devices need to be supported as such they may have interface files and image assets for say iPhone and iPad, these can and should be stripped out but often aren’t
5. Many banks also have single codebases supporting multiple brands of their banks and subsidiaries, or for their business vs personal vs premier/VIP/platinum customers, they use asset catalogs etc to reskin each but theres often bloat from the overlap
6. Lots and lots of legacy code which often never gets removed. Many still have Objective-C code/dependencies for example
7. There’s often a surprising amount of functionality in banking apps that goes amiss by most users who only really use it to check their balances, eg Cheque scanning/OCR, biometrics (beyond Face ID / Touch ID), receipt management, business or premier customers may have chat or video facilities with their relationship manager etc
8. The app is built by a large consulting company and no-one gives a shit about the package size because the client isn’t paying extra for that (or “we will put it on the backlog”, and then it’s never addressed)
Not necessarily. I was implying that part of the problem was that the applications are made cheaply and quickly, which necessitates the use of huge frameworks and libraries that make this possible. And then, because no one with decision making power cares about the size so much, these are just left in place instead of selectively rewriting or stripping the over-large parts to shrink the package.
This is distinct from any “feature-enabling” type bloat IMO, because it’s more “development style enabler” type bloat instead.
And its not a revenue generator if size is smaller - most customers wouldn't know how to determine the app size and wouldn't know what it means even if they saw its size.
1. Additional security frameworks to help with anti-tampering, often from 3rd parties who have little desire to decrease their frameworks size. Surprising amount require frameworks for mapping/location, photos, camera, bluetooth etc due to anti-fraud and fingerprinting checks
2. Many bank apps obfuscate their binaries/code which increases size
3. Many have huge backwards compatibility requirements so end up always having older frameworks or multiple versions in some cases
4. Often large number of devices need to be supported as such they may have interface files and image assets for say iPhone and iPad, these can and should be stripped out but often aren’t
5. Many banks also have single codebases supporting multiple brands of their banks and subsidiaries, or for their business vs personal vs premier/VIP/platinum customers, they use asset catalogs etc to reskin each but theres often bloat from the overlap
6. Lots and lots of legacy code which often never gets removed. Many still have Objective-C code/dependencies for example
7. There’s often a surprising amount of functionality in banking apps that goes amiss by most users who only really use it to check their balances, eg Cheque scanning/OCR, biometrics (beyond Face ID / Touch ID), receipt management, business or premier customers may have chat or video facilities with their relationship manager etc