“file uri scheme”

Could you please file a feedback report and include the sample code that reproduces the issue. Once you do please share the Feedback ID number here for the record. Thanks

Thank you for filing FB22254960 . When your app declares support for public.text in CFBundleDocumentTypes, you're telling the system that your app can open text documents. The document picker respects your declaration and shows both the content types you explicitly request folder and the types your app supports.

Thanks for this interesting post! I'm not an expert on that field nor that API. Hope one of the engineers on that team can jump into this thread for better info. These specific FigXPCUtilities and FigCaptureSourceRemote logs are almost certainly benign internal framework noise rather than a regression or a flaw in your capture pipeline. Looking up the err=-17281 is a CoreMedia error code that, without knowing here, typically points to a minor XPC synchronization hiccup, a port invalidation, or an asynchronous state mismatch during the setup or teardown of the capture session? I believe this logs are for information only and should be removed. Code paths that silently recovered in older iOS versions often have their log levels elevated in newer releases (or beta releases), resulting in console spam. If your AVCaptureVideoDataOutputSampleBufferDelegate is successfully receiving CMSampleBuffer frames and your preview layer is rendering smoothly. You can safely ignore these logs. If you want to temporarily hide t

I confirm the issue is still present on visionOS 26.3.1 and on visionOS 26.4 beta as well. I noticed the issue across different apps using ManipulationComponent. Removing the widgets solves the issue. Not all widgets cause the issue though. For instance, the Photos or Calendar widgets cause the issue while Clock or Weather widgets do not cause any issue in my testings. I did file a Feedback FB22262491.

Thanks for the post, very interesting you went to an approached that will create a duplicate app instead of localization. I would actually focus on the reason you can’t localize in another language as that API has been proven to be great. I think we should focus on that. Apple’s automated systems and human reviewers are trained to flag apps that look and function similarly to existing apps. I believe the primary goal is to keep the App Store clean the preference is that a single app supports multiple languages and features, rather than having separate apps for different regions or languages. I think on the final result having 2 apps on the same region with different languages. If both apps are available in the same region that could be a really bad experience for the users. Let’s focus on the reason you can’t localize. Localization isn't just translating words; it's adapting the software. Developers extract all hard-coded text in the app and put them into a file called. The app then pulls the correct

I found a fix. You can right click an entry in the catalog and select Mark as Reviewed and it will then create an en.lproj folder and file. In source code view you can bulk edit state : new to state : translated for all English values. On build it will also then remove extractionState : extracted_with_value from each entry and all strings will be in the en.lprog strings file.

@AlkensoDev I would recommend to file a bug because I'm unable to reproduce it on the latest release of Xcode. I would also recommend when filing the bug to provide your sysdiagnose as maybe could be something on the set up of your environment. 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.

Sorry for the double post. But just a quick additional question. Am I better off working around the issue by retrying with the Carbon file manager or should I just skip the resource fork in the copyfile callback, then copy it over myself at the end?

Hi Quinn, thanks for the reply. We kind of expect the permissions to disappear when installing an update, but the main problem is that the CGRequestScreenCaptureAccess() doesn't work after that happens until a reboot. We expect that the call should cause the prom[pt to appear to allow the user to re-enable ScreenCapture. I have filed a bug report: FB22261705

Thanks for these answers, but I'm afraid I need a bit more help. How do you go about presenting the activityViewController? Could you show this in a small example app? I had previously written this and it does share but it creates 2 files, and doesn't present any way to rename the file. import SwiftUI import UIKit struct ContentView: View { @State private var showShareSheet = false @State private var textItem1 = @State private var textItem2 = // @State private var shareItems: [Any] = [ // Check out this file!, // URL(fileURLWithPath: FileManager.documentsDirectory.path()) // Replace with a real file URL // ] var shareItems: [Any] { [ textItem1, textItem2 // URL(fileURLWithPath: TinySavedItems) ] } var body: some View { VStack { TextField(enter text, text: $textItem1) .padding() TextField(enter text, text: $textItem2) .padding() Button(Share, systemImage: square.and.arrow.up) { showShareSheet = true } .sheet(isPresented: $showShareSheet) { ActivityViewController(activityIt

I'm experiencing this issue. Copy file works locally for these files but fails when coming from a NAS. Works from Finder in both cases, as previously described above. copyfile does not seem to provide a usable error. The callback is invoked twice and I get : what == COPYFILE_COPY_XATTR stage == COPYFILE_START Then the callback is invoked a second time with: what == COPYFILE_COPY_XATTR stage == COPYFILE_FINISH In both cases my callback function returns COPYFILE_CONTINUE. Then the copyfile function returns -1, errno is not set. Not getting a usable error unfortunately forces kind of jackhammer workarounds. Have you noticed this issue for files without resource forks (but use other xattrs) or is the resource fork the main cause?

That does the thing! Thanks! And, yes, we probably should have documented all of this, so PLEASE file about this and post the bug number back here. I filed FB22260532

The problem turns out to be a corrupt /Library/Preferences/com.apple.networkextension.plist file. This needs to be deleted, such that the system can create a new one. Unfortunately that’s not possible because in Apple’s “infinite wisdom“ even the root user has been degraded to a lowly user account with selective admin privileges, instead of being the God account it’s supposed to be. As a consequence, one must boot into recovery mode, open a terminal session, and then delete the file from there.

[quote='880037022, voidpulse, /thread/792453?answerId=880037022#880037022, /profile/voidpulse'] I see the bug was reported about 8 months ago [/quote] What was your bug number? Tracking down local network privacy issues is hard, and the thing that helps the most is good quality bug reports. For an example of that, see this thread, resulting in FB21858319. The issue described in that thread is a generic one. While the developer who filed the bug did so with very specific steps-to-reproduce, the bug itself is timing dependent and thus can crop up in a wide variety of scenarios. So, it’s possible that this fix will help in your case as well. However, the fix isn’t currently being seeded, so you can’t currently tell whether that’s the case or not )-: I recommend that you monitor that other thread for updates. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com