Common Data Loss in Insurance Apps: Causes and Fixes

1. Automated UI exploration – Run SUSATest against the app with the *curious* and *novice* personas; look for “unsaved state” alerts or missing screenshots after navigation.

What CausesData Loss in Insurance Apps

Technical Root Causes

• In‑memory state not persisted – UI actions (e.g., entering a policy number) are stored only in RAM; a process kill or configuration change wipes the data.
• Improper handling of lifecycle events – Android’s onSaveInstanceState or iOS’s AppDelegate notifications are missed, so draft claims disappear when the app goes to background.
• Network‑reliant save flows – Submitting a claim relies on a successful POST to the backend; if the request fails or times out, the locally cached draft is discarded without user confirmation. - Unreliable offline‑first architectures – When sync is interrupted, conflict resolution may drop user‑entered fields instead of merging them.
• UI component recycling bugs – Re‑using list items or tabs can retain stale values, causing previously entered data to be overwritten silently.
• Third‑party SDK crashes – Analytics or payment SDKs may abort mid‑transaction, leaving intermediate data in an inconsistent state.

Real‑World Impact

• User complaints – “My claim draft vanished after I got a call” appears in 12 % of App Store reviews for major insurers.
• Store ratings – Apps with frequent data loss see average star drops of 0.8 points within three months of launch.
• Revenue loss – Abandoned claim submissions translate to an estimated $3.2 M annual revenue hit for a mid‑size carrier (based on conversion rate from quote to policy).
• Regulatory exposure – Missing audit trails for policy changes can trigger compliance warnings from state insurance departments.

How Data Loss Manifests (Specific Examples)

Detecting Data Loss

1. Automated UI exploration – Run SUSATest against the app with the *curious* and *novice* personas; look for “unsaved state” alerts or missing screenshots after navigation.
2. Crash‑session replay – Capture the full view hierarchy before a crash; verify that any text fields containing user input are still present in the saved state bundle. 3. Network‑failure simulation – Use tools like Charles Proxy to drop responses on claim‑submission endpoints; confirm that drafts are persisted locally instead of being cleared.
3. Lifecycle stress testing – Rotate, split‑screen, and background the app 100 times in a row; assert that all entered values survive each transition.
4. Log‑based validation – Emit debug logs whenever onSaveInstanceState or equivalent is called; downstream dashboards should flag missing calls for high‑traffic screens.
5. Accessibility audit – Enable TalkBack/VoiceOver and navigate the claim flow; a sudden loss of entered text is a red flag.

Fixing Each Manifestation ### 1. Claim Draft Lost on Crash

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString("damageDesc", damageEditText.text.toString())
    outState.putParcelableArrayList<Photo>("photos", photoList)
}

• Ensure every editable field is saved into the bundle.
• Restore values in onCreate when savedInstanceState is non‑null.

2. Policy Selection Reset After Orientation Change

• Switch to a ViewModel that holds UI state across configuration changes.
• Bind the dropdown to viewModel.selectedCoverage instead of directly to the activity’s field.

3. Premium Calculation Aborted Mid‑Quote

• Decouple UI from network response: keep a local provisional premium while awaiting the server.
• Show a “Saving…” indicator and persist the provisional value to SharedPreferences before the response arrives. ### 4. Claim Photo Disappears on Background
• Store attachments in internal storage immediately after capture (getFilesDir()/claim_photos).
• Load thumbnails from that directory on resume; do not rely on UI component state.

5. Saved Policy Documents Deleted on Logout

• Separate temporary cache from persistent vault.
• Use androidx.work to move files to a policy_documents directory that survives process death. ### 6. Mis‑aligned Data Binding in Wizard
• Replace findViewById lookups with Data Binding Library expressions that are bound to a central wizardState object.
• Validate each step before moving forward; clear only the current step’s fields, not the entire wizard model.

7. Sync Conflict Drops User Notes

• Implement Operational Transformation (OT) or CRDT logic for note fields.
• Keep a local copy of notes in a SQLite DB; on sync, merge remote changes with a “last‑write‑wins” rule that preserves the most recent user edit timestamp.

Prevention: Catching Data Loss Before Release

• CI gate: Run a nightly SUSATest suite that includes a *data‑loss regression* profile. The suite must verify that after each of the 10 personas completes a claim flow, the final screen shows a “Draft saved” banner. - Schema validation: Add JSON schema checks for all request bodies; if a required field is missing, reject the request and surface a “Missing data” error instead of silently discarding it.
• Feature toggles: Wrap persistence logic behind a feature flag; enable it in staging builds and monitor crash analytics for onSaveInstanceState omissions.
• Code review checklist:

1. Is every mutable UI field added to savedInstanceState or a ViewModel?
2. Are network failures caught and logged before clearing local caches?
3. Does the app write to disk before returning to the UI thread?

• Canary monitoring: Deploy to a small user cohort and instrument onTrimMemory events; spikes in “state restoration failed” logs indicate imminent data loss. By treating data persistence as a first‑class concern — embedding it in UI lifecycles, synchronizing network interactions, and validating state across device transitions — insurance apps can eliminate the silent loss that drives user churn and regulatory risk. The combination of automated exploration (e.g., SUSATest) and disciplined state management ensures that a policy holder’s confidential data never disappears mid‑transaction.