file uri scheme

[quote='868778022, JianbinWu, /thread/808040?answerId=868778022#868778022, /profile/JianbinWu'] How to distinguish between those … and the real ethernet adapter which insert on my iPad? [/quote] Unfortunately I can’t see a good way to do that on iOS [1]. I think you could make a reasonable case that those additional interfaces should not be returning IFRTYPE_FUNCTIONAL_WIRED, but instead something more indicative of their purpose (like IFRTYPE_FUNCTIONAL_INTCOPROC). If you’d like to see that change, I encourage you to file a bug along those lines. And if you do file a bug, please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] On macOS you have a lot more options, including both System Configuration framework and I/O Kit. Neither of those are API on iOS or its child platforms.

I can’t really speak to the MDM side of this but, in general, it’s not possible to change the ACL on a keychain item without user interaction [1]. The issue is that every keychain item starts out with a default ACL and that default ACL has an entry that requires user interaction to change the ACL. The only way to avoid this is to create the item with a non-default ACL, but if you’re sufficiently on the ball to do that then you might as well just create the item with the right ACL up front. On iOS you can avoid this entire issue by leaning into the ManagedApp framework. Unfortunately that’s not available on macOS )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] To be clear, ACLs are only relevant to file-based keychains, including the System keychain. macOS also supports the data protection keychain, and ACLs are irrelevant there. See TN3137 On Mac keychain APIs and implementations for more background on that.

I see, so quit AppleEvent is kinda like the Windows WM_QUIT message. In that case Electron should already handle that. We definitely will file a bug. In the meantime, the documentataion for Sudden Termination says it's for shutdown. Does Testflight also use it? If so, what is the default value for NSSupportsSuddenTermination if not set in Info.plist? Should we manually set that value to false in our Info.plist? Even worse, our app is a singleton, which means that when the app relaunches, it fails. This is a bit of bad wording on me. To clarify, it's not the app failing to launch, but that our program expects to launch its child processes then communicate with them using domain sockets, but if leftover orphans from previous sessions were present, then we can't open new domain sockets on the same path because the old one is still there. To be pedantic we could try opening on another path, but we haven't implemented that. Currently if this happens then our program shows error and exit. This is what I me

You can use -[NSFileProviderDomain supportsSyncingTrash] to tell the system that the domain does not support syncing the trash. When configured this way, the system will handle trashing of downloaded and dataless files appropriately on your behalf.

Hi @drewolbrich Thanks for filing FB21287011. I'll ensure it's routed to the appropriate team.

We are seeing a strange lifecycle issue on multiple MDM-managed iPads where application(_:didFinishLaunchingWithOptions:) is not called after the device is idle overnight. Even if we terminate the app manually via the app switcher, the next morning the system does not perform a cold launch. Instead, the app resumes directly in: So, my first question here is how sure you are about EXACTLY what's happening. In particular, how do you KNOW didFinishLaunchingWithOptions is not being called? In particular, how does your logging infrastructure work and how far back in time would it track? My concern here is that what's missing here isn't that didFinishLaunchingWithOptions isn't being called, but that the app was actually initialized at some much earlier point in time when the system launched your app into the background and then suspended it, potentially hours earlier than the point you actually opened it. We have full logs from four separate MDM iPads showing identical behavior. Happy to share a minimal reproducibl

In general, no, multiple apps can’t share the same asset packs. The behavior that you’re seeing with AssetPackManager.ensureLocalAvailability(of:) is likely because you have a URL override configured in Settings > Developer (or in the Terminal on macOS). A URL override applies to all apps on the device that were installed for development, so all such apps will discover the same set of available asset packs unless you stop and restart the mock sever with a different set of asset packs when you switch which app you’re actively testing. If you see this behavior without a URL override configured, then please file a feedback report. We would be very interested to learn about your use case for shared asset packs. Please file a separate feedback report that explains your need for such a feature. Thanks!

I found a workaround. To get around the compiler looking for old compiled timelines, I simply duplicaed my scene (immersive) to a new name, pointed to it, and it worked. So, now any time I make a change, I just have to change the name of the file, almost like versioning it... immersive_v1. Thats not ideal, but it worked.

Thanks for providing some code. I was able to reproduce the problem you have described here. 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.

I noticed this with QLPreviewView--images for .apps take forever to load. Zip files too and I'm sure there are other file types I don't know about. I filed FB20797520 back in October. Considering making the thumbnail myself for these certain file types that I've found to be slow because this is degrading my app but I've been somewhat overwhelmed by these types of bugs I really don't want to write another one of these ugly workarounds. Kind of hoping they just fix it in a timely fashion. Fingers crossed. My app is sandboxed, and access to the files is made through the NSOpenPanel first (Macintosh HD folder). I have non-sandboxed app version of an app and QLPreviewView still takes around 30 seconds to load app icon images. In another part of my app I don't use QLPreviewView but load thumbnails with QLThumbnailGenerator. QLThumbnailGenerator seems to load the thumbnail images quickly.

Hey @drewolbrich, Thanks for pointing this out and for filing FB21294645. I've forwarded this to the relevant team(s). Thanks!

Thank you for your response and for taking the time to read the Technical Note. I believe you have now realized that Universal Links function consistently well, but there could be several reasons for their behavior deviating from expectations: When encountering issues related to Apple-app-site-association files and associated domains, particularly when they function correctly on the first attempt but fail on subsequent attempts within the same tab, several potential security and configuration factors could be at play: JavaScript Logic Errors: Although you mentioned that the code execution is identical, race conditions or state mismanagement within your JavaScript could lead to differing outcomes on successive runs. Please verify for such possibilities. Error Handling and Logs: Enhance error handling surrounding the associated domain validation logic and ensure comprehensive logging to capture any discrepancies during the second invocation. By systematically examining these areas, you should be able t