Hello, I am encountering a UI layout issue on iOS 26 where UITabBar items become squashed or overlapping during device rotation (from Portrait to Landscape). This glitch occurs specifically when a custom UITabBarAppearance is applied. 1. "Liquid Glass" and UITabBar Customization According to TN3106, Apple states: "Starting in iOS 26, reduce your use of custom backgrounds in navigation elements and controls. While the techniques in this document remain valid for iOS 18 and earlier, prefer to remove custom effects and let the system determine the navigation bar background appearance. Any custom backgrounds and appearances you use in the navigation bar might overlay or interfere with Liquid Glass or other effects that the system provides, such as the scroll edge effect." Does this guidance also apply to UITabBar? Specifically, could setting a custom background color via UITabBarAppearance interfere with internal layout constraints required for the Liquid Glass effect to adapt correctly during orientation changes? It appears that the internal UIStackView may fail to recalculate width in time when these system effects are active. 2. Validation of the Layout Workaround To maintain our app's visual identity while resolving this squashing issue, I implemented the following fix within the transition coordinator of my UITabBarController: Code Implementation (Objective-C) [coordinator animateAlongsideTransition:^(id<UIViewControllerTransitionCoordinatorContext> _Nonnull context) { // Forcing a layout refresh to synchronize with the rotation animation [weakSelf.tabBar invalidateIntrinsicContentSize]; [weakSelf.tabBar setNeedsLayout]; [weakSelf.tabBar layoutIfNeeded]; } completion:nil]; Is manually invalidating the intrinsic content size an acceptable practice for iOS 26? Or is there a more "system-native" approach to ensure UITabBar layout remains stable and compatible with Liquid Glass, especially when custom appearances are necessary?

Hello Apple Developer Support and Community, I am a senior software engineer investigating a Disk Writes Resource Violation (bug_type 145) for a photo-management application (BeePhotos v2.3.0). We observed a violation where the app dirtied approximately 1GB of file-backed memory in just 48 seconds, triggering a resource report. [Core Diagnostic Data] The following data is extracted from the .crash report: Event: disk writes Action taken: none Writes caused: 1073.96 MB over 48.28s (Average: 22.24 MB/second) System Limit: 1073.74 MB over 86,400 seconds (Daily limit) Device: iPhone 15 Pro (iPhone16,2) OS Version: iOS 26.4 (Build 23E244) Free Space: 3852.25 MB (Approx. 3.8 GB) [Implementation Details] Our application performs the following sequence for a 1GB video download: Download: Uses NSURLSessionDownloadTask to download the file to the system-provided location URL (in the /tmp or com.apple.nsurlsessiond directory). Move: In didFinishDownloadingToURL, we move the file to the App’s sandbox Library/Caches directory using FileManager.default.moveItem(at:to:). Save: We then add the file to the Photo Library via PHAssetCreationRequest.addResource(with:fileURL:options:) using the local URL in Library/Caches. [Technical Questions] I suspect the 1GB download is being "amplified" into ~3GB of total physical writes, and I would like to confirm the following: Cross-Volume Move: Does moving a file from the nsurlsessiond managed temporary directory to the App’s sandbox Library/Caches constitute a Cross-Volume Move on APFS? If so, does this effectively double the write count (1GB download + 1GB copy-on-move)? PHPhotoLibrary Ingestion: When using PHAssetCreationRequest, does the system perform another 1:1 data copy of the source file into the assets database? Would this result in a 3rd GB of writing? Low Disk Space Impact: Given the device only had 3.85 GB free, does the system’s "low disk space" state (near the 150MB threshold) increase the overhead for metadata updates or physical write amplification that counts towards this limit? Best Practices: To stay within the daily 1GB budget for high-resolution media, is it recommended to call PHAssetCreationRequest directly using the location URL from didFinishDownloadingToURL to avoid intermediary copies? Are there any permission or lifecycle risks with this approach? Any insights from the Apple engineering team or the community on how to minimize the write footprint during high-speed ingestion would be highly appreciated. Best regards

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.

iOS 15 has new function to manually adjust capture location, time and date. The question is I used requestImageDataAndOrientation(for:options:resultHandler:) to request image,  but the EXIF data is still unadjusted. Is there anyway to request image with the adjusted EXIF data ?