Post

Replies

Boosts

Views

Activity

NEFilterFlow.sourceAppIdentifier changed in iOS 16 for Safari View Controllers
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?
1
0
721
Nov ’22
Testing Hardened Runtime?
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.
2
0
1.7k
Nov ’18
NSURLSession - Different timeouts per task?
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?
3
0
5.6k
Mar ’16
URL(string:..) and URLComponents(string:...) succeeding when they shouldn't?
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)
1
0
1.9k
Apr ’21
OSLogPrivacy.auto clarification please
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)
1
0
1.7k
Apr ’21
Does OSLog.isEnabled(type: .debug) actually work?
My iOS app has a function that logs a whole load of statistics about a particular object. Since this is only for dev purposes I don't want any of the actual statistics gathering to be run if debug logs are not enabled so I am checking OSLog.default.isEnabled(type: .debug) before doing anything. Here is the basic shell of my code: swift     func dumpStatistics(for item: Any) {         func callSomeVerySlowFunc(_ object: Any) - String {            /* Something much more complicated than this */             return "Hello"         }         guard OSLog.default.isEnabled(type: .debug) else {             NSLog("Not dumping Statistics, debug logging is disabled")             return         }         NSLog("(NSLog) dumping Statistics, debug logging is supposedly enabled")         os_log(.debug, "(os_log)dumping Statistics, debug logging is supposedly enabled")         let stats: String = callSomeVerySlowFunc(item)         NSLog("(NSLog) dumping Statistics: %@", stats)         os_log(.debug, "(os_log) dumping Statistics: %{public}@", stats)     } When "Show Debug Info" is enabled in Console, this is what I get (as expected): (NSLog) dumping Statistics, debug logging is supposedly enabled (os_log)dumping Statistics, debug logging is supposedly enabled (NSLog) dumping Statistics: Hello (os_log) dumping Statistics: Hello When "Show Debug Info" is disabled, this is what I expect to get:  Not dumping Statistics, debug logging is disabled However, this is what I actually do get: (NSLog) dumping Statistics, debug logging is supposedly enabled (NSLog) dumping Statistics: Hello This implies that OSLog.default.isEnabled(type: .debug) is always returning true, but the actual logging code itself knows it's not really enabled. So this has the effect that I go through all the expense of calculating the statistics when I shouldn't. (BTW - I added the NSLog calls to help me see what was really happening. I don't intend to keep them in there) I don't think I am doing anything wrong in my code. I'm running macOS 10.15.7 alongside two iPads, one with iOS 14.3 and one with 14.4. Both iPads are connected via USB
3
1
1.5k
Feb ’21