“file uri scheme”

No, you don't need to write the data as a file to your the app’s document directory. With UIActivityViewController, you can share a piece of text, as shown in the following code example let text = This is a piece of text. let activityViewController = UIActivityViewController(activityItems: [text], applicationActivities: nil) With that, when activityViewController is presented, it shows the system-provided share UI that contains a Save to Files button, which allows you to save the text as a file to iCloud Drive. Tapping the button shows a UI that has a Save as field for you to input the file name for the taget file. To import a file, consider using SwiftUI fileImporter. Best, —— Ziqiao Chen  Worldwide Developer Relations.

@ramprajapat Can you please create a new post with the link to your AASA file and the logs and description of the issue. Thanks Albert Pascual
  Worldwide Developer Relations.

Hi @DTS Engineer , I am also facing this weird issue I am consistently encountering a build warning in Xcode 26 that prevents proper symbolication of crash logs. The warning states: warning: (arm64) /Users/mickey/Library/Developer/Xcode/DerivedData/CalendarSync-bjuvwxojzofqzzcmzzpdozbujrge/Build/Products/Debug-iphoneos/CalendarSync.app/CalendarSync empty dSYM file detected, dSYM was created with an executable with no debug info. Steps to Reproduce: Open the project in Xcode 26. Build the project for a physical iOS device (arm64) or Archive the project. The warning appears during the Generate dSYM phase of the build process. Troubleshooting Steps Already Taken (Issue Persists): Set 'Enable Debug Dylib Support' to No. Verified 'Debug Information Format' is set to 'DWARF with dSYM File'. Verified 'Generate Debug Symbols' is set to Yes. Set 'Strip Debug Symbols During Copy' and 'Strip Linked Product' to No. Performed 'Clean Build Folder' and manually deleted the DerivedData folder. The issue per

I don't think I'm experiencing the problem anymore, but it appears that multiple promo codes were generated inadvertently. I've filed FB22253261 with more information if you want to look.

I filed a bug report with an sample project and 2 files for testing. I confirm the problem. FB22253128 Here the message in FB (with the zipped sample project and 2 test files): Context: Xcode 26.3, iOS 18.7.6 on iPhone Xs In this iOS app, I call UIActivityViewController to let user Airdrop files from the app. When trying to send a URL whose file name contains some characters like accentuated (-, é, '), the transfer fails. Removing those characters makes it work without problem. Steps to reproduce Build and load the app on iPhone transfer the 2 pdf files ('name accentué.pdf' and 'name plain.pdf' to the Documents folder of Test app (I did it in Finder on Mac with iPhone USB connected to the Mac). The 2 files are identical except their name. Run the app Tap 'Send by AirDrop name plain.pdf' and select AirDrop to Mac : Transfer OK Tap 'Send by AirDrop name accentué.pdf' and select AirDrop to Mac : Transfer fails

(I say “in theory” because LibZip seems to be doing something smarter somehow; even if you overwrite the text file at the same position—at the first entry—saves are still a lot faster than they would be writing the entire 500MB out again.) So, one factor here is just write caching. The more specifically, the write() syscall is returning as soon as data reaches the UBC (Universal Buffer Cache), which is the shared read/write cache for the entire system. This ensures that subsequent reads() return the just written data, even if the read originates from different file descriptors or processes. However, when the data will actually reach the disk is basically undefined, which is why fsync and F_FULLFSYNC exist. What makes copies slow isn't the writes; it's the reads, since the data still has to be pulled off the disk so it can be sent back to write. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I briefly tried to get this to work today using the old Carbon API, which I must confess I'm not super familiar with (before my time), but didn't have any success. Before I posted this thread, I tried what looked like the most straightforward way to accomplish this: No, that won't work. NSFileBusy is looking at ExtendedFileInfo.extendedFinderFlags and checking if kExtendedFlagObjectIsBusy is set. I don't think it's really used today, but my recollection was that this meant “busy” in the file access/locking sense, which is different than the creation case of the Finder. In any case, I'd start by checking/setting kMagicBusyCreationDate. I believe that's the Finder primary mechanism, and, more practically, it's not deprecated and easier to access than type/creator. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Not as far as I can see, Can you file a report that I can share with the relevant engineering team? I think this issue is worth looking at. Please include a sample project with steps to reproduce the issue, note a filename you used also. Reply with the FB number here once complete. One tip I have is, if you are unsure if it's a known issue or not, file the report anyway. This gives us a head start on this investigation and a timeline view if it has been reported previously. Thank you @Claude31 😁  Travis

Q1. Is there an official, complete list of all conditions that trigger expirationHandler? The documentation only mentions time expires. No, but the primary causes are user cancellation and failure to report progress. Theoretically, resource pressure could cause it; however, in practice, I think the system typically ends up killing your app instead[1]. Q2. What is the specific time limit before timeout? If it varies by device state, what are the conditions? There isn't any specific time limit. I've never worked out what the absolute maximum (defined by the progress reporting requirement) is, but that limit would be high enough that it's not really a constraint. Q3. A way to distinguish the reason is needed. User stop and system expiration require completely different handling. Currently, this is impossible. Yes, this is definitely an issue with the API. Please file an enhancement request asking for this, then post the bug number back here. [1] The issue here is similar to (one of…) the reason why memo

Thanks! On device? I do not see any bugs on that part, and I would really encourage you to create a simple focused project so you can show the crash on a device after submitting a bug that I think will be the best approach in this case. Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Albert Pascual
  Worldwide Developer Relations.

Thanks for the detailed response, Albert. Our server API has a strict payload limit of 250 MB per request. Because of this constraint, our existing upload infrastructure uses chunked uploads for large files — splitting videos into smaller byte ranges and uploading each chunk separately via the BITS protocol (CreateSession → Fragment → CloseSession). However, I don't see any API surface in PHAssetResourceUploadJobChangeRequest to: Specify byte ranges for partial uploads Create multiple sequential jobs for chunks of the same resource Provide a callback/delegate pattern for give me the next upload destination Given that the system daemon handles uploads out-of-process (as you explained), it seems this API assumes the destination endpoint can accept the entire file in a single HTTP request. My question then becomes: For services with server-side payload limits, is PHBackgroundResourceUploadExtension the wrong tool for the job? Should we instead: Continue using our existing NSURLSession backgroun

[quote='879858022, hasii2021, /thread/818406?answerId=879858022#879858022, /profile/hasii2021'] I set up the file system as APFS case-sensitive. [/quote] I’ve seen that cause problems in the past. However, I don’t think that’s the case here. I created a case-sensitive APFS disk image, copied your zip archive to that, and repeated my tests there, and everything still worked. But, yeah, a disk image is a great way to test stuff like this. If you managed to figure out what’s causing this, please reply here with the info. I’m super curious. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='879813022, wuzihang, /thread/818722?answerId=879813022#879813022, /profile/wuzihang'] FB22081725 [/quote] Thanks for filing that. [quote='879813022, wuzihang, /thread/818722?answerId=879813022#879813022, /profile/wuzihang'] has [this] been routed to the appropriate Swift/Xcode engineering team … ? [/quote] Yes. [quote='879813022, wuzihang, /thread/818722?answerId=879813022#879813022, /profile/wuzihang'] [is] there is any information about which future Xcode version … ? [/quote] Even if there were, I can’t talk about The Future™ here on the forums. See tip 3 in Quinn’s Top Ten DevForums Tips. This lack of visibility is one of the reasons why I encourage folks with Swift compiler bugs to file their bugs via the Swift bug process. However, that’s not really appropriate here because you need an Apple framework, Combine, to reproduce it. But if you can find a way to reproduce the crash without that dependency, a Swift bug would make a lot of sense. ps In future, if you have existing case