[HN Gopher] Ask HN: Why are banking/finance apps so heavy?
___________________________________________________________________
Ask HN: Why are banking/finance apps so heavy?
I have an iPhone. Of the 10 largest apps on my phone, 4 are
bank/finance apps ... Robinhood clocks in at 480MB, Chase at 350.
What about these apps demands such a large footprint? (Larger than
say Notion, Amazon, messaging, navigation/maps, etc etc)
Author : gffrd
Score : 24 points
Date : 2022-09-20 16:28 UTC (6 hours ago)
| warinukraine wrote:
| I also have the Chase app and can confirm it's heavy.
|
| The Chase customer service though, had been excellent. Just
| thought I'd mention that.
| ajhurliman wrote:
| 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.
| justsomehnguy wrote:
| 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.
|
| "Don't attribute to malice..."
| izacus wrote:
| 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.
| dandigangi wrote:
| 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.
| izacus wrote:
| 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.
| dandigangi wrote:
| Yup! Great example you can see it super quickly is SAP...
| (not a bank but $170B+ value and little incentive to
| improve the quality)
| rdrd wrote:
| 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
| selfhoster11 wrote:
| 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)
| halJordan wrote:
| You didnt really give a new reason, you just said why the
| above reasons might occur.
| ilrwbwrkhv wrote:
| Cause they are not tech companies. They use the cheapest labour
| which gets the job done.
| daveslash wrote:
| 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.
| colechristensen wrote:
| Robinhood is 100% a SV tech company and does not use "the
| cheapest labor".
| gffrd wrote:
| Per the manifest, 450MB of the Robinhood app's weight comes
| from "needless animations"
| gffrd wrote:
| 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.
| unsignedchar wrote:
| 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
| gffrd wrote:
| 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.
| kleer001 wrote:
| 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.
| gffrd wrote:
| Good analogy! And that makes logical sense ...
|
| 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.
| selfhoster11 wrote:
| 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.
| ElectricalUnion wrote:
| > 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.
| izacus wrote:
| What exactly do you think it's "locked" into a mobile app that
| shows a few web templates and forms? :)
| Scorector_PL wrote:
| ev1 wrote:
| 90% of it is anti-root or tracking code
| javier2 wrote:
| 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.
___________________________________________________________________
(page generated 2022-09-20 23:02 UTC)