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.
Pretty much all of those apps will use cross-platform frameworks to save costs and bundle bunch of extremely bloated proprietary (paid) libraries. It's not strange to see those whole apps written in web stack and bundling whole Chromium and bunch of large native libraries claiming they "detect unsecure phones" (while mostly just crashing when they see something like Android 13 or iOS 16).
Almost all of them are outsourced as well, so you get the cheapest solution done by cheapest developers combined with box ticking compliance.
Thinking exactly the same thing. Plus... banks are already worth billions and have little reason to invest in things that doesn't effect their bottom line when they are already printing money.
That, and quality of the app is not really a decision that drives selection of a bank. I've been told by a certain EU bank marketer that "if we get them before 18, they're ours until death". Which is a bit of an exaggeration, but it's telling about just how sticky the customers for banks are. Switching out accounts and losing those preferred mortgage deals is a big deal.
Such arrogance will not go unpunished. Banks have two ways to differentiate. Better app and better prices. The prices they can offer is based on their degree of automation and the quality of their risk models. In other words, they are tech companies and they better act like it.
This is so true. Long ago I had a telesales warm calling job for a mortgage product. The number of customers who had all their financial services from a single one of the big few (U.K.) banks was telling
I agree with you. Let me expand my thoughts: I can't say with certainty, but here's a guess: I've certainly seen this behavior from more junior devs who don't have a senior to coach them and I've also seen this commonly when the software is outsourced to the cheapest 3rd party contractor who has no real skin in the game other than getting the product delivered to the client.
What I've observed is that in both cases the devs will use npm/nuget/yarn/favorite-package-manager with a bias for pulling in lots of packages, which all have lots of dependencies themselves. There ends up being a lot of bloat. Lots of libraries that are either not in use or really aren't needed.
Both scenarios happen frequently to companies that are no tech companies first.
They may also be dealing with old / proprietary tech stacks—due to regulatory, industry, or security realities—that make using modern standards very cumbersome / impossible.
I'll add this just as a reference point. 3 Banking/Insurance apps on my phone:
Home Banking 1:
- App Size 129MB
- Docs & Data 19MB
Home Banking 2:
- App Size 98MB
- Docs & Data 8MB
Insurance:
- App Size 102MB
- Docs & Data 12MB
< 150MB seems somewhat reasonable to me
And since you mentioned other apps: Telegram is 98MB, Airbnb 218MB, Spotify 143MB, 1Password 128MB just to name a few I have on my phone right now. So Around 150 seems about normal.
All three the apps I mentioned are for Italian based companies, not sure if the situation is different in other countries.
They are designed essentially by a committee. What others said about security,anti-*,obfuscation can apply to lighter apps as well.
These apps reflect the complexities of the organization. Each sub feature can have an entirely different stakeholder and not being a tech-first company means outsourcing to a an army of devs that will pile on code for more profit or internal devs who will pile on code upon code back and forth because the stakeholder's vision is rarely is communicated accurately or efficiently to whoever writes the code. And then that work has to go through security, qa,marketing,etc.... back and forth. Essentially, it will probably feel like a miracle that they managed to make a functioning app if you're used to tech-first companies.
It's not only the bundle size for me: the runtime is slow.
Not "React Native with redux rerendering" slow, but "like a slow webpage disguised as app with lagging frames after tapping simple buttons for basic actions" slow.
One data point: I made a banking app (Creator Cash) and it's 37.1 MB on the App Store.
- Used React Native
- More features than you'd expect from a typical bank (card issuing/ management, sending payments, invoicing, CRM of contacts to pay/invoice, push debit to fund your Creator Cash account from your brick and mortar without having to send from the brick and mortar, data viz for earnings by platform, earned wage access aka cash advances, and more)
- Uses Stripe Treasury for BaaS
I could speculate, but I'm not really sure what causes that much bloat in other banking apps.
Requirements for a banking app (or even a retail app) is not like you might expect on a FANG-type app. Focus would be on functionality, stability, possibly ease of use (but way down the line), and security. I'm guessing management is not too bothered about app size and banking mgmt won't be overly technically focused.
Incidentally I was maintaining a cross platform mobile app for a major UK company. Between Android versions of the fairly ancient framework the app size grew 2 or 3 fold. There were a couple of issues, one was js minification was failing before it was wrapped into a native app by the framework, I think I fixed that in the build file. Also both the ARM and x86 libraries were being included in the APK even though we were only targeting one particular device series. Removing one of these almost halved the file size. It was only really the guy managing the devices and device builds that cared about this, the business wouldn't have noticed.
Somwwhere around 2014 the PR dept sent a mail allempoyee@... incuding a 3Mb image.
I don't remember how much we shelled out for our 3PAR SAN, which hosted Exchange data in a CCR cluster, but it wasn't a pocket change AND we had 14000 mailboxes at that time.
My intuition tells me it's mostly, if not all, security based decisions. Like, the reason that a lock is typically big and heavy and takes a little bit of trouble to open and close.
That’s a nice sentiment, but based on what I’ve seen of how this particular sausage is made, I’m willing to bet it’s literally that no-one with the right amount of influence cares enough about shrinking the package size. So it just stays like that.
My first thought was "I wonder if lockmakers are really protective of their methods / manufacturing process," but realized this information would matter little: the point is that it doesn't matter if people know exactly how the lock is made, because it doesn't make it any faster to open it, and I've only got 2 hands and 24 hours in a day and the time just isn't worth the risk.
> Like, the reason that a lock is typically big and heavy and takes a little bit of trouble to open and close.
The sad part is that making the lock big and heavy usually only makes the intended uses of the lock inconvenient; the unintended bypasses don't care about those.
I mean more metaphoricaly big and heavy. Like, putting in a password is costly. It has to live somewhere. It requires effort. It takes a moment. You have to memorize something. It causes a moment in the flow of utility.
A similar dynamic seems to play out for apps of health insurance companies, where the typical user with employer-provided insurance doesn’t get to choose the provider
I was thinking earlier: I wonder how different the landscape would look if customers had the freedom to choose their banking "front-end," linked up to their brick-and-mortar.
Insurance is a great example of the same thing: horrible apps that only do 3 things but are 400MB.
Everything I've read so far has overlooked something.
Assets, and the ability to update them. banking apps are typically pretty simple, where you're essentially wrapping all of the 'core' behavior in another API, and that API is doing all the heavy lifting, and sending JSON like they all do.
I think the real reason is around asset templates, and transpiling
It feels like atleast some of them use the same company or UI framework to build the app. So bloated for one company means bloated for others. Also from what I can see they have lot of third party libraries included for security purposes like detecting jailbroken phones and gathering location based intelligence etc
The client should be considered insecure as it runs on a device the bank does not control, and their backend should be built with that in mind. So why does it matter if the device is jail broken or not?
Many of them bundle with heavy graphing libraries and OCR libraries for reading receipts or credit cards and what not, so they already start off pretty heavy. Then they are often cross platform, making them even bigger. Then add every tracking software under the sun.
The web gets its share of criticism and sometimes its deserved, but it runs on every device, on every screen size and never comes close to the size of an app.
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