Our app has a network extension (as I've mentioned lots 😄). We do an upgrade by downloading the new package, stopping & removing all of our components except for the network extension, and then installing the new package, which then loads a LaunchAgent causing the containing app to run. (The only difference between a new install and upgrade is the old extension is left running, but not having anything to tell it what to do, just logs and continues.) On some (but not all) upgrades... nothing ends up able to communicate via XPC with the Network Extension. My simplest cli program to talk to it gets Could not create proxy: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named blah was invalidated: failed at lookup with error 3 - No such process." UserInfo={NSDebugDescription=The connection to service named bla was invalidated: failed at lookup with error 3 - No such process.} Could not communicate with blah Restarting the extension by doing a kill -9 doesn't fix it; neither does restarting the control daemon. The only solution we've come across so far is rebooting. I filed FB11086599 about this, but has anyone thoughts about this?

I got the permission from Apple (yay), and when I generate a profile on the portal, I can select it. But when I download it... it doesn't have it. Looking at the profile on the portal again, it says I have "Enabled Capabilities Endpoint Security, In-App Purchase". (Although how did that get there?)

This has been going on for at least a couple of hours for us: notarizing doesn't complete. Our last job ran for over 90 minutes before CircleCI timed it out. We're using xcrun notarytool submit with the --wait option; it contined to say "Current status: In Progress" for, as I said, 90 minutes or so. (Normally it takes about 70 seconds.) https://developer.apple.com/system-status/ says everything is normal. This does not seem to be the case for us. 😄

#include <stdio.h> #include <sstream> int main(int ac, char **av) { std::__1::basic_ostringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > x; x << "How now brown cow"; return 0; } If I build this on macOS 12, and try to run the binary on macOS 11, it fails because that symbol is not present in /usr/lib/libc++.1.dylib. If I compile it on macOS 11, and run on 11 or later, it works. Is this correct behaviour? Since the dylib version didn't change, I would expect that to mean no ABI changes.

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?

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.

Is it possible to use SwiftData in a CLI tool, or is it only designed to work with SwiftUI?

I asked a similar question last year, and got no responses. I've written a much simpler (no network extension!) case that seems to demonstrate what I'm confused about. Simple app with an XPC service. I have an ObjectiveC class TestObject which has an NSString* and an NSData* (which I never actually use). I have a protocol defined in Swift: @objc protocol XPCTestServiceProtocol { func logData(entry: TestObject) -> Void func logData(entry: TestObject, completion: ((String) -> Void)) } In the Switt XPC service, the code is: class XPCTestService: NSObject, XPCTestServiceProtocol { var totalBytes = 0 var lastName = "" @objc func logData(entry: TestObject) { totalBytes += (entry.data?.count ?? 0) } @objc func logData(entry: TestObject, completion: ((String) -> Void)) { totalBytes += (entry.data?.count ?? 0) completion("Finished") } I've got this code in the ObjC app: id<XPCTestServiceProtocol> proxy = [self.connection remoteObjectProxyWithErrorHandler:^(NSError* error) { self.stopRun = YES; NSLog(@"Proxy got error %@", error); }]; while (self.stopRun == NO) { @synchronized (self) { NSNumber *objNum = [NSNumber numberWithUnsignedLongLong:self.count++]; NSString *objName = [NSString stringWithFormat:@"Object %@", objNum]; TestObject __weak *toWeak = to; #if USE_COMPLETION [proxy logDataWithEntry:to completion:^(NSString *str) { to = nil; }]; #else [proxy logDataWithEntry:to]; #endif } } attached to a start button (and self.stopRun is set by a stop button, this is all super simple). So I run that, start the test, and things start going (122k calls/second it says). According to Activity Monitor, my app is using about 1gbyte after 20 seconds or so. However, if I run it under Instruments' Leaks template... Activity Monitor says it's used only about 60mbytes. (And at the end of the run, Instruments says it's used about 30mbytes.) Now... if I use the completion and a synchronous proxy, then even without Instruments, Activity Monitor says it's 60mbytes or so. Is the memory reported by Activity Monitor real? Or not real?

Even when it is disabled (that is, our app says "don't do anything" and all it does is start logging things). On the mac, when I try to make an outgoing audio-only call (it's a mac mini with no camera), it seems to connect as far as the outside is concerned, but nothing happens -- I get a request on my other devices, with the wrong account, and the mac mini says it's failed while the ipad or iphone keep connected. I am logging everything I can think of in our extensions, and they don't seem to show anything of interest. And I can't figure out what to look for in the entirety of system logs. I do see Messages dropped during live streaming (use log show to see what they were)... but I'm not sure what to look for in the log show. If I try to make a call in, it results in what seems to be an iOS FaceTime bug -- the phone tells me to log into FaceTime. Even though I am logged in.

I thought Swift wasn't supposed to get them, which is part of the reason why I chose to use it for my network extension. But we're getting crashes occasionally, that look like: Thread 4 Crashed::  Dispatch queue: com.apple.NSXPCConnection.user.endpoint 0   com.kithrup.MyApp.NExt                  0x102c4ffe2 MyExt.sendData(_:data:completion:) + 610 1   com.kithrup.MyApp.NExt                  0x102c5091f @objc MyExt.sendData(_:data:completion:) + 255 2   Foundation                              0x7ff81ef97490 __NSXPCCONNECTION_IS_CALLING_OUT_TO_EXPORTED_OBJECT_S3__ + 10 3   Foundation                              0x7ff81ef3fa1f -[NSXPCConnection _decodeAndInvokeMessageWithEvent:flags:] + 2322 4   Foundation                              0x7ff81eef641e message_handler + 206 5   libxpc.dylib                            0x7ff81de24b6c _xpc_connection_call_event_handler + 56 6   libxpc.dylib                            0x7ff81de23947 _xpc_connection_mach_event + 1382 7   libdispatch.dylib                       0x7ff81df2e3b1 _dispatch_client_callout4 + 9 8   libdispatch.dylib                       0x7ff81df47041 _dispatch_mach_msg_invoke + 445 9   libdispatch.dylib                       0x7ff81df341cd _dispatch_lane_serial_drain + 342 10  libdispatch.dylib                       0x7ff81df47b77 _dispatch_mach_invoke + 484 11  libdispatch.dylib                       0x7ff81df341cd _dispatch_lane_serial_drain + 342 12  libdispatch.dylib                       0x7ff81df34e30 _dispatch_lane_invoke + 417 13  libdispatch.dylib                       0x7ff81df3eeee _dispatch_workloop_worker_thread + 753 14  libsystem_pthread.dylib                 0x7ff81e0e1fd0 _pthread_wqthread + 326 The XPC method is func sendData(_: UUID, data: Data?, completion: @escaping (_: Error?) -> Void) It's crashing on address 0x10, so pretty clearly a NULL-dereference. Since this is happening in my extension, it's in Swift (as I said above), so I have no idea what could be NULL without the compiler yelling at me first.

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.)

Because it may be quicker to ask: with a TPP, readData() gets a data size of 0 if the process has finished writing to the network. However, there seems to be no way to find out if it has finished reading from the network, other than to do a .write() and see if you get an error. (I filed a FB about this, for whatever that's worth.) Since the API is flow-based, not socket, it's not possible to tell if the app has set its own timeout. Or exited. So one question I have is: if I do flow.write(Data(count:0)) -- is that a possible way to determine if it's still around? Or will it be interpreted as read(2) returning 0? (Putting this in for testing is difficult, but not impossible -- as I said, this might be the quickest way to find out.)

BUG IN CLIENT OF LIBDISPATCH: Unexpected EV_VANISHED (do not destroy random mach ports or file descriptors) Which, ok, clear: somehow a file descriptor is being closed before DispatchIO.close() is called, yes? Only I can't figure out where it is being closed. I am currently using change_fdguard_np() to prevent closes anywhere else, and every single place where I call Darwin.close() is preceded by another call to change_fdguard_npand thenDispatchIO.close()`. eg self.unguardSocket() self.readDispatcher?.close() Darwin.close(self.socket) self.socket = -1 self.completion(self)

It tells me my certificate is bad (doesn't have a private key), and that it needs me to revoke it so it can generate a new one, and I do that, and it loops forever. Oh and I get email from Apple saying it's been revoked. Not sure if it's related but I also can't use a Developer ID certificate. Also says it doesn't have a private key. I even generated a new certificate using openssl so I could make sure I had the private key and the .csr file and still no happiness. I also managed to kill my login keychain at some point, because why not. I've googled and stackoverflowed and nothing works. This is on macOS 13.6.1, and Xcode Version 15.0.1 (15A507). I am frustrated to the point of tears at this point.

A few hours ago, it took 3 minutes to get the notarization phase of our build done... now I've got one that's been running for 25 minutes and hasn't finished yet. The last time this happened, the waits got up to multiple hours, and the status page didn't get updated.