Bringing a Financial Transaction App Back to the Stores
The technical foundation of the app members use to follow their savings, loans and instalments was rebuilt. The systems behind it were left untouched, and the app returned to both stores in two months.
The app could no longer be updated
The client is a corporate mutual-aid and savings institution with tens of thousands of members. Members pay regular contributions, receive a profit share on their savings, and can borrow against those savings and repay in instalments. The mobile app is where a member runs that whole relationship — an app where money comes in, goes out and gets calculated.
The app had not been updated in years and had fallen behind store requirements. What that means in practice is serious: no new version can be published, problems accumulate on newly released devices, and when a security patch is needed it cannot be shipped. In an app tens of thousands of people use to reach their money, that is not a maintenance item you can postpone.
We were asked to bring it up to today's requirements and get it relisted on both stores.
Why this was not a simple update
This was not an update. It was rebuilding the ground the app stands on.
The technology layer the app runs on (React Native) had been redesigned in the intervening period: the engine that runs the code had changed, the libraries handling screen transitions and data flow had moved to new major versions, and both Android's way of asking users for permission and Apple's privacy declaration requirements had been redefined. Updating the pieces one by one was not going to work.
There was a further constraint: the institution's server side would not be touched. The app had to keep speaking the same language as the existing services. So the renewal happened entirely on the phone side, without breaking a single integration.
Then there was the nature of the content. The screens show amounts, due dates, instalments and balances. In an app that shows money, a wrong figure costs far more than a slow screen — so correctness and error handling came before any visual refresh.
At this point two options usually present themselves: rewrite the app from scratch, or keep patching the existing code. Neither was taken. The app itself stayed exactly as it was, with its thirty screens and its business rules. Only the technology layer underneath it changed.
What we did
The foundation was rebuilt
The technology layer the app runs on was moved to current versions, the engine running the code was replaced, and the iOS and Android project files were regenerated from scratch.
Meeting store requirements
Everything Apple and Google ask for today was put in place: current OS targets, the privacy declaration, permission descriptions and notification entitlements. Without these the app could not pass store review.
The version number did not match itself
The app's version number was kept in four separate files and they disagreed. That can send a package to the store under the wrong number and get the release rejected. We read which value actually reaches the build, found the mismatch and aligned all four.
The release key was verified
A package uploaded to the store had been rejected because its signature did not match what was expected. The correct key was restored and re-uploaded only after we verified it matched the store's expected value exactly.
So it does not crash in production
Protection against crashing on launch was added. If something goes wrong in notifications the app no longer closes. That feature simply switches off. Technical output used during development was stripped from the release build.
Notifications rebuilt
The app's notification delivery was moved off an intermediary service and onto Google's notification infrastructure directly, configured separately for Android and iOS.
The keys were handed to the institution
The app's release keys, store identity files and notification certificates were handed over together with an inventory explaining what each one is for, where it is kept and when it needs renewing. If you do not hold your app's release key, the app is not really yours.
Outcome
The work was completed in two months. The app was relisted on both stores. Before release it was tested end to end on real devices, sign-in and financial flows included, and it went live with the institution's approval.
The delivered app has thirty screens and roughly 17,700 lines of code.
The real gain is this: the app can be updated again. Adding a feature, shipping a security patch and keeping up each time store rules change are all possible for years to come.
Is a business-critical app of yours ageing?
An application your customer relationship or a core process runs on will drift behind store requirements over time. By the time anyone notices, the options usually narrow to two: rewrite it, or attempt a risky renovation.
This project took a third path. The technology layer beneath the app was rebuilt while the systems behind it were left untouched. Not one integration broke, and the work was done in two months.
This particular job was at enterprise scale. The smaller version of the same problem is far more common: an application a few years old, a codebase nobody wants to touch, a release key nobody can locate. The scale changes; the things worth checking do not.
Let us assess together where your application stands today and which path fits your situation.
Let us assess your application →
Ready to start your next software project with Kepiten?
Tell us what you are trying to build. We will shape it around how your business actually works.