When attempting to fix an issue that is only happening on a specific iOS build I noticed that I am not able to install that specific build on my simulator. Is there any way to get specific iOS builds that are not available through Xcode? Example: The bug I am trying to fix is only happening on 17.6.1 and 17.7.1. These specific builds are not available through Xcode. Attempted Resolution: I found a iPhone14,5_17.6.1_21G101_Restore.ipsw file but was not able to import it into Xcode for use nor was I able to use it on a physical device.

What happened? facing issue to upload on ios TestFlight xcode version 16 macOS 15.0 xcrun bitcode_strip -r platforms/ios/YourApp/Plugins/YourFramework.framework/YourFramework -o platforms/ios/YourApp/Plugins/YourFramework.framework/YourFramework already tried bitcode_strip command but also that didn't work. The following issues occurred while distributing your application. Asset validation failed Invalid Executable. The executable '***** Syndrome.app/Frameworks/OneSignal.framework/ OneSignal' contains bitcode. (ID: fda6a528-a835-4b16-8252-893d8d16acbd) Steps to reproduce? create build , upload it on testflight and you'll get error OneSignal Cordova SDK version Release 3.3.1 Which platform(s) are affected? iOS

Hello! I am trying to remove a photo from my Photos Library using PhotosUI. I run into this error when I attempt to delete it: "Error returned from daemon: Error Domain=com.apple.accounts Code=7 "(null)"" No photos access scope requirements declared for changes Failed to log access with error: access= accessor:<> identifier:82068C12-FD10-4DE2-9867-B4406FBFB706 kind:intervalEvent timestampAdjustment:0 visibilityState:0 assetIdentifierCount:0 accessCount:0 tccService:kTCCServicePhotos, error=Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.privacyaccountingd" UserInfo={NSDebugDescription=connection to service named com.apple.privacyaccountingd}

Hi, I'm trying to create a UICollectionView where the cell high is automatic. Cells contains a UILabel with all anchors to the contentView of the cell. It seems to work but I have a strange behavior with longer text, on reload data and on device rotation: Cells do not display the whole text or they change row, both randomly. To create my collection view I first create the collection view with a custom flow layout setting the automatic size on viewWillAppear: let collectionViewFlowLayout = CustomFlowLayout() collectionViewFlowLayout.estimatedItemSize = UICollectionViewFlowLayout.automaticSize collectionView = UICollectionView(frame: .zero, collectionViewLayout: collectionViewFlowLayout) and I have also overridden: override func willAnimateRotation(to toInterfaceOrientation: UIInterfaceOrientation, duration: TimeInterval) { collectionView.setNeedsLayout() self.collectionView.layoutIfNeeded() self.collectionView.collectionViewLayout.invalidateLayout() //self.collectionView.reloadData() } Then, I created the custom layout as follow: import UIKit final class CustomFlowLayout: UICollectionViewFlowLayout { override func layoutAttributesForElements(in rect: CGRect) -> [UICollectionViewLayoutAttributes]? { let layoutAttributesObjects = super.layoutAttributesForElements(in: rect)?.map{ $0.copy() } as? [UICollectionViewLayoutAttributes] layoutAttributesObjects?.forEach({ layoutAttributes in if layoutAttributes.representedElementCategory == .cell { if let newFrame = layoutAttributesForItem(at: layoutAttributes.indexPath)?.frame { layoutAttributes.frame = newFrame } } }) return layoutAttributesObjects } override func layoutAttributesForItem(at indexPath: IndexPath) -> UICollectionViewLayoutAttributes? { guard let collectionView = collectionView else { fatalError() } guard let layoutAttributes = super.layoutAttributesForItem(at: indexPath)?.copy() as? UICollectionViewLayoutAttributes else { return nil } layoutAttributes.frame.origin.x = sectionInset.left if(indexPath.section == 0){ layoutAttributes.frame.size.width = collectionView.safeAreaLayoutGuide.layoutFrame.width - sectionInset.left - sectionInset.right } else if (indexPath.section == collectionView.numberOfSections - 1){ let width = ScreenUtility.getCollectionCellWidthForElement(in: collectionView, sectionLeft: sectionInset.left, sectionRight: sectionInset.right, minimumInteritemSpacing: minimumInteritemSpacing, multiplier: 3) layoutAttributes.frame.origin.x = ScreenUtility.getCollectionCellOriginForElement(in: collectionView, at: indexPath, forElementHavingWidth: width, sectionLeft: sectionInset.left, sectionRight: sectionInset.right, minimumInteritemSpacing: minimumInteritemSpacing, multiplier: 3) layoutAttributes.frame.size.width = width } else if (indexPath.section == collectionView.numberOfSections - 3) || (indexPath.section == collectionView.numberOfSections - 4){ let width = ScreenUtility.getCollectionCellWidthForElement(in: collectionView, sectionLeft: sectionInset.left, sectionRight: sectionInset.right, minimumInteritemSpacing: minimumInteritemSpacing) layoutAttributes.frame.origin.x = ScreenUtility.getCollectionCellOriginForElement(in: collectionView, at: indexPath, forElementHavingWidth: width, sectionLeft: sectionInset.left, sectionRight: sectionInset.right, minimumInteritemSpacing: minimumInteritemSpacing) layoutAttributes.frame.size.width = width } else { let width = ScreenUtility.getCollectionCellSizeForElementFullRow(in: collectionView, sectionLeft: sectionInset.left, sectionRight: sectionInset.right) layoutAttributes.frame.origin.x = ScreenUtility.getCollectionCellOriginForElementFullRow(in: collectionView, sectionLeft: sectionInset.left, sectionRight: sectionInset.right) layoutAttributes.frame.size.width = width } return layoutAttributes } } And finally on collection view cells: override func preferredLayoutAttributesFitting(_ layoutAttributes: UICollectionViewLayoutAttributes) -> UICollectionViewLayoutAttributes { setNeedsLayout() layoutIfNeeded() let targetSize = CGSize(width: layoutAttributes.frame.width, height: 0) layoutAttributes.frame.size = contentView.systemLayoutSizeFitting(targetSize, withHorizontalFittingPriority: .required, verticalFittingPriority: .fittingSizeLevel) return layoutAttributes } override func prepareForReuse() { self.nameLabel.text = "" self.idLabel.text = "" self.contentView.setNeedsLayout() self.contentView.layoutIfNeeded() } Let me show you an example on the iPad that is the worst. First Time I open the collection view I have cells on wrong rows and not sized properly Then I rotate the device portrait and the cells are fine On landscape again it changes behavior: This is just an example, things happens apparently randomly, and also sometimes cells disappear (I think the height is set to 0). I really do not understand why, cells width seems to be computed correctly, and cell label is set via setter: open var step: String = "" { didSet { nameLabel.text = step nameLabel.sizeToFit() self.contentView.setNeedsLayout() self.contentView.layoutIfNeeded() } }

Hi everyone, I’m working on an iOS app and I need to implement background fetch to periodically update data even when the app is in the background. I’ve enabled Background Fetch in the capabilities, but I’m not sure how to properly set up the fetch intervals and ensure reliable data updates without draining too much battery. What’s the best approach to set the frequency of background fetches? Are there any specific best practices to optimize battery usage while using background fetch? Is there a way to ensure the fetch runs more frequently for time-sensitive data? Any advice or code examples would be greatly appreciated! Thanks in advance for your help.

When I call a number, it rings for them but when they pick up, we can't hear each other. I get this in my logs: 🎤 Audio Route Changed: AVAudioSessionRouteChangeReason(rawValue: 3) ❌ Error handling route change: Error Domain=NSOSStatusErrorDomain Code=1701737535 "Session activation failed" what does that code actually mean?

Here’s a suggestion: Apple should provide a feature for iPhone users to automatically log the specific time and date whenever they reset their phone. This log would allow users to easily track when resets occur. Additionally, Apple could enhance backup options by enabling users to restore any data lost during a reset. This might include automatic backups before each reset or a more intuitive process for recovering previously backed-up data.

I started getting a location error recently. I've never seen this error before and it began happeing randomly. Here is the breakpoint. (if let locationManager........) var currentLocation: Result<CLLocation, Error> { get { #if DEBUG return .success(CLLocation(latitude: CLLocationDegrees(exactly: 0)!, longitude: CLLocationDegrees(exactly: 0)!)) #else if let locationManager = self.locationManager { return locationManager.currentLocation } return .failure(LocationError.unknown) #endif } } I've tried everything I can think of to fix the issue. It has an issue getting the users location when logging in. I've made no changes to the code and everything has worked for years. The bug reports show nothing. I've tried re-installing Xcode, rebuilding the pods etc. I've tried everything that you would normally do in this situation.

Simulators sometimes draw the screen with the wrong aspect ratio and appear distorted. I'm on macOS 14.7 and using Xcode 16.1, but Xcode 16 was also sometimes doing this. This is happening in both iPhone simulator and iPad simulators. Is anyone else seeing this? It's not just the Home Screen, it happens in apps too. I have a weird bug when testing on the iPad simulators and I can't tell if it is a bug in the simulator or in my app. All my iPads are broken, so I can't actually test on device right now.

In a UITabBarController, its controllers are set to be UINavigationControllers. When programmatically setting the selectedViewController to a desired controller which is not currently displayed, the selected icon is correct however the actual view controller is still the previously selected. Pseudo code: tabController.controllers = [viewcontroller1, viewcontroller2, viewcontroller3].map{ UINavigationController(rootViewController: $0) } .... // let's say at some point tab bar is set to e.g. showing index 1 tabController.selectedController = tabController.controllers[0] // after this the icon of the 1st tab is correctly displayed, but the controller is still the one at index 1 I have noticed that if the controllers are simple UIViewController (not UINavigationController) upon setting the selectedViewController the TabController sets both icon and content correctly. But this is not the wanted setup and different UINavigationControllers are needed. Is this a new bug in iOS18? Any idea how to fix this (mis)behaviour?

Hi, iOS 18.1 Safari 18 does not play HLS/.m3u8 audio tracks (while all previous iOS Safari still do). If I turn on the Web Inspector toggle and put it on, restart Safari/ refresh the page, the player works. Before filing a bug, are you already aware of such behavior or some way to deal with it?

Here are reasons why Apple should consider an iMessage update to include message refreshing, chat sharing, and data restoration, along with the option for users to request message re-sending if a malfunction occurs. Such an update would enhance the iPhone experience and provide benefits that could positively impact iMessage users worldwide. Reliable Data Restoration for Lost Messages • Problem: If users accidentally delete messages, experience a technical issue, or encounter a failed backup, they can lose access to essential conversations, photos, and shared files. • Solution: By implementing a robust data restoration feature, Apple could allow users to refresh and recover past conversations, giving them access to their message history even after loss or deletion. • Impact: This would give users peace of mind, knowing their conversations can be recovered. iMessage would become a more reliable platform for retaining important memories, personal conversations, and work-related exchanges. Ability to Request Message Re-Sending During Malfunctions • Problem: If a message fails to deliver or is accidentally deleted on one end, there’s currently no simple way to retrieve that specific message unless the sender manually re-sends it. • Solution: Adding a feature that allows users to request re-sending from the other party when messages go missing would make iMessage more resilient to data loss and technical glitches. • Impact: This would ensure that users maintain complete conversations even if a malfunction occurs, minimizing miscommunication and frustration. This feature would be particularly beneficial for people relying on iMessage for important or time-sensitive conversations. Improved Continuity for Important Conversations • Problem: Losing access to conversation history can disrupt both personal and professional interactions, particularly if key information is lost. • Solution: A message refresh and restoration feature would allow users to retrieve older conversations, preserving continuity for both personal relationships and work-related discussions. • Impact: This feature would be valuable globally, enabling people to retain important conversations without disruption. iMessage would become a trusted platform for managing long-term conversations and preserving significant exchanges. Increased Privacy and Security for Message Restoration • Problem: Without a native restoration option, users sometimes turn to third-party tools, which can pose privacy risks. • Solution: Apple could introduce an encrypted, secure data restoration and chat-sharing feature within iMessage, ensuring that message recovery is both private and reliable. • Impact: This would enhance iMessage’s reputation for data privacy, as users worldwide could trust that their data remains protected when recovering messages. A secure, Apple-native solution would eliminate the need for risky third-party options. Easier Transition and Access to Conversation History • Problem: Moving between devices or recovering from backups can cause users to lose portions of their message history, which can be frustrating and disruptive. • Solution: A seamless chat-sharing and message restoration option would allow users to refresh their iMessage conversations across devices, ensuring a complete and consistent message history on any new or restored iPhone. • Impact: This would make iMessage a more reliable platform for those who frequently switch devices or need to recover from backups. Globally, it would simplify iMessage use, making it easier for people to stay connected without worrying about data loss. User-Controlled Data Retention and Message Management • Problem: Currently, users have limited control over retrieving lost or deleted messages, often having to rely on full device backups. • Solution: By introducing a message refresh feature and allowing users to request re-sending from contacts, Apple would give iMessage users greater control over their data and conversations. • Impact: This level of control would appeal to iMessage users worldwide, as they could manage their own message history with flexibility. It would make iMessage a more user-centered, customizable messaging platform. Implementing these features would make iMessage a more resilient, secure, and user-friendly platform for users everywhere, enhancing both the reliability and versatility of Apple’s messaging service.

Here are some reasons why Apple should consider an update to enhance message refreshing and chat sharing on WhatsApp, making it smoother across both iPhone and Android: Cross-Platform Compatibility • Problem: Right now, switching between iPhone and Android on WhatsApp can result in lost messages or complicated backup processes due to differences in operating systems and data formats. • Impact: A universal update allowing seamless message refresh and sharing would bridge the gap between iOS and Android. Users could switch devices without losing conversation history, making the experience more fluid and inclusive for both iPhone and Android users. Enhanced Data Security and Privacy • Problem: Many users rely on third-party methods to back up or transfer WhatsApp chats, which can pose privacy risks. • Solution: A unified system from Apple (and Android) could ensure that all backups and chat transfers are encrypted, keeping data private and secure, aligned with each platform’s commitment to data protection. • Impact: This would reduce security concerns for people using their devices for sensitive communications, such as business transactions or personal matters. Peace of Mind for Users • Problem: Many users worry about losing important messages when they upgrade their phones or change their operating systems. • Solution: An update that includes auto-refresh and universal chat-sharing across backups would make sure conversations and media are always accessible, no matter the device. • Impact: This peace of mind would lead to higher user satisfaction and reduce anxiety about data loss, enhancing WhatsApp’s reliability as a communication platform worldwide. Improved User Experience and Retention • Problem: The complexity of transferring chats between iOS and Android devices can push users to avoid switching or even consider alternatives to WhatsApp. • Solution: With a streamlined message and chat-sharing experience, users would find it easier to stay connected on WhatsApp, regardless of the device. • Impact: This could increase user retention and trust, making WhatsApp more indispensable as a global messaging platform. Greater Accessibility for Global Users • Problem: Many users globally use WhatsApp for family, work, and community connections, especially in areas where it is the primary communication tool. Losing messages or finding backup systems challenging can cause disruptions. • Solution: A message refresh and sharing update would support seamless transitions and backups, making WhatsApp more accessible and consistent. • Impact: This would support worldwide connectivity, especially in regions where WhatsApp is a lifeline for communication, fostering inclusivity and reducing digital barriers. Future-Proofing for Technological Advancements • Problem: As technology advances, the gap between iOS and Android compatibility could widen if not addressed now. • Solution: An update that includes flexible chat-sharing and message-refreshing capabilities would keep Apple and Android devices aligned and prepared for future features or communication needs. • Impact: This proactive approach ensures that WhatsApp remains relevant, adaptable, and future-ready for global users as both platforms evolve. Overall, this update could foster better communication, security, and user satisfaction worldwide. It would also help Apple and WhatsApp strengthen their roles as leaders in secure and universal messaging solutions.

Here are some reasons why Apple should consider an update to enhance message refreshing and chat sharing on WhatsApp, making it smoother across both iPhone and Android: Cross-Platform Compatibility • Problem: Right now, switching between iPhone and Android on WhatsApp can result in lost messages or complicated backup processes due to differences in operating systems and data formats. • Impact: A universal update allowing seamless message refresh and sharing would bridge the gap between iOS and Android. Users could switch devices without losing conversation history, making the experience more fluid and inclusive for both iPhone and Android users. Enhanced Data Security and Privacy • Problem: Many users rely on third-party methods to back up or transfer WhatsApp chats, which can pose privacy risks. • Solution: A unified system from Apple (and Android) could ensure that all backups and chat transfers are encrypted, keeping data private and secure, aligned with each platform’s commitment to data protection. • Impact: This would reduce security concerns for people using their devices for sensitive communications, such as business transactions or personal matters. Peace of Mind for Users • Problem: Many users worry about losing important messages when they upgrade their phones or change their operating systems. • Solution: An update that includes auto-refresh and universal chat-sharing across backups would make sure conversations and media are always accessible, no matter the device. • Impact: This peace of mind would lead to higher user satisfaction and reduce anxiety about data loss, enhancing WhatsApp’s reliability as a communication platform worldwide. Improved User Experience and Retention • Problem: The complexity of transferring chats between iOS and Android devices can push users to avoid switching or even consider alternatives to WhatsApp. • Solution: With a streamlined message and chat-sharing experience, users would find it easier to stay connected on WhatsApp, regardless of the device. • Impact: This could increase user retention and trust, making WhatsApp more indispensable as a global messaging platform. Greater Accessibility for Global Users • Problem: Many users globally use WhatsApp for family, work, and community connections, especially in areas where it is the primary communication tool. Losing messages or finding backup systems challenging can cause disruptions. • Solution: A message refresh and sharing update would support seamless transitions and backups, making WhatsApp more accessible and consistent. • Impact: This would support worldwide connectivity, especially in regions where WhatsApp is a lifeline for communication, fostering inclusivity and reducing digital barriers. Future-Proofing for Technological Advancements • Problem: As technology advances, the gap between iOS and Android compatibility could widen if not addressed now. • Solution: An update that includes flexible chat-sharing and message-refreshing capabilities would keep Apple and Android devices aligned and prepared for future features or communication needs. • Impact: This proactive approach ensures that WhatsApp remains relevant, adaptable, and future-ready for global users as both platforms evolve. Overall, this update could foster better communication, security, and user satisfaction worldwide. It would also help Apple and WhatsApp strengthen their roles as leaders in secure and universal messaging solutions.

Where can I find ios 18 DeveloperDiskImage.dmg?

Incident Identifier: 81AB2E74-1895-4DA4-9362-AE9E20B13847 Distributor ID: com.apple.AppStore Hardware Model: iPhone16,2 Process: Uplus [16285] Path: /private/var/containers/Bundle/Application/F737D7AC-B933-4204-926C-9149AD377F4B/Uplus.app/Uplus Identifier: com.haier.uhome.Uplus Version: 9.0.0 (2024091802) AppStoreTools: 16A242b AppVariant: 1:iPhone16,2:18 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.haier.uhome.Uplus [4813] Date/Time: 2024-10-29 11:43:30.8727 +0800 Launch Time: 2024-10-29 11:43:30.8707 +0800 OS Version: iPhone OS 18.1 (22B5045g) Release Type: Beta Baseband Version: 2.20.02 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_PROTECTION_FAILURE at 0x00000001e95280e0 Exception Codes: 0x0000000000000002, 0x00000001e95280e0 VM Region Info: 0x1e95280e0 is in 0x1e9528050-0x1e956c050; bytes after start: 144 bytes before end: 278383 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL mapped file 1e9528000-1e9528050 [ 80] r--/rw- SM=COW Object_id=f1de19db ---> __TPRO_CONST 1e9528050-1e956c050 [ 272K] r--/rw- SM=COW /usr/lib/dyld mapped file 1e956c050-1e9570000 [ 16K] r--/rw- SM=COW Object_id=f1de19db Termination Reason: <0x2A> 2 Triggered by Thread: 0 Thread 0 Crashed: 0 dyld 0x00000001ac079500 0x1ac03f000 + 238848 1 dyld 0x00000001ac072bcc 0x1ac03f000 + 211916 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x2010003030100000 x1: 0x0000000fffffc0d0 x2: 0x0000000000000004 x3: 0x00000001ac047829 x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x2010003030100000 x9: 0x2010003030100000 x10: 0x000000016b917dfd x11: 0x00000001ac0b4240 x12: 0x0000000000000050 x13: 0x0000000000000044 x14: 0x0000000000052010 x15: 0x0000000000000000 x16: 0x0000000000000000 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x0000000182bb0000 x20: 0x000000016b917b50 x21: 0x000000016b917af8 x22: 0x00000001e9528050 x23: 0x000000016b9177d8 x24: 0x0000000fffffc10c x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x0000000000000000 fp: 0x000000016b917870 lr: 0x84028001ac079380 sp: 0x000000016b9177d0 pc: 0x00000001ac079500 cpsr: 0x60001000 esr: 0x92000047 (Data Abort) byte write Translation fault Binary Images: 0x1044e8000 - 0x10795bfff main_executable_path_missing arm64 /main_executable_path_missing 0x1ac03f000 - 0x1ac0c29a3 dyld arm64e /usr/lib/dyld EOF 18.1.crash

I am trying to understand the 2.3.3 section as it was cited as an issue with my submission for an iOS App. "2.3.3 Screenshots should show the app in use, and not merely the title art, login page, or splash screen. They may also include text and image overlays (e.g. to demonstrate input mechanisms, such as an animated touch point or Apple Pencil) and show extended functionality on device, such as Touch Bar." I have provided some iOS screens for showing a stage of one game being played. However my App includes 5 games and 4 modes of play. Should I include similar screenshots for each game? I fear I may run out of screenshots. Could using videos help? I believe we are restricted to 3. Do I need to show screenshots for the App on iPad ( it is not Universal ) ? The input mechanism is a text field next to a submit button. Do I have to highlight/overlay the same? If I do the above, is it okay/recommended to skip the info page, Home Screen which neatly shows all modes and the next screen which compactly shows all the games, example of dark mode , achievements and leaderboards? Is there some other thing I should consider here? I was asked to check on Support Forum first. I am in the midst of an App Review. Please advise!! Thanks in advance.

Hello; I am using Rad Studio 11.3 software development language. When distributing the application, it works fine with iOS 16.7 iPhone X. I am getting "DeveloperDiskImage.dmg" error on iPhone 14 Pro iOS 18.1 device. The application crashes on the opening screen. At the same time, my HospiTools application in Appstore is distributed and installed with iPhone X 16.7. When we download the application from Appstore, it works fine with iOS 18.1. Thank you.

While customizing ImagePicker and using it, we find out that the metadata is not reflected normally and report it. The situation is as follows. The time or time zone of an image is changed in the Photos app. Changing the time zone of an image with an actual capture date of 2024:11:08 08:27:44 → 2024:11:07 17:27:44 Image data is extracted from a PHAsset using PHImageManager. The metadata is obtained from this image data. The time zone information exposed in the Exif tag information does not reflect the time or time zone changed in the Photos app. let asset: PHAsset = ... .... let options = PHImageRequestOptions() options.isSynchronous = true options.version = .current options.deliveryMode = .highQualityFormat options.resizeMode = .none options.normalizedCropRect = .zero options.isNetworkAccessAllowed = true options.progressHandler = { progress, error, _, _ in } PHImageManager.default().requestImageDataAndOrientation(for: asset, options: options) { imageData, uti, orientation, info in let cgImageSource = CGImageSourceCreateWithData(imageData! as CFData, nil) let properties = CGImageSourceCopyPropertiesAtIndex(cgImageSource!, 0, nil) as? Dictionary&lt;String, Any&gt; let exif = properties!["{Exif}"] let dictionary = exif as? Dictionary&lt;String, Any&gt; } Metadata Check In this case, it is reflected in the creationDate of PHAsset, so it can be somewhat compensated by forcibly replacing the metadata. However, because PHAsset does not include time zone information, when changing the time zone as well, it's impossible to calculate the correct time according to the time zone. PHPicker This issue is resolved when using the PHPickerResult provided by PHPicker. extension PhotosPickerViewController: PHPickerViewControllerDelegate { public func picker(_ picker: PHPickerViewController, didFinishPicking results: [PHPickerResult]) { ..... for result in results { let identifier = UTType.image.identifier if result.itemProvider.hasItemConformingToTypeIdentifier(identifier) { result.itemProvider.loadDataRepresentation(forTypeIdentifier: identifier) { data, error in guard let data = data, let cgImageSource = CGImageSourceCreateWithData(data as CFData, nil), let properties = CGImageSourceCopyPropertiesAtIndex(cgImageSource, 0, nil) as? Dictionary&lt;String, Any&gt;, let exif = properties["{Exif}"], let dictionary = exif as? Dictionary&lt;String, Any&gt; else { return } } } } } } Metadata Check Question I wonder why this happens, and if this is normal behavior. Instead of the System Picker that Apple provides as a base, I wonder if there is any way I can supplement it in that situation if I use a customizer.

Basic Information Please provide a descriptive title for your feedback: Sheet presentationDetents breaks after rapid open/dismiss cycles Which platform is most relevant for your report? iOS Description Steps to Reproduce: Create a sheet with presentationDetents([.medium]) Rapidly perform these actions multiple times (usually 3-4 times): a. Open the sheet b. Immediately scroll down to dismiss Open the sheet again Observe that the sheet now appears at .large size, ignoring the .medium detent Expected Result: Sheet should consistently maintain .medium size regardless of how quickly it is opened and dismissed. Actual Result: After rapid open/dismiss cycles, the sheet ignores .medium detent and appears at .large size. Reproduction Rate: Occurs consistently after 3-4 rapid open/dismiss cycles More likely to occur with faster open/dismiss actions Configuration: iOS 18 Xcode 16.0 (16A242d) SwiftUI Device: iPhone 14