Tecnobank - Inheriting an app that would not build
Stabilizing and evolving an iOS and Android app received from another vendor, with both projects stuck before a single new line of code.
The task looked small
Tecnobank works with data for the vehicle financing market. The request was direct: add billing lookup to the existing app, and adjust the design for the final version.
The app came from another vendor, iOS in Swift and Android in Kotlin. This was meant to be evolution work, not construction.
What the first week revealed
None of it was possible without first fixing what sat underneath.
- The source code did not arrive at the start of the project and, when it did, the files were corrupted and would not open. The iOS project would not compile. More than eighty errors, before any change. The project carried two dependency tools at once, CocoaPods and Carthage, duplicating frameworks with no identifiable technical reason. The environment version the client recommended was not compatible with what the code actually required. Android in Kotlin made reading harder for a team that had to move fast over an unfamiliar base.
An inherited app that does not compile is not a setup detail. It is the whole project stopped before it starts.
Unblock first, deliver after
The order of attack was dictated by what was blocking.
Android first. It was the shortest path to a running build. Compilation errors were fixed in the first days, and from then on there was a base to show results on.
Then iOS. Cleaning the dependency tree was the core of the work: updating and fixing packages one by one, and removing the second dependency tool that duplicated frameworks. With the tree clean, the project compiled again and could be moved to the language version the libraries required.
The inherited defects. With the build standing, usage problems surfaced. The app crashed when tapping rows in the contract table, and the fix required manually updating the tab component, including the cell resource missing from the package. The floating button on the home screen also misbehaved, and had its show and hide control adjusted.
The contracted feature
With the base stable, billing lookup went where it belonged: in the financial institution profile, reachable from the floating button on the home screen.
The screen lists recent charges with reference month, due date, payment date, slip amount and status. It was implemented on Android and shipped for client sign-off within the cycle.
The design track ran in parallel. The prototype covered the entire app, not only the new screen: login, home menu, registration lookup, certificate validation, invoice and billing, contract registration and the agent and citizen entry points.
Contract registration brought the real complexity of the domain: the field layout changes by state, and the survey covered seven of them, each with its own set.
The prototype went through successive rounds of client validation, with screen connections adjusted between rounds.
The diagnosis that became a recommendation
Along the way it became clear that the problems in the inherited code did not stop at what blocked the contracted delivery. What surfaced was the symptom of a base that had never been audited.
X-Apps put that in writing and proposed a structural analysis of the software to the client, to map the errors in the base before investing in new features. It also laid out the alternative path: rewriting the app from scratch, with estimates comparing two cross-platform technologies.
Pointing at what lies underneath is part of the work, even when the contracted scope is something else. The client decides what to do with the information, but has to have it.
Stack and practices
- iOS in Swift and Android in Kotlin, both inherited from a previous vendor. CocoaPods for iOS dependencies, with Carthage removed for duplicating frameworks. Manual update of the tab interface component, adding the missing cell resource. Adobe XD for low and high fidelity prototypes, with a preview link for the client. Homologation builds shipped at every step forward. Testing the client endpoints with a request collection, to separate app errors from service errors. Prototype validation meetings with the client's business team.
Did you inherit an app from another vendor?
Inherited code usually arrives with no documentation, no history and no guarantee that it builds. In those cases the first delivery of value is an honest diagnosis of what is there. X-Apps takes on the base, unblocks the build and says what it found.