Understanding Offline Functionality
Mobile apps must work when network is unavailable. Offline mode is not just about showing cached data — it involves data synchronization, conflict resolution, and maintaining a seamless user experience across connectivity states.
Types of Offline Support
| Level | Description | Example |
|---|---|---|
| No offline | App is unusable without network | Streaming-only apps |
| Read-only cache | Previously loaded data viewable | News apps, social feeds |
| Queue actions | Actions queued, executed on reconnection | Email compose, message draft |
| Full offline | Full functionality, sync later | Note-taking apps, maps |
Data Synchronization Patterns
Last-Write-Wins
The most recent change overwrites previous ones. Simple but can cause data loss.
Conflict Resolution
When two users edit the same record offline, the app must resolve conflicts:
- Automatic merge: Non-conflicting changes are merged (like git)
- User choice: Present both versions and let the user choose
- Server wins: Server version always takes precedence
- Client wins: Local version always takes precedence
Testing Offline Mode
Test Flow
1. Load app with network → verify data appears
2. Enable airplane mode
3. Navigate through the app → verify cached data shows
4. Perform actions (create, edit, delete)
5. Disable airplane mode
6. Verify all queued actions sync correctly
7. Verify no data loss or duplication
Essential Test Scenarios
Data persistence:
- App shows cached data when opened offline
- New data created offline is preserved after app restart
- Edited data offline is preserved after app restart
- Deleted items offline are correctly synced when online
Sync behavior:
- Queued actions execute in correct order on reconnection
- Sync progress indicator shown during synchronization
- Failed sync items are retried with clear error feedback
- Sync does not duplicate data (idempotency)
Conflict scenarios:
- Same record edited on two devices — conflict resolved correctly
- Record deleted on one device, edited on another — handled gracefully
- Large amount of offline data syncs without timeout
Advanced Sync Testing
Testing Sync Conflicts
Create conflict scenarios deliberately:
- Open the app on Device A and Device B
- Put both devices in airplane mode
- Edit the same record differently on each device
- Bring Device A online, wait for sync
- Bring Device B online, observe conflict resolution
Exercise: Offline Testing Plan
Scenario: You are testing a project management app with tasks, comments, and file attachments. Design an offline test plan.
Solution
Read-only offline:
- Load project with tasks → airplane mode → verify all tasks visible
- Open task with comments → airplane mode → verify comments cached
- Navigate between projects → verify only previously loaded projects available
Create offline:
- Create new task offline → verify saved locally → go online → verify synced
- Add comment offline → verify visible locally → go online → verify synced
- Create task with attachment offline → verify attachment queued → sync when online
Conflict resolution:
- Edit task title on Device A offline, edit same task on Device B offline → both come online → verify resolution
- Delete task on Device A, add comment to same task on Device B → verify handled
- Assign task to user A offline, assign to user B on other device → verify winner
Edge cases:
- 1000+ offline changes → verify bulk sync completes without timeout
- Create → edit → delete same task offline → verify only deletion syncs
- App killed while syncing → verify resume on next launch
Pro Tips
Tip 1: Test sync after long offline periods (24+ hours). Token expiry and large data deltas create edge cases.
Tip 2: Kill the app during sync to test crash recovery. Partial sync states are a common source of data corruption.
Key Takeaways
- Offline support ranges from simple caching to full offline CRUD with conflict resolution
- Test the complete cycle: load data → go offline → perform actions → come online → verify sync
- Conflict resolution must be tested with multiple devices editing the same data
- Sync must be idempotent — repeated sync should not duplicate data