Bringing a Financial Transaction App Back to the Stores
The platform layer of an application tens of thousands of members trust with their money was rebuilt from the ground up — without touching the systems behind it — and relisted on both stores in two months.
Where we started
The client is a regulated 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. Phone operating systems and app store rules had moved on considerably in that time, and the app had fallen behind them. 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.
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 quietly. 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.
Outcome
The work was completed in two months. The app was relisted on both stores as version 3.0.2; before release it was tested end to end on real devices — sign-in, notification permission and financial flows included — and went live with the institution's approval.
As delivered: 30 screens, roughly 17,700 lines of code. The app now runs on React Native 0.81.5, Expo SDK 54 and React 19.1, supporting iOS 15.1 and above.
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.
Let us assess together where your application stands today and which path fits your situation.
Let us assess your application →
Ready to transform your operations and scale with Kepiten?
Let’s build powerful AI or software solutions together — customized for your business and future growth.