Hi, I'm trying to use the FileProvider Diagnostics Profile for macOS to get more details while debugging my FileProviderExtension. But when installing it it says its already expired: Any chance of getting an updated one that's not expired?

In iOS 15, when an app showed a Safari View Controller, the sourceAppIdentifier provided to a NEFilterDataProvider would be related to the app that used the Safari View Controller. E.g For a SFVC shown in Google Docs it would be EQHXZ8M8AV.com.google.Docs But in iOS 16, depending on whether it is for a Browser Flow or a socket flow, the identifier is now always given as either .com.apple.WebKit.Networking for Browser flows or .com.apple.mobilesafari for socket flows. This now means it is no longer possible for a NEFilterDataProvider to know which app is responsible for that flow and as such cannot use the sourceAppIdentifier in any decision as to whether to allow or drop the flow. Was this an intentional change? If so, why?

In iOS 16, UIDevice.name has changed to only return the model of the device, not the user specified name. There is an entitlement, com.apple.developer.device-information.user-assigned-device-name that can be requested to keep the old behaviour, but I can't find any info on how to request that entitlement. Anyone able to help?

Hi, Our education app needs to be able to pick up the UPN of the currently logged in user on a Shared iPad set up via Apple Schools Manager. I haven't been able to find any information about how to get such info, but I imagine I'm not looking in the right place. Is such a thing possible, and if so, how? Thanks

Hi My code reads a bunch of URLs from a file and does something with each one. swift for line in everyLineFromSomeTextFile { guard let url = URL(string: line) else {continue} doSomethingWith(url) } I recently noticed that some of the lines in the file had wrongly encoded path portions. e.g: https://www.apple.com/us/search/caf%e9 (Or see here if the forum munges that up) Badly Encoded - https://developer.apple.com/forums/content/attachment/14fa4686-ba0a-46ba-8129-4fe9cb965a6c This looks like it was incorrectly percent-encoded from ISO 8859 character set instead of UTF8 as I am sure the last path component is meant to be 'café' when unencoded . However my code didn't skip that line as URL(string: line) didn't return nil. But url only contained the scheme and the host. The path was empty. I tested what URLComponents also did with that string and it gave a similar result - valid scheme and host but empty path. However URLComponents.percentEncodedPath actually returns the original malformed path: /us/search/caf%e9 To complicate things further: url.absoluteString == "https://www.apple.com/us/search/caf%e9" Surely both of those initializers should fail if the string can't be properly and fully parsed? As it happened, my code went ahead and incorrectly did: doSomethingWith(url) where url was https://www.apple.com I haven't even looked at what would happen if the host, query or fragment components were also incorrectly encoded in my source. I realise that URL and URLComponents are just wrappers around NSURL and NSURLComponents, but they behave the same too. (the url string wasn't really an Apple one - I used that for simplicity)

Am I right that .auto is just the default privacy specifier for when an explicit one is not mentioned in the log code, and as such there is no need to ever use it explicitly? swift var i =123 var s = "hello" myLogger.log("\(s, privacy: .auto), \(i, privacy: .auto)") produces the same log as: swift myLogger.log("\(s), \(i)") and that s == "private" in the logs and i == 123 Also in: swift myLogger.log("\(s, privacy: .auto(mask: .hash)), \(i, privacy: .auto(mask: .hash))") that only s will be hashed as i resolves to being public so no masking is needed and 123 is displayed. (The documentation could really use some actual examples of more use cases)

So I've enabled Hardened Runtime on my app but want to test it actually does what it is meant to do.So I put in a simple couple of calls to location services on a button: CLLocationManager* locMan = [CLLocationManager new]; [locMan startUpdatingLocation];and expected my app to crash on Mojave since I hadn't ticked the "Location" option in the "Resource Access" section of the Hardened Runtime capabilities.Instead it carried on as normal and I saw the Location StatusItem show up in the menu bar with my app listed as something that was using Location services.So now I'm wondering if Hardened Runtime is really turned on for my app or not. Or am I misunderstanding its usage?FYI - My app is distributed via Developer ID provisioning, not the App Store.

Trying to convert some code over from NSURLConnection and noticed that the timeouts are per-session, not per-task. In our existing code there are a few places where some requests are given longer timeouts then the others.I see that in NSURLSession the timeouts are all session based. i.e one-size-fits all. There seem to be a couple of options to be able to fine-tune the timouts per-task:Use different sessions for each different timeout. Not pleasant and goes against the idea of having one session-per client-server pairing.Set the Session timeout for each task at task creation time. Not even sure this would work and if it did would need additional multithreading safeguards to ensure only one task at at time can be created.Anyone else had to deal with this oversight?