GPSi - Field auditing in your pocket
An iOS checklist and inspection app for Grupo GPS field teams, built from scratch out of an Android app with no source code and no documentation.
Bringing field auditing to the iPhone
Grupo GPS runs one of the largest facilities operations in Brazil, with teams spread across large client contracts. GPSi is the tool those teams use to record what is actually happening on site: the supervisor scans a QR Code in the room, the app opens the checklist for that point, and leadership sees service quality without waiting for paper or for a spreadsheet sent later.
An Android version already existed and was in use, maintained by the client's own team. iOS was missing, and iOS was what leadership carried in their pocket.
The challenge
X-Apps took on the project without the two things that normally support a port to another platform.
- There was no source code for the Android app, and no documentation for the API it consumed. Android kept evolving while iOS was being built, with changes that showed up unannounced. Checklist business rules lived in system configuration, differed between areas and, in places, did not match what Android actually did. * The client API returned the same field sometimes as a number and sometimes as text, and some calls did not work on Android either.
Reverse engineering as a method, not a shortcut
With no source and no documentation, the only reliable description of the system was the Android app itself, running. That is where the specification came from.
The team installed the APK on an emulator, put a proxy between the app and the server, and worked through the system feature by feature, recording every call. Endpoints, response shapes and the data model came out of that traffic. Every iOS screen was built against an observed contract, not an assumed one.
It was an expensive method and it was treated as such: mapping a single feature cost around three hours of observation before a line of code. In return, iOS shipped with API documentation that had not existed before, and that stayed with the client.
When checklist rules turned out to contradict each other, the answer was the same: a technical call with the client and a document settling what actually applied, area by area.
A form that changes shape
The heart of GPSi is the checklist, and it is never the same one. Each area of the operation asks different things in different ways, and those differences change over time.
The decision was not to code one screen per area. The form is assembled at runtime from the configuration the server returns, and a single component serves the whole operation. Differences between areas became configuration, not code.
The form accepts the answer types a field inspection really needs:
- text, number, single and multiple choice; a photo taken on the spot, attached to the inspected item; the supervisor's signature, captured on the screen itself; * non-conformity records with follow-up.
A request that arrived mid-project, showing more than one checklist per QR Code, made it in precisely because the structure was dynamic: the change applied to every scanning screen at once.
The whole operation, area by area
The app covers the fronts Grupo GPS audits in the field.
Organizational Resources. Planned and completed routes, checklist answers with photo upload, access to what was already submitted, and non-conformity follow-up.
Human Resources. Benefit tracking, with requests, details and comments, training records and submission, and non-conformity for benefits and absence.
Client Perception. Inspection checklist for the quality perceived by the contracting company, submitted on the spot.
Technology Resources. Checklist loading and submission, ticket opening and closing.
Safety and Health. Immediate workplace accident reports with photo, monthly inspection and inspection submission.
All of it running on local storage and synchronization, because the supervisor does not always have good signal at the point being inspected.
Stack and practices
- Native iOS in Swift, with Storyboards and auto layout tuned for different iPhone screens. Alamofire on the HTTP layer and RealmSwift as the local database, for synchronization. QR Code reading implemented without third party libraries, in an in-house component reused by every screen that needs to scan. In-app version update checking. Sprints tracked in Jira, version control in Bitbucket and an asynchronous daily wired into the project channel. * Test builds shipped to the client throughout the project, not only at the end.
The delivery
GPSi was published on the App Store in September 2018. The next day a version went up with the Android-inherited images reprocessed, which cut the package size in half, and with the synchronization timeout adjusted.
After release came the post-project phase, fixing the open points and monitoring the application daily through the warranty period. The source code was handed over to Grupo GPS and App Store ownership was transferred to the client's own account, which still maintains GPSi today.
Testimonial
"X-Apps answered us with excellence and agility for developing iOS applications, demonstrating know-how on other technologies and allowing us to make a partnership on new projects."
Milton Foti - Systems Manager, Grupo GPS
Have a system with no documentation to carry forward?
Inheriting a system with no source, no documentation and users depending on it is more common than it sounds, and it does not have to stall the product. X-Apps puts together the team that observes, documents and rebuilds, shipping testable builds from the start.