file uri scheme

I am currently encountering a problem: during the process of uploading a large file, I have moved the file that was not successfully uploaded to the trash can. These two operations have been tested to be serial (triggering the 'create Item' callback first, followed by the 'modify Item' callback), which means that the file must be uploaded before it can be moved to the recycle bin (which can also result in the file being stored in the cloud recycle bin). I want to implement: directly interrupt this upload process and then do not complete the upload. How can I achieve this? Please help me. Thank you

Does Apple suggest that developers transition to arm64-only and drop support for arm64_32 devices? No — Apple Watch Series 9 and later, and Apple Watch Ultra 2 and later all support the arm64 architecture. There are many Apple Watch devices that run watchOS versions your app likely supports beyond that list, so you need to keep the arm64_32 architecture around for those devices. As noted in the announcement, you'll want to use the Standard Architectures build setting for your watchOS app, and that will automatically build the right set of supported architectures for your app, which will include arm64_32 as well as arm64. If we add support for both arm64_32 and arm64, the binary will almost certainly exceed the 75 MB app size limit, and potentially violate the size constraints for each architecture slice as well. What size constraints per architecture are you thinking of? The Maximum build file sizes documentation lists such a requirement for iOS apps in the iOS 7 and 8 time frame, but that isn't rele

Here is the code of my message extension, if that helps. I am indeed trying to write to the shared storage of the App Groups import os.log // Apple's modern, fast, privacy-safe logging system class NotificationService: UNNotificationServiceExtension { private let log = OSLog( subsystem: Bundle.main.bundleIdentifier!, category: pushnotificationsmessageextension ) var contentHandler: ((UNNotificationContent) -> Void)! // A mutable copy of the notification content — this is what we'll modify or save var bestAttemptContent: UNMutableNotificationContent? // Main entry point — called every time a push arrives with `mutable-content: 1` override func didReceive( _ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void ) { // Save the handler so we can call it later (required!) self.contentHandler = contentHandler // Make a mutable copy so we can modify title, body, attachments, etc. bestAttemptContent = request.content.mutableCopy() as? UNMutableNotification

This answer is somewhat covered here: https://developer.apple.com/forums/thread/741948?answerId=811104022#811104022 The essence is that this warning refers to custom metadata saved in the HEIC images when using ObjectCaptureSession UI on iOS devices with LiDAR. There is no public way to provide this data besides using our ObjectCaptureSession capture UI which adds it automatically. If you are using another capture approach, you may safely ignore these warnings. The benefit of using the ObjectCaptureSession front-end is that we may additionally use these raw points to improve reconstruction of textureless surfaces (e.g. white walls) where depth maps may not be sufficient. To be clear, this point cloud data is distinct from the depthDataMap in the sample. This depth map may be available when reading HEIC files. It may be automatically populated (even on non-LiDAR devices) from stereo disparity data generated by AVCaptureSession in a multi-camera session, or may be derived from LiDAR data. Regardless of

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

Hello @ricciohu. I talked to our engineers about this question. Here is the complete story. LUT-based ICC profiles have never been supported on Apple platforms. Previously you may have been able to provide LUT-based ICC profiles to our routines but it was a bug that our routines were not properly checking parameters and raising errors for LUT-based ICC profiles. This has been fixed in recent updates and our routines now produce errors and don't allow LUT-based ICC profiles. Previously, using LUT-based ICC profiles with our routines produced unpredictable and erroneous results as there was no officially supported and maintained code inside of any of our routines for handling them. Any functionality you may have observed in previous Apple products using our routines together with LUT-based ICC profiles is subject to error and change without notice at any time. I do not recommend using LUT-based ICC profiles in any production code including code targeting past system software versions. If you require LUT-based I

Hello @erawq, There is no reliable way to disconnect your app's audio playback from an AirPlay route (aside from the user taking action to change the route in Control Center for example). From AVAudioSessionTypes.h: - AVAudioSessionCategoryPlayAndRecord: /// DefaultToSpeaker will default to false, but >can be set to true, routing to Speaker /// (instead of Receiver) when no other audio route is connected. The key phrasing here is (instead of Receiver) when no other audio route is connected. In other words: try audioSession.setCategory(.playAndRecord, options: .defaultToSpeaker) This call is only expected to have an effect when audio is currently being routed to the device's receiver (the speaker which on most devices is at the top near the front-facing camera). In your case, audio is being routed to an AirPlay route, so it is expected that this call should not have an effect. If you would like the capability of programmatically disconnecting from an AirPlay route, I suggest that you open a new Feedback to

the communication permission work for me with xcode and ios 26.2 public release it needs sync contacts and enable communication limit on the child device. Thanks. I also got mine working. Not sure if it was the upgrade to 26.2 actual release from 26.2 RC or changing the Communications limits. I still don't know how to fake my location to texas to test significant app update Two thoughts: Use a VPN GPX file in your project (for testing) - https://techcommunity.microsoft.com/discussions/windows10space/can-i-spoof-gps-location-on-iphone--no-jailbreak-needed/4427403/replies/4427409