“file uri scheme”

Oh no, I’m sorry that’s happening for you! I have some suspicions about what could be causing this but I have not seen it happen recently. I think the most helpful thing for us would be the trace file you’re analyzing — that would allow us to open it on our end and reproduce the issues. Can you attach that to a feedback report filed using Feedback Assistant? I’d love to take a look. — Jed

Q1: Yes, I used Migration Assistant to move files to this Mac mini (Apple Silicon). I believe I only migrated files, not the full user account. My previous Mac likely had uid 502 assigned to my user account, which may have carried over to the system directories on this new Mac. Q2: There is only one user account on this Mac. Q3: No, this is a personal Mac, not managed by any organization. No endpoint security software installed. Q4: I don’t believe so. This Mac mini is relatively new and I don’t recall ever disabling SIP. Please let me know if there’s any additional diagnostic information I can provide, or if there’s a recommended fix for the uid mismatch.

@TE2026, ok, thanks for letting me know about not having a developer account. Let me try to get some more info from you here, if you know. What we are able to tell through your report is that there are system directories on your Mac that have a different owning file user than expected, where the directory is owned by uid 502 instead of the expected uid 501, and that's tripping up the device management infrastructure. This is pretty unusual, and it would be helpful to us to figure out how you got into this situation, if possible. Here are some questions to maybe help you think through things, but I'm really looking for anything that you can point out as potentially unusual in how this Mac is set up or used: Have you migrated this macOS user account to different Macs over many OS versions? Is there only one user account on the Mac, or is this Mac used in some sort of a multi-user environment? Is this Mac managed in some way, such as by a company or educational institution, according to institutional IT

Man, there is so much history here... I tried setting the creation date to: 1946-02-14 08:34:56 +0000 right after creating the folder. But it doesn't have the desired effect. Maybe I didn't convert the date correctly? SO, I had a bit of loose time today, so I threw together this test code: // // main.m // create_time_check // // Created by Kevin Elliott on 3/16/26. // #import int main(int argc, const char * argv[]) { @autoreleasepool { NSURL* url = [NSURL fileURLWithPath: @/Volumes/HomeBase/MassiveTestBed/MassiveTestDirOut/TestDir]; NSDate* date = NULL; NSError* err = NULL; if([url getResourceValue: &date forKey: NSURLCreationDateKey error: &err]) { NSLog(@%@, date.debugDescription); } // Jan 24, 1984, the day the mac was announced... const CFAbsoluteTime kAbsoluteTimeMagicBusyCreationDate = -534528000.0; NSDate* magicDate = (NSDate*) CFBridgingRelease(CFDateCreate(kCFAllocatorDefault, kAbsoluteTimeMagicBusyCreationDate)); NSLog(@File is Busy: %d, [magicDate isEqualToDate: date]); NSURL* tar

It sounds like your static library isn't built as an XCFramework that then contains your static library. In essence, your library needs to be built twice, once for iOS devices and a second time for iOS simulators, with both copies and the header files then packed inside of the XCFramework so Xcode then handles all of the details from there. The documentation covers all of the details you need. — Ed Ford,  DTS Engineer

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