Making offline clinical work reliable

Product context and challenge

Swift Medical’s clinical Android application supported offline document creation and image capture. I later joined the team supporting its production Flutter application, working on native Android and iOS capabilities.

Failed synchronization was the main customer complaint. Pending work was coupled to WorkManager’s internal state, and out-of-order operations were rejected by the backend. Some documents remained on devices for months. Long sessions also exposed memory leaks and expensive bitmap and encryption work.

My scope and ownership

• Introduced an application-owned database queue and separated connectivity policy from WorkManager scheduling.
• Piloted Coroutines in a low-priority synchronization area, compared memory and CPU behavior, then extended the migration.
• Profiled document creation and prioritized frequently used flows for a staged migration from RxJava and MVP to Coroutines and MVVM.
• Led the replacement of Mixpanel with an internal analytics library and monitored its staged production rollout.
• Supported native camera plugins and FHIR data structures in the Flutter product; enabled SwiftVision on ARM64 iOS simulators and migrated native dependencies for 16 KB pages.

Decisions and trade-offs

• The product needed to own synchronization state and ordering. WorkManager remained responsible for scheduling execution, while the application database held pending domain operations.
• A measured pilot established whether Coroutines improved the existing thread-heavy implementation before extending the change. Frequently used flows took priority over a wholesale rewrite.
• Clean Architecture made replacing analytics practical, but production behavior still determined rollout readiness. I stopped the first limited rollout when results were unacceptable, iterated on the library, and released again.

Quality, validation, and delivery

• Used CPU and Memory Profilers, allocation and leak analysis, and Perfetto to investigate long-session failures and blocked threads.
• Compared resource use before expanding the synchronization migration and monitored adoption and performance during analytics rollout.
• Compiled OpenCV and TensorFlow dependencies for ARM64 iOS simulators and validated SwiftVision with the computer-vision team before its production release.

Outcomes

• Documents that had been waiting on customer devices for months successfully synchronized.
• The application gained explicit synchronization queue ownership and better processing observability.
• SwiftVision shipped with ARM64 iOS Simulator support, and native-library support for 16 KB pages was delivered by the required deadline.

Supporting technologies