I followed a tutorial on SwiftUI and macOS (and wow was it worth it, I understand more of what I was doing wrong before!). After the tutorial was done, I thought, okay, let's try adding CloudKit to it. Which was rather trivial to do, I was impressed. Then I thought, ok, let's try being able to have local or CloudKit, depending on runtime. But when I did that, the file was opened readonly, due to "Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey." This seems to be something a lot of people have run into, but for some reason I haven't found any actual fixes. Anyone know?

Unless I'm missing something (always possible)... there is no way to tell if you get a valid proxy back -- the error handler is asynchronous, and I don't see a way to say "this proxy is valid." Am I missing something?

Just to make sure I'm not once again doing something dumb or stupid: this notification only gets sent to the application that loads & starts the VPN? If I want some other process to be aware of it, I have to use the SC* APIs?

In a deamon, I register using: [[NSDistributedNotificationCenter defaultCenter] addObserver:loader selector:@selector(getNotifications:) name:kProxyStartNotification object:@"MyProxy"]; In the transparent proxy provider, I post using: static let dnc = DistributedNotificationCenter.default() // later Self.dnc.postNotificationName(.proxyStart,                                       object:"MyProxy",                                       deliverImmediately:true) (I also tried putting the same observer code in the containing app, just to be sure.) (Also, btw: the automatic conversion of kProxyStartNotification to Notification.Name.proxyStart is really sweet.) I'm not getting the notification in other processes. I tried putting an observer in the extension, and sure enough that did get the notification, so it is being generated. Just... not leaving my process. I tried checking for sandbox violations, using Quinn's instructions, but see nothing. I also tried [[NSDistributedNotificationCenter defaultCenter] addObserver:loader    selector:@selector(getNotifications:)     name:nil     object:@"MyProxy"]; (and the same in Swift, for the network extension), and -- as can be guessed by my still asking this question -- no luck.

I've got a system extension. There's a daemon that talks to it. Because I want the sysex to be able to reach out on its own, the daemon talks to the sysex over XPC, and passes over an anonymous endpoint, so that either side can initiate a message. This all works pretty well, and I'm happy with it. But the design, as is, means that if the sysex goes away for some reason, the daemon can't ever talk to it again. This shouldn't be too difficult a problem to fix -- I can tell when the XPC connections are invalidated, I just have to wait for the sysex to come back up. I am using notify(3) for this, and this does work. And this is the part that is frustrating, and I obviously think should even be impossible: after starting back up, sending a notification, and getting the anonymous endpoint from the daemon, and setting the connection to an NSXPCConnection, the connection ... gets set to nil. The problem is that since I've written this in Swift, I put an observer on the endpoint and log whenever it changes. And in the log, I see "changing it from nil to ", and then a log message saying "connection is non-nil, as it should be" and then... later it says the connection is nil. Without a "changing it from to nil". I am very, very frustrated.

If I cruelly do a kill -9 on the process, it doesn't seem to automatically reconnect. This surprised me. Is there something I am supposed to do to tell it to do so?

My little network extension is running out of file descriptors. My suspicion is that something in the Security framework is not being deallocated, although even this doesn't make a great deal of sense: The extension looks at each flow, and gets a SecStaticCodeRef for it, finds the pathname, makes a decision, and stores the result of that decision in an NSCache<NSData, NSNumber> where the key is flow.metaData.sourceAppUniqueIdentifier. This goes through a couple layers of abstractions (the cache is in one Swift class, and it calls another Swift class that gets the security info and then returns the pathname, or throws an error). As an example, after running for a couple of days, it has 1074 open file descriptors for /System/Library/PrivateFrameworks/CloudKitDaemon.framework/Support/cloudd -- and only had 732 three hours ago.

Is there a way to see which profiles are downloaded (in ~/Library/MobileDevice/ProvisioningProfiles) in a human-readable method using Xcode? Specifically, I'd like to know what type (and for which certificate(s)) each profile is. Looking at them with emacs is ... annoying, even for me. 😄

Again, none of this is really my choice: our project is multi-platform (specifically, at this time, Windows and macOS). As a result, the people who started 8 hours before I did picked CMake and vcpkg to handle build system generation and 3rd party dependencies. (TBF, I can't blame them for this, since this does work on a Mac, for at least a simple build.) I want to support Apple Silicon, obviously. I can build native on my M1 MBP. (I could, theoretically, use lipo and create a universal bundle, but that would mean manually signing a handful of executables, and then the whole thing, unless I missed a way to do this much more easily?) We're using CircleCI for CI, or maybe github actions in the future. I have not been able to figure out how to use CMake and vcpkg to do a cross build. Not even universal, just "build for arm64 on Intel mac". googling and searching these fora hasn't shown a lot that seems to work (mainly, I think, for the vcpkg side). Which is weird, because one of the things people use CMake for is to build Android and iOS apps, which generally does mean cross-compiling. Does anyone know how to do that? I'm at the point where I'm looking at CocoaPods again -- but that will not work with CMake, so we'll have two completely different build systems, one of which requires a Mac with GUI to add/remove sources/targets.

A bad time to ask, I'm sure, since everyone is busy with WWDC. What is the difference between filterSockets and filterPackets? In terms of code and classes, I mean. (For my very simple test, if I set filterSockets to true, it just doesn't seem to work.) Related to that: with filterPackets set to true, what data is NEFilterPacketProvider.packetHandler getting? It looks like a subset of an ethernet packet on my system (which, in fact, does have wired ethernet!). But it's missing some of the wire bits (the preamble and SFP), and the length is wrong. (Eg., the handler is given bytes of length 1514, but the ethernet length field is 1500 -- but there are 16 bytes before the length field, plus the two bytes of the length/type.) I suppose it's possible it's not an ethernet packet, but it certainly looks like one, just... slightly wrong.

Is it better to Create an NSXPCConnection, keep it around, and create proxies using that as needed, or Create an NSXPCConnection, create a proxy off of it, and then close the connection when done?

I must be missing something obvious here: I've got my packet filter running (yay), but every UDP packet it gets has a destination port of 0. Also I am confused by this other behaviour:             let udpHeader = (bytes + etherHeaderSize + ip4HeaderSize).bindMemory(to: udphdr.self, capacity: udpHeaderSize)             switch Int(udpHeader.pointee.uh_dport).bigEndian {             case 80, 443:                 return true             case 0:                 os_log(.debug, log: Self.log, "UDP port 0: ip_dst = %{public}s", ReadableIPAddr(ipPacket.pointee.ip_dst))                 return false             default:                 os_log(.debug, log: Self.log, "Got UDP packet dest port %#x, ip_dst = %{public}s", Int(udpHeader.pointee.uh_dport).bigEndian, ReadableIPAddr(ipPacket.pointee.ip_dst))               return false             } The case 0 is not used, even though the default prints out a value of 0.

We want to have a login window stay in front and key, until the user signs in. We want it to stay in front even if switching away from it. Now, this does seem possible, since zoom just did it to me while I was getting into a call to discuss this, but I can't figure out how. In this particular case, I am instantiating an NSViewController subclass, and then creating an NSWindow for it to use. I have tried setting the NSWindow.level to all sorts of values, and they don't seem to work. help?

As I've said before, our product uses cmake for building, and vcpkg for 3rd party management. vcpkg does not (yet) support universal builds on the Mac; neither does HomeBrew, and MacPorts kinda does but some of the ports actually think "universal" is x86, x86_64, ppc, and ppc64 and won't build because you can't build ppc anymore. So I have had serious talks with our build and we have reached a compromise where I can now build for arm64 or for x86_64. The next step would be to manually combine the executables, and then re-sign (using our Developer ID). Has anyone got suggestions on how to do that? I can just grab the codesign commands from the build output and use those; is that feasible? (At some point I may insist on having a week or so to try getting vcpkg to build universal, but I don't have that week or so now, so that's not going to happen. I could potentially ditch cmake for the Mac builds, and then I think CocoaPods has all of the 3rd party libraries we depend on, but I'm not positive, and that then introduces guaranteed breakage when the Windows and macOS versions uses different sets of files and versions.)

I put a cromulent plist file in /Library/LaunchAgents; I load it for the current user using launchctl bootstrap gui/501 $plistfile. Great! But if I then log in as a different user, without rebooting, it doesn't run. I can't do a bootstrap for a user who isn't there; I can't do a launchctl load for an agent. This seems like I'm missing something, but googling hasn't helped me a lot. (On top of all that, I am pretty positive this used to work, but I may be thinking back to MacOS not macOS.)