Fix FindMy folder permission not surviving a relaunch

[gheydon]

Related: #11 — though see the note at the end, this is probably a different bug from the one reported there.

The problem

Picking the FindMy folder grants access for exactly one sync, then loses it. The practical result is that Full Disk Access ends up being the only thing that works — a far broader grant than the app needs, since it reads nothing but the FindMy data.

Two causes

The bookmark was never stored. In AppView.swift:

@AppStorage("bookmarkData") var findmyBookmark =
    try url.bookmarkData(options: .minimalBookmark, ...)

@AppStorage declared as a local variable inside the importer callback does not write to UserDefaults — the assigned value becomes the property wrapper's default. The variable is then unused. Nothing is persisted.

Nothing ever resolved a bookmark. There is no URL(resolvingBookmarkData:) anywhere in the codebase, so even had one been saved, no launch path could restore access.

Why it looks like it works

The picker opens the security scope, the sync that runs immediately afterwards succeeds, and then defer { url.stopAccessingSecurityScopedResource() } closes it when the callback returns. Every later timer-driven sync then fails against a folder the app can no longer read. Access appears to work and quietly stops.

The fix

A small DataAccess type that:

• writes a security-scoped bookmark (.withSecurityScope, rather than .minimalBookmark, which does not preserve scope)
• resolves it at launch, before the first read
• refreshes it when the bookmark goes stale
• holds the scope for the lifetime of the process instead of releasing it via defer

The importer callback — previously duplicated verbatim across the two availability branches — now calls a single onDirectoryPicked handler.

Testing

• Builds clean, no new warnings.
• Bookmark round-trip verified across genuinely separate processes: granting writes an 824-byte bookmark, a fresh process resolves it and reads through the restored scope, and repeated restores work.

What I could not verify: that this removes the need for Full Disk Access on the real FindMy directories. My test machine runs macOS 26, where ~/Library/com.apple.icloud.searchpartyd does not exist, and the test process inherited Full Disk Access anyway — so a successful read there would prove nothing about TCC. What is definitely fixed is the persistence bug, which was unambiguously broken. Whether a bookmark alone suffices for those directories deserves a second opinion from someone able to test it.

On #11

I am referencing that issue as related context rather than claiming to close it. The symptom reported there is that the permission dialog never appears and Full Disk Access does not help, which is a different failure from the one fixed here. What this PR does address is the reason people end up on Full Disk Access in the first place — the narrower folder grant not surviving.

🤖 Generated with Claude Code