“Popping Sound”

I'm surprised that a fileReferenceURL would be cached in a filePathURL at all. My expectation is when calling fileReferenceURL on a file path URL is to get a reference to the file at the exact file path right now if it is there (or nil) and I would have to hold the fileReferenceURL on first access to follow the file around. I can understand that thinking, but it's not the system’s perspective. The system’s view here is that the file reference is considered more authoritative than the path. The reason for this is pretty simple- it's easy for an app to track a path (just store it as a string), but the only way an app can track a file system object is by doing what file references do. The preference for the reference object also ends up masking also sort of common behaviors which would otherwise be highly disruptive. For example, it allows users to rename directories without having to worry about the consequence that might have on whatever files their apps might happen to be interacting with. Based on your previ

I am not familiar with the available AVCapture options, but if you find a case where there is no way to disable features that you are not using please file a feedback report using Feedback Assistant. You should be able to use the Core ML Instruments template to see what other work is executing on the neural engine and identify what feature it may be related to and if you have successfully disabled it. Neural engine utilization As you've noticed, the neural engine is not overloaded in total utilization (only 7%). The issue happens because both your code and AVFoundation are trying to use the neural engine at the same time. If AVFoundation runs first, your Core ML work will need to wait for the earlier inference to finish before it can execute. The first step is to try to avoid the neural engine work from AVFoundation (or as I mentioned, file a feedback report if you find this is not possible). Alternatively you could try to pipeline or offset your work to avoid the contention (although this may add undesirable

Thanks again for the reply, and especially for such a thorough and helpful one! For example, I suspect this doesn't happen if you start with a security-scoped bookmark, which you resolve to a bookmark before each save. Out of curiosity I just tested this, and I still see the bug. To see it yourself, just use the code from my first post but change the savingURL accessor to use a security-scoped bookmark, as follows: private var bookmarkData: Data? // Ask user to choose this via a save panel. var savingURL: URL? { get { var isStale = false if let bookmarkData, let url = try? URL(resolvingBookmarkData: bookmarkData, options: .withSecurityScope, relativeTo: nil, bookmarkDataIsStale: &isStale) { if isStale { // Should really update the bookmark data here... } return url } else { return nil } } set(newURL) { bookmarkData = try? newURL?.bookmarkData(options: .withSecurityScope) setUpSpamSave() } } Then add the following to the top of spamSave() after checking savingURL is non-nil: let didAccess = savingURL.start

Very interesting. Thanks a lot for the detailed responses. As I mentioned briefly in a previous post I stumbled across this commenting out some things to test out an error handling code path. As a result of the matching NSURLFileResourceIdentifierKey the wrong error message was logged. In my app's case this is basically a harmless bug because I do nothing but the behavior did spark my curiousity. In any case I will most likely be removing -getRelationship: calls from app entirely soon. I'm surprised that a fileReferenceURL would be cached in a filePathURL at all. My expectation is when calling fileReferenceURL on a file path url is to get a reference to the file at the exact file path right now if it is there (or nil) and I would have to hold the fileReferenceURL on first access to follow the file around. If caching the fileReferenceURL in the URL itself has been determined to be necessary I'm also somewhat surprised an existing fileReferenceURL isn't cleared/updated when files are manipulated via high level

I observed the same for iOS 18. There is a partial workaround: when authorization status is .notDetermined, request only .provisional authorization when authorization status is .authorized (i.e. after the user chose Keep), request [.alert, .badge, .sound] This way you at least get support for badges and sound, but it is still bad because the Lock screen and Banner settings will still be disabled and I think there is no way to re-request them programmatically. Unfortunately this makes provisional authorization kind of undesirable for many use cases.

[quote='817434021, pawanquantum, /thread/817434, /profile/pawanquantum'] while the tunnel is active in a pre-MFA quarantine state [/quote] I’d like to clarify my understanding of this. First up, what does “MFA” stand for in this context? Second, it sounds like your concerned about this sequence: The system wants to bring up the tunnel. So it instantiates your provider and calls the startTunnel(…) method. Your provider opens a connect to your VPN server. And then calls setTunnelNetworkSettings(…) to bring up the tunnel. However, the tunnel isn’t really up at this point, in that your VPN server won’t forward packets to the networks that the tunnel claims. Is that right? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Calling Objective-C directly from C is certainly possible and can simplify your codebase by eliminating intermediate layers. Additionally, using Grand Central Dispatch (GCD) to manage thread safety and dispatch tasks to Objective-C contexts is a sound approach. Below, I'll outline how you can achieve this, maintaining thread safety and leveraging GCD effectively. Direct Objective-C Function Call from C Assuming you have an Objective-C method you want to call directly from C, you can use the Objective-C runtime functions to achieve this. Here's a step-by-step guide: Objective-C Method Declaration First, ensure your Objective-C method is declared properly. For example: @interface Renderer : NSObject (void)mtlEnd; @end C Function to Call Objective-C Method You can define a C function that uses the Objective-C runtime to call the mtlEnd method: #include void mtlEnd(MTRenderContext mt_ctx) { // Retrieve the class of the render context Class rendererClass = mt_ctx->mt_render_funcs.mtlObj.isa; // Get th

Hi there, The error you are seeing is actually expected behavior due to iOS privacy and security restrictions. Apple strictly prevents apps from initiating an AVAudioSession for recording from a completely backgrounded state. Because of these privacy constraints, you cannot start an audio recording from scratch using an intent (like via a Shortcut or the Action Button) if the app isn't already active. How to make this work: To use an AudioRecordingIntent alongside a Live Activity, the recording session must originally be initiated while the app is in the foreground. Once the session is running and the user backgrounds the app, you can then manage it: Pause and Resume: You can manually pause the recording from the background using a button on your Live Activity. Once paused, you can use an intent triggered from the Live Activity to resume the recording. System Interruptions: If your active background recording is interrupted by the OS (e.g., an incoming phone call, an alarm, or Siri), you can provide

iOS 15 is the minimum supported device for debugging. It sounds like you found at least one of the places where this is documented, the Xcode Support page, in addition to the Xcode 26 Release Notes. For anything older than iOS 15 where you found that you can still connect the debugger to your app with Xcode 26, please consider that a happy convenience for yourself at this time, but you also should not rely on it, and instead look at moving yourself up to the documented minimum supported configurations. — Ed Ford,  DTS Engineer