pettiDebug local app data with SQLite snapshots
A save button appears to work, but reopening the screen shows the old value. Use the database to distinguish a failed write from a stale interface.
Start with the right file
Find the database actually used by the development build. Different simulator installations, environments and working directories may hold files with the same name. Confirm a recognizable test record in Petti before making conclusions. The iOS Simulator guide and Django guide cover locating common development stores.
Capture one reproducible action
- Open the database read-only, leaving its WAL companions in place.
- Capture a baseline with What Changed?.
- Perform one action in your application and let its transaction commit.
- Compare with the current database and inspect the relevant row’s old and new values.
- Repeat with a new baseline if you need to isolate a second action.
Turn the difference into a diagnosis
If the committed value changed but the screen did not, investigate application caching or display logic. If no relevant change appears, first check whether the table was actually compared, whether the write committed and whether you opened the correct file. A comparison alone does not prove which process wrote a value.
Record the app build, reproduction steps, source path and relevant row identity with the result. Use a small synthetic fixture when sharing a bug report. Petti snapshots stay local and contain the underlying data; choose what to share deliberately.
Respect the application’s storage rules
Use the app’s own API to change framework-managed stores. Core Data’s internal SQLite schema is not a supported editing interface. Petti’s read-only inspection does not turn internal tables into a stable contract. For a custom SQLite store, a disposable development copy is the simplest place to test a hypothesis.
Practice the complete before-and-after workflow with a fictional order. If the value is JSON, continue with cell preview and field extraction.
Updated