YEAR
2026
INDUSTRY
Health, Government, Tech
SERVICES
React Native App Development, ATDD Methodology, AI-Accelerated Development, Design & Architecture
TL;DR
How Adapptor helped iLA upgrade their aging apps from iOS and Android to a single cross-platform codebase with an AI-assisted approach, without sacrificing quality and within budget.
Independent Living Australia exists to empower people to live and age well. Central to that mission is the network of support workers who deliver care in homes, the community, and facilities across Australia.
A tool critical to that mission is the app, Keep Able On The Go. It runs on Android and iOS, and provides a library of curated clinical content, including videos, audio, podcasts, articles, and resources that enable workers to do their jobs in the field.
While Keep Able had served its users well, the need to maintain two separate native codebases was becoming increasingly inefficient. Every feature needed to be built twice, every bug fixed twice. Every release was double the effort. For iLA, this wasn’t just a development overhead, it was a ceiling on how fast they could respond to the needs of clients who rely on Keep Able every day.
This was unsustainable, but the typical development effort required to consolidate two native apps into a single cross-platform codebase was going to limit the extent of improvements iLA could bring to their users.
Enter Adapptor. We understood the goal: rewrite Keep Able with a single React Native codebase and reskin the UI, while keeping the existing backend dependencies and feature parity. To achieve this within budget and without sacrificing quality, we suggested a flavour of AI agentic development called Acceptance Test Driven Development, or ATDD.
ATDD is the brainchild of Robert “Uncle Bob” C Martin, a legend of the software industry and co-author of the influential Agile Manifesto. It recognises the power of AI coding agents while addressing their key weakness, a tendency to lose sight of the goal provided by the developer.
ATDD addresses this drift by defining upfront executable requirements that act as guardrails for the agents. Requirements are expressed in the well known Gherkin ‘Given/When/Then’ form.
SCENARIO / SUCCESSFUL LOGIN WITH VALID CREDENTIALS
Given a registered user with email “alice@example.com” and password “SecurePass123”
When the user submits the login form with those credentials
Then the user is authenticated
And the user is redirected to the dashboard
And a welcome message “Welcome, Alice” is displayed
Once the requirements are created, the project team guards them ‘ferociously’. But at a finer level, AI agents create and curate unit tests in support of the requirements, and continually check quality indicators and perform remedial tasks such as refactoring when necessary.
In the case of Keep Able, the existing iOS and Android apps already embodied the requirements, given the initial target was a feature-parity rewrite. So AI was able to extract the initial set of requirements from the two codebases, and these initial requirements were reviewed and edited by stakeholders. This also served as the shared source of truth between the Adapptor team and iLA throughout the engagement.
Before letting the agents loose on these requirements, a foundation was laid in the form of the Architectural Guide. This established: a folder structure, state management rules, code style conventions, domain language, and specific technical library choices. This informed the agents about our preferred way to apportion responsibility for the data-fetching logic, shared app state, and local UI state.
The ATDD pipeline was custom-built for the project. The requirements in the form of Gherkin specs were in the specs/ folder to be parsed by a project-local pipeline that generates acceptance tests to be committed alongside the source code. Acceptance tests were connected by step bindings on the exact text of the specs to code that implements the requirement. This transformed the specs from mere documentation to a development contract. A feature was only handed over for manual testing when both its acceptance tests and unit tests were green.
DAVE FARLEY / SOFTWARE ENGINEER AND AUTHOR
The rewrite brought the iOS and Android apps into a single React Native application while retaining Keep Able’s established features. The app is organised around four main destinations: Resources, Search, Saved and Settings.
Resources
A catalogue that can be filtered by category and content type, together with recently viewed items.
Search
Text and voice search across videos, podcasts, audio, articles and downloadable files, with an AI-generated answer when five or more results are found.
Saved
Registered users can save content, download it to the device, and schedule alerts for later use in the field.
Settings
Account, preferences and connected behaviours stay clear and predictable whether the device is online or offline.
One crucial requirement was offline use. Keep Able must continue to function in the field when internet access is intermittent or unavailable. When a registered user saves an item, it is downloaded to the device and added to the Saved library. While offline, the user sees only the items present on that device and can open and play them without contacting the server.
Saved videos and audio use their local copies rather than streaming, and saved articles and images remain available through the same library. Offline behaviour also extends beyond the content itself. Alerts on saved items are scheduled locally and can be set without a connection. Content views are recorded on the device while offline and reflected in the user’s account history when connectivity returns.
Resources refresh automatically after reconnection, while saved content is updated when a newer version becomes available. Local data is preserved when the same person signs in again and removed when a different account is used on the device.
The specifications also define where connectivity is still required. Users cannot save new content, remove saved items across their devices or stream unsaved media while offline. Similar-content recommendations are unavailable until the connection returns. In each case, the app informs the user that the action requires internet access rather than allowing it to fail without explanation.
These connected behaviours made offline support a substantial part of the rewrite. Each one was captured as a Given/When/Then scenario and converted by the project’s ATDD pipeline into an executable acceptance test. This gave the AI-assisted development process precise, testable outcomes for offline storage, playback, reconnection and synchronisation.
Search also includes an AI-generated answer when a query returns at least five matching resources. The answer is presented alongside the catalogue results, begins in a brief form and can be expanded or collapsed by the user. It is accompanied by a disclaimer that it may contain AI-generated information. This feature serves as a conversational entry point into the clinical content library, helpful when users aren’t sure what to search for. When fewer than five results are found, the app shows the matching resources without generating an answer.
iLA now ships one app instead of two. That means faster releases, lower maintenance cost, and one source of truth. Feature parity is locked in by executable specifications, which double as living documentation that will grow as the app does. Every core behaviour — search, offline storage, local alerts, reconnection sync, AI-assisted answers — is guarded by executable acceptance tests that travel with the code.
For Adapptor the engagement proved again that AI accelerates development the most when it is constrained by precise, testable requirements. Momentum with rigour produces a codebase the client can own, maintain and grow with confidence.
For the support workers who rely on Keep Able in homes, community settings and facilities across Australia, the experience is consistent across iOS and Android, offline and online.
