PHObject.localIdentifier reliability

Question

Created 1d

Replies 3

Boosts 1

Participants 2

This post is from the WWDC26 Photos & Camera Q&A.

For a PHAsset in the same Photos library on the same device/Mac, what are the documented stability guarantees of PHObject.localIdentifier? Is it safe to persist and use for future PhotoKit operations in that same local library? Are there known cases where it can change or stop resolving?

If a persisted localIdentifier no longer resolves but a persisted PHCloudIdentifier.archivalStringValue does resolve in the same library, is updating the stored local identifier from that cloud mapping the recommended recovery path?

Thanks!

Answered by Engineer in 892523022

The PHObject.localIdentifier should not be considered for long-term persistence. These identifiers can change in the photo library under certain conditions.

PHCloudIdentifier is the only type that is guaranteed to be consistent through all scenarios and one you should use if you wish to persist asset identifiers.

If you need to maintain the localIdentifier, then you would effectively need to maintain the pair of identifiers and refer back to the PHCloudIdentifier when the PHObject.localIdentifier is no longer valid.

See the snippet example in https://developer.apple.com/documentation/photos/phcloudidentifier on how to handle missing localIdentifiers.

Answer 1

Engineer OP

Apple

1d

Recommended

The PHObject.localIdentifier should not be considered for long-term persistence. These identifiers can change in the photo library under certain conditions.

PHCloudIdentifier is the only type that is guaranteed to be consistent through all scenarios and one you should use if you wish to persist asset identifiers.

If you need to maintain the localIdentifier, then you would effectively need to maintain the pair of identifiers and refer back to the PHCloudIdentifier when the PHObject.localIdentifier is no longer valid.

See the snippet example in https://developer.apple.com/documentation/photos/phcloudidentifier on how to handle missing localIdentifiers.

Answer 2

Zapsurfer OP

1d

Thanks

To make sure I implement your recommendation correctly: my plan is to persist both identifiers, use PHObject.localIdentifier as the current-library operational identifier for normal PhotoKit interactions, and keep PHCloudIdentifier.archivalStringValue as the durable recovery identifier. If the stored localIdentifier stops resolving, I would map the stored PHCloudIdentifier back to a current localIdentifier, update my stored localIdentifier, and continue using that for local PhotoKit operations.

Does that match the intended use of the identifier pair?

For a visible PHAsset in the current library, should cloudIdentifierMappings(forLocalIdentifiers:) always be expected to produce a PHCloudIdentifier? If it can fail, are there known non-deletion cases I should handle besides the asset no longer existing/resolving? In that situation, should the app still track the asset by localIdentifier and retry cloud identifier mapping later, or should the asset be excluded because it cannot be given a durable PHCloudIdentifier?

Answer 3

Engineer OP

Apple

1d

Accepted Answer

Yes, that is correct. The PHCloudIdentifier should be used sparingly as it is a costly conversion to obtain the localIdentifier. However it is the only identifier that is guaranteed to be durable, so consider it as a backup to the localIdentifier, should the conditions of the library change and the localIdentifiers are no longer valid.

Deleted PHAssets are likely the only scenario that you would encounter an error in the conversion from localIdentifier to cloudIdentifier