Also with Swift, if I put this in a playground: import Cocoa var formatter = DateFormatter() var locale = Locale(identifier: "en_US_POSIX") formatter.locale = locale formatter.dateStyle = .medium formatter.timeStyle = .long var dateString = formatter.string(from: Date.now) var data = dateString.data(using: .utf8) print("\(dateString)") print("\([UInt8](data!))") We can see that on a beta OS it's got the non-ASCII space, and on Ventura it's got 0x20.

Yes. NSLocale *enUSPOSIXLocale = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"]; [dateFormatter setLocale:enUSPOSIXLocale]; [dateFormatter setDateStyle:NSDateFormatterMediumStyle]; [dateFormatter setTimeStyle:NSDateFormatterLongStyle]; NSString* dateString = [dateFormatter stringFromDate:[NSDate date]]; And the string will have a non-ASCII space character. But only on the beta OSes.

Our problem is basically that at one specific point in our connection process we're using URLSession with an IP address instead of an FQDN. Before that we use FQDNs, after that we use NWConnection, but at that specific point we need to connect by IP address. With the stricter security checking on the beta versions of the OSes we can no longer programmatically override the trust when we validate the host name internally. This means that we need to get the OS to do it for us. It looks like sec_protocol_options_set_tls_server_name will work for the NWConnections (although we still need to do more testing on that), but we have no solution for the case of a URLSession connecting by IP address. Hostname support for TLS: https://developer.apple.com/forums/thread/708005 - "NWConnection TLSParameters does not provide API to set SNI" https://developer.apple.com/forums/thread/680012 - "Set SNI using nw_endpoint_t or nw_parameters_t?" No support on URLSession https://developer.apple.com/forums/thread/82179 - "Setting SNI hostname for URLProtocol with URLSession" https://developer.apple.com/forums/thread/105057 - "NSURLSession's SNI Support"

On other threads I see that in the past there was no way to tell a URLSession to check for a particular hostname during TLS. Is this still true? It seems like an omission that it wouldn't take much to fix.

We can convert to UTF8 where we first saw the problem, but we can't send that over the internet... I checked into contents, and we use NSDateFormatter's stringFromDate to generate the time, with standard setLocale, setDateStyle, and setTimeStyle. It appears that it's generating a lovely ASCII string except for the first space in " PM PDT" at the end of the date string: e280af 50 4d 20 50 44 54 e280af = sp?? 50 = P 4d = M 20 = sp 50 = P 44 = D 54 = T So that's the root here. Of course we can't use that in any Internet exchange that wants ASCII headers or payload, and an unexpected change in the behavior of NSDateFormatter isn't really cool.

I’ve narrowed down the problem. This code: NSString* nstb = [NSString stringWithFormat:@"[%@] <%@>: %@\n", time, tag, info]; char* cstring = [nstb cStringUsingEncoding:NSASCIIStringEncoding]; Always returns a NULL cstring on the betas. On all previous OS versions it returns a valid cstring. The data in the NSString is all data which can be represented with the ASCII encoding, and the documentation for the function says that it will return NULL only when the data cannot be represented with the requested encoding. This is a pretty fundamental change in behavior.

This is still happening. Only on M1/M2 systems. We also see swift-frontend taking 5GB per-instance, with three of them visible in Activity Monitor. It's bad enough that the systems will sometimes become unusable--a standard build for test will take many hours, and it shows 9GB of swap being used. We can't be the only ones seeing this issue...

This is reproducible with the shipping apps, in the App Stores. No connections needed--as soon as you open the applications there is data written to the files, and the problem can be seen. I've filed two bugs, one for iOS/iPadOS and one for macOS: iOS: FB12663311 macOS: FB12663328

I'll see what I can do. My suspicion right now is that it's something related to the app group, because if write() was broken in a general sense there would have been more noise on the forums about it.

You’re talking about the write system call here, yes? If so, these two statements don’t really gel. If write fails, it returns -1 and sets errno. If the file is getting filled with zeroes, the write succeeded, but it just wrote zeroes. And yet it's happening. write() returns -1 errno is set to EFAULT file size changes by the number of bytes attempted file is filled with 0s I’m not aware of sandbox or security restriction that’d cause that behaviour. It’s either a bug in the file system side of things, or your code has actually passed a buffer full of zeroes to write. The latter is by far the most likely. No, it's not--this happens with the shipping applications, and on earlier versions of the OSes the correct information is written. The only difference is the OS versions. A bug in the betas seems likely, but one question would be why more people aren't seeing it. I recommend you add some temporary logging to your… well… logging (-: that logs a subset of this data to the system log. You can then compare the system log results with the contents of the file. We've done that. When we log to both, we see that we're logging valid data. Kevin

I haven't had time to get back to them with the information, and I haven't found a way around it.

Thanks. I'll look into that. I'll probably need to repro it with a smaller test app because of some of the data in the result bundle for our full app. Kevin

Yes, that was it. Setting Allow Arbitrary Loads for testing worked. Thanks. Kevin

Looks like it might be. I'll take a look at using NSExceptionDomains to get around this when needed. The main use case is testing, not distribution--we really don't want to let people loosen up too much on production setups--so if this is the issue we should be able to build in specific exceptions for test builds. Thanks for pointing out that entry. Kevin

Sometimes, but we take that into account in our code that handles the server cert validation when there's a trust question. It's one reason we have a handler for the server certs. Kevin