PHAssetCreationRequest merges new Burst Photos into "Recently Deleted" instead of Library

Question

Created 1w

Replies 5

Boosts 0

Participants 2

Description

I am observing a critical issue when saving burst photos using the Photos Framework. If a burst photo with the same burstIdentifier already exists in the "Recently Deleted" album, any new assets saved via PHAssetCreationRequest are automatically merged into that deleted entry instead of appearing in the main Library or "All Photos."

Environment

Framework: Photos Framework (iOS)
API: [[PHPhotoLibrary sharedPhotoLibrary] performChanges:...]

Code Snippet

The following logic is used to save the burst assets:

[[PHPhotoLibrary sharedPhotoLibrary] performChanges:^{
    // 'paths' is a custom object providing the creation request
    PHAssetCreationRequest *assetCreationRqst = [paths assetCreationRqst];
    assetCreationRqst.favorite = [FavorManager.shared isSetDownloadedAssetFavorite:self.curItem];
    
    PHObjectPlaceholder *placeHolder = assetCreationRqst.placeholderForCreatedAsset;
    localIdentifier = placeHolder.localIdentifier;
    
} completionHandler:^(BOOL success, NSError * _Nullable error) {
    if (success) {
        // The handler returns success, but the asset is invisible to the user
        [weakSelf handleDownloadSuccess:localIdentifier];
    }
    // ... cleanup and completion ...
}];

Steps to Reproduce

Save a burst photo to the iPhone's built-in Photos app.
Manually delete that burst photo so it moves to the "Recently Deleted" album.
Execute the code above to save the same burst photo (or a new set containing the same burstIdentifier in its metadata).
Check the main Photo Library / "All Photos" view.

Observed Result

The completionHandler returns success = YES, and a localIdentifier is generated.
The photo does not appear in the main Library or "All Photos."
The newly saved photo is silently merged into the existing burst set located inside the "Recently Deleted" folder.
The user cannot see the new photo unless they manually "Restore" the deleted items from the album.

Expected Behavior

PHAssetCreationRequest should always result in a visible asset in the user's Library. Even if a matching burstIdentifier exists in "Recently Deleted," the system should treat the new request as a new independent asset or provide an error, rather than hiding it within a deleted collection.

Answered by DTS Engineer in 877554022

Hello jimmy520,

The behavior you're describing is intentional. As per the documentation for burstIdentifier:

When the user takes a sequence of photos in burst mode with the Camera app (on supported devices), the Photos app user interface groups the resulting assets together. The Photos framework identifies a burst sequence as a group of assets sharing the same burst identifier string.

As such, attempts to save or import an image with a duplicate burstIdentifier will result in the image being sent to the same place as the rest of the group.

A workaround to the situation you're describing is to delete the original burst photo with the burstIdentifier from Recently Deleted. So when you either re-save it, or create a new photo with that identifier, it will be treated as the beginning of a new group.

Let me know if you'd like to know more,

Richard Yeh  Developer Technical Support

Boost

Answer 1

DTS Engineer OP

Apple

1w

Accepted Answer

Hello jimmy520,

The behavior you're describing is intentional. As per the documentation for burstIdentifier:

When the user takes a sequence of photos in burst mode with the Camera app (on supported devices), the Photos app user interface groups the resulting assets together. The Photos framework identifies a burst sequence as a group of assets sharing the same burst identifier string.

As such, attempts to save or import an image with a duplicate burstIdentifier will result in the image being sent to the same place as the rest of the group.

A workaround to the situation you're describing is to delete the original burst photo with the burstIdentifier from Recently Deleted. So when you either re-save it, or create a new photo with that identifier, it will be treated as the beginning of a new group.

Let me know if you'd like to know more,

Richard Yeh  Developer Technical Support

1

Answer 2

DTS Engineer OP

Apple

4d

Hello jimmy520,

Could you call fetchAssetsWithBurstIdentifier:options: to check if the burstIdentifier is present? See here.

Please note #5 from our forums tips:

When replying, use a reply rather than a comment. Comments are best reserved for short messages, like “Thanks!” or “See this other thread.”

IMPORTANT If you reply in the comments, other folks on the thread may not be notified of your reply.

0

Answer 3

jimmy520 OP

4d

Hi Richard,

Thank you for the guidance. I have tested fetchAssetsWithBurstIdentifier:options: as you suggested and confirmed that I can locate the assets sharing the same burstIdentifier even when they are not appearing in the main Library.

Here is the core of the issue I’m facing:

While I can fetch these assets, there is no explicit property on PHAsset to determine if it currently resides in the "Recently Deleted" album.
In our app's workflow, PHPhotoLibrary returns success = YES during the performChanges block. However, because the new burst is automatically grouped with an existing deleted set, the photo is immediately invisible to the user in the main Library.
Our intended UX is to show a warning alert to the user if we detect that a matching burstIdentifier already exists in the "Recently Deleted" album. This prevents the confusion of a "successful" save that results in an invisible file.

Question for clarification:

Is there a recommended, officially supported way to identify if a PHAsset returned by fetchAssetsWithBurstIdentifier:options: is currently in the "Recently Deleted" state so we can reliably trigger our UI alert?

I appreciate your technical insights on how to handle this scenario properly to ensure a clear experience for our users.

Best regards,

Jimmy

0

Answer 4

DTS Engineer OP

Apple

3d

Hello jimmy520,

By design, there is no API for fetching Recently Deleted assets. Is it necessary to support saving a burst photo with the same burstIdentifier as recently deleted assets? You may want to reconsider your goals.

A potential workaround could be to use creationRequestForAssetFromImage: of PHAssetChangeRequest to create an entirely new PHAsset with the UIImage of the photo you're trying to save. However, please note that while this asset will be free of the burstIdentifier associated with the deleted burst photos group, it will also lack other metadata as well:

Important A UIImage object does not contain all metadata associated with the image file it was originally loaded from (for example, Exif tags such as geographic location, camera model, and exposure parameters). To ensure such metadata is saved in the Photos library, instead use the creationRequestForAssetFromImageAtFileURL: method or the PHAssetCreationRequest class. To copy metadata from one file to another, see Image I/O.

You can still file an enhancement request through Feedback Assistant with information on how this design impacts you. Bug Reporting: How and Why? explains how you can do that.

Richard Yeh  Developer Technical Support

0

Answer 5

jimmy520 OP

3d

Hi Richard,

Thank you for the clear explanation and the suggested workaround.

I understand now that there is no official API to fetch assets specifically from the "Recently Deleted" album, and that using UIImage to create a new asset would result in the loss of critical metadata.

Regarding your question about our goals: Our intent was to provide a better UX by warning users before a save operation results in an "invisible" asset (due to the automatic grouping with deleted items). Since we cannot reliably detect this state via the current Photos Framework, we will evaluate whether to handle this by pre-processing the metadata or by filing an enhancement request through Feedback Assistant as you suggested.

I appreciate your time and the technical insights provided throughout this discussion.

Best regards,

Jimmy

0