Recovering a critical mobile workflow and changing how the company built and supported apps
A rebuilt production application took roughly 10 seconds to open an important record on a current iPad and 30 seconds or longer on older Fire-class tablets in the observed test contexts.
This story comes from Chris Martinez’s prior professional experience. Performance figures are approximate before-and-after test observations; they are not presented as client-attributed or client-endorsed results.
The decision
Repair the request, state, and rendering path; validate it across controlled accounts; then convert the evidence into architecture and device-support standards.
Observed result
Our before-and-after testing observed the current-iPad workflow improve from roughly 10 seconds to under one second. The company later reused the resulting architecture and support standards across its mobile applications.
The decision, visualized
≈10s → <1s in the observed iPad test
Controlled-account comparisons connected request and state changes to a faster critical workflow, then to durable architecture and device-support standards.
The production problem
The product supported healthcare field work across tablets and phones, including offline behavior and synchronized records. From the main screen, a user selected a record and opened its general information and progress. That workflow could take roughly 10 seconds on the iOS simulator and current iPad used in testing, while users of older Fire-class Android tablets reported waits of 30 seconds or longer.
This was not a cold-start or login measurement. It was a device-sensitive delay inside an already released product, and it affected the point at which a professional needed the record to become usable.
What the code and network behavior showed
The inherited React Native implementation used web-oriented patterns that did not account for the CPU, GPU, and lifecycle constraints of the actual mobile-device range. Some useEffect paths fired the same HTTP requests roughly two to ten times. Responses containing information the app had just received were then written into Redux again, producing state and interface work that did not help the user.
The visible delay was therefore not one slow endpoint or proof that React Native itself was too slow. Request behavior, state handling, rendering order, and constrained hardware were multiplying one another.
The implementation
Chris changed the screen so its usable structure could appear without waiting for every dependent region. Individual sections displayed appropriate loading states and became ready as their information arrived.
He then introduced change-aware checks before writing returned information into Redux. When the meaningful data had not changed, the application skipped the redundant state update and resulting render instead of repeating the same work.
What our testing observed
QA compared the old and revised builds using the same accounts, then repeated the checks with additional accounts. In those observed test contexts, progressive loading first reduced the current-iPad wait from roughly 10 seconds to roughly 5 seconds. The additional request and state changes brought it below one second.
On the older Fire-class devices available to stakeholders, the reported wait improved from 30 seconds or longer to approximately 8–12 seconds. Those devices remained materially slower, but the comparison helped separate an application problem the team could repair from a hardware-support promise it could not sustain. All figures are approximate observations from this anonymized prior-professional engagement.
A contract-aligned architecture standard
The recovery did not end with a patch. Chris documented a screen-architecture standard and led the team discussion that introduced it. Before implementing a new screen, the team reconciled the intended workflow and visual design with the API data, loading states, error and empty states, display behavior, and navigation the product had to support.
That standard reduced the need to build a visual screen first and then add conditional workarounds around an incompatible data contract. The team reused the documented approach when it built additional mobile applications, and later launches were experienced as more successful than the first. No release-rate or defect metric is claimed here.
A company-wide device-support decision
The technical recovery exposed a second operating problem: a very small Fire-class device segment produced a disproportionate share of device-related tickets created by customer support. The team could trace callers and reported problems to device types; newer iOS hardware and higher-end Android devices were not producing the same concentration of slowness reports.
Chris recommended a current-major-version-plus-two support window and a published list of internally tested devices. The company adopted the approach across its mobile applications, ended Fire-class support, and warned that unlisted hardware might receive limited support or a reduced experience. Customer support could give customers a clear upgrade path, while product, development, and QA spent less time moving device-specific issues between teams and more time on broader defects, features, and technical debt.
Why the story matters
The valuable outcome was not simply a faster screen. Hands-on diagnosis led to a code change, a controlled validation method, a documented architecture pattern, and a company-wide product-support policy. That is the difference between treating a symptom and improving the system that produced it.