QA for a Property Inspection App: Offline, Photos and Sync

A property inspection app earns trust on one scenario: an inspector in an empty flat with no signal, filling in a report and taking forty photos, who expects all of it to survive the walk back into coverage. Test offline capture, photo integrity, sync conflicts and GPS on real devices, because that is where work is lost. RAITHub tests mobile apps on iOS and Android; it does not build them.

If you would rather have it tested for you, see how RAITHub would test this below. It pairs with the wider PropTech app testing before launch and the general pre-launch QA checklist.

Why is an inspection app harder to test than a normal app?

Because the hard cases are the normal cases. Inspections happen in basements, lifts and vacant units where signal is poor or absent, so the app has to work fully offline and sync later without losing anything. It captures lots of photos, often large, on devices that may be low on storage or battery. And two people, or the same person on two devices, can touch the same report, creating sync conflicts. A booking platform's worst bug is double-booking under concurrency (short-let booking platform QA); an inspection app's worst bug is lost or corrupted field work.

How do you test offline capture?

On a real device with the network genuinely off, not a simulator with a flag flipped. Fill in a full inspection, add photos and notes, then confirm everything is held locally and nothing requires a round-trip to save.

Case	What to assert
Complete an inspection fully offline	Every field, photo and note is saved on-device
Force-close the app offline, reopen	The in-progress inspection is still there, intact
Device restarts (battery dies) offline	No data loss after reboot
Fill the device storage mid-inspection	A clear warning, not a silent failure or crash
Airplane mode on and off repeatedly	No partial saves, no duplicate records

How do you test photos on an inspection app?

Photos are the most common place work is silently lost. Test that each photo is stored at full quality until it has uploaded, that orientation (EXIF) is correct so a photo isn't sideways, that a photo stays attached to the right room or item, and that a half-finished upload resumes rather than corrupting. Test large photos and many photos (an inspection can have dozens), and test that deleting a photo removes it everywhere, not just from the view.

• Integrity: the uploaded photo matches the captured one, byte for byte where expected.
• Association: each photo stays linked to its item after sync, not reassigned or orphaned.
• Interrupted upload: killing the app mid-upload resumes cleanly; no duplicate and no half-image.
• Orientation and metadata: EXIF rotation respected; timestamps and, if used, location preserved.
• Storage pressure: low-storage devices warn before capture fails.

How do you test sync and conflicts?

The dangerous moment is coming back online. Test that a queued offline inspection syncs exactly once, not twice if the request is retried, and that the server's response is applied correctly. Then test genuine conflicts: the same report edited on two devices, or by two people, before either synced. Decide and verify the resolution rule, last-write-wins, merge, or flag-for-review, and make sure the rule is applied consistently and never silently discards an inspector's work.

// A conflict scenario, exercised against the app's sync API.
// 1. Device A and Device B both pull report R at version 1 (offline).
// 2. A edits the kitchen notes; B edits the bathroom notes.
// 3. Both come online and sync.
// Expect: both edits survive (merge), OR the loser is preserved and flagged.
//         NEVER: one device's whole inspection silently overwritten.
test('concurrent edits to one report do not lose work', async () => {
  const r = await seedReport({ version: 1 })
  await syncEdit('deviceA', r.id, { kitchenNotes: 'cracked tile' })
  await syncEdit('deviceB', r.id, { bathroomNotes: 'leak under sink' })

  const merged = await fetchReport(r.id)
  expect(merged.kitchenNotes).toBe('cracked tile')
  expect(merged.bathroomNotes).toBe('leak under sink') // neither edit lost
})

Also test sync idempotency directly: replaying the same queued change must not create a duplicate inspection, the same exactly-once concern as any webhook (testing payments and webhooks end to end).

How do you test GPS and device-specific behaviour?

If the app stamps inspections with location, test that permission denial is handled gracefully (an inspection without GPS still saves), that a poor fix is flagged rather than recorded as precise, and that the location is captured at the right moment. Then test across real devices: a range of iOS and Android versions, small and large screens, and the permission prompts each platform shows. Device fragmentation is exactly why this testing runs on real devices and device clouds, not one phone on a desk.

Buy, build or hire this testing?

Option	What you get	Choose this when
Your team tests it	Developers check their own work	You have QA skill and real devices, and offline testing discipline
A device-farm tool	Automated runs across many devices	You can write and maintain the mobile test scripts yourself
A pre-launch mobile QA audit	A tester works the offline, photo and sync edges on real devices and hands you a ranked bug report	You are about to launch and lost field work is unacceptable
A monthly QA plan	Mobile regression testing each release	The app keeps changing and offline and sync must stay solid

How RAITHub would test this

• Scope: offline capture, photo integrity and association, sync and conflict resolution, GPS and permissions, and coverage across real iOS and Android devices and screen sizes.
• Timeline: a fixed-scope pre-launch mobile audit is a one-off checkpoint; ongoing coverage runs as a monthly QA plan.
• What you receive: a ranked bug report with device, OS version and reproduction steps for each issue, and a clear split of what to fix before launch.
• Ways to buy it: a one-off pre-launch mobile QA audit or a monthly QA plan. RAITHub tests the app; your team (or another vendor) builds and fixes it.
• Next step: a free 15-minute technical audit, then a fixed written quote.

See the mobile app testing service, the QA as a Service hub, or book the free 15-minute audit. The wider real-estate context is on the real-estate industry page. RAITHub tests mobile apps and does not build them.

Documentation checked on 10 October 2026.

Frequently asked questions

Does RAITHub build property inspection apps?

No. RAITHub tests mobile apps, on iOS and Android, on real devices and device clouds, but it does not develop native mobile apps. This is a test plan for an inspection app your own team or another vendor built; RAITHub tests it and reports the bugs with reproduction steps.

Why does an inspection app need offline testing?

Because inspections happen in basements, lifts and vacant units where there is little or no signal, so the app must work fully offline and sync later. If offline capture or sync is weak, an inspector can lose a whole report and dozens of photos, which is the failure the testing is built to catch.

How do you test photos so none are lost?

Check that each photo is stored at full quality until it uploads, keeps its orientation and metadata, stays attached to the right item after sync, and resumes cleanly if an upload is interrupted. Test many and large photos on low-storage devices, where capture is most likely to fail silently.

How do you test sync conflicts?

Edit the same report on two devices before either syncs, bring both online, and verify the resolution rule, merge, last-write-wins or flag-for-review, is applied consistently and never silently discards work. Also replay a queued change to confirm sync is idempotent and does not create duplicate inspections.

Can you test on the specific devices our inspectors use?

Yes. Testing runs on real iOS and Android devices and device clouds, across the OS versions and screen sizes your inspectors actually carry, because offline, photo and permission behaviour differs between devices and a single phone on a desk will not reveal it.