Allow applications to handle CloudKit zone purges before local deletion #551

Description

Could SyncEngine expose an application policy/delegate hook before deleting local records in response to a CloudKit zone purge?

In ReceiptGenie, the local receipt library is durable user data. If a user removes the app's cloud data to free iCloud storage, we would like to preserve their local library and pause cloud synchronization, then let them explicitly choose whether to resume/re-upload or delete their local data. We do not want to silently recreate the cloud contents against the user's intent either.

This is a source-based behavior/API report, not a claim that SQLiteData caused a confirmed customer incident. We are getting reports from production customers about missing local records and investigating, but do not have the customer's CloudKit event history or a confirmed triggering action.

Current behavior in the source

In SyncEngine.swift at 1.12.0, handleFetchedDatabaseChanges handles .deleted and .purged together by deleting local rows associated with the zone through SyncMetadata. It then schedules recreation of the default zone. .encryptedDataReset instead takes the upload path.

I found the same policy in 1.6.1. Account changes already have an application delegate hook, but I could not find an equivalent interception point for zone purges.

The existing FetchedDatabaseChangesTests document local deletion after zone deletion and preservation after encrypted-data reset. I inspected these tests; I have not run a real iCloud-storage-purge reproduction or the upstream test suite for this report.

Requested behavior / questions

• Is propagating a .purged zone event into local row deletion the intended product contract?
• Is there a supported way to preserve the local library and pause synchronization on that event today?
• Would you consider a reason-aware delegate/policy hook before local deletion, allowing an app to choose its recovery flow while preserving the existing default for other apps?

The request concerns the app's private database zone. It is not a proposal to ignore ordinary receipt deletion on another device or retain access to revoked shared records. Account switching also needs its own isolation policy so one account's data is never uploaded to another.

Reproduction status / versions

Source inspected: SQLiteData 1.6.1 and 1.12.0. No standalone runtime reproducer yet; customer app version and triggering event remain unknown. This report is deliberately scoped to the identifiable source behavior and the missing application policy hook. Happy for this to be moved to Discussions if that is the preferred venue.