I've just started using xpc_connection_set_peer_code_signing_requirement() and can happily report that it meets all of my needs in terms of validating who my XPC connection is really connected to. However there seems to have been a slight oversight in that the new error XPC_ERROR_PEER_CODE_SIGNING_REQUIREMENT has either not been made public, or is not available to Swift code for some reason. For example: if event === XPC_ERROR_CONNECTION_INVALID { // OK } else if event === XPC_ERROR_TERMINATION_IMMINENT { // OK } else if event === XPC_ERROR_CONNECTION_INTERRUPTED { // OK } else if event === XPC_ERROR_PEER_CODE_SIGNING_REQUIREMENT { // Error: Cannot find in scope }

Filed FB8968738, I'll post here again if anything comes of it.

I am having the same issue. iOS devices work fine, but macOS devices won't connect to the development push service. Bug report: FB8968738

So I read through TN2265: Troubleshooting Push Notifications - https://developer.apple.com/library/archive/technotes/tn2265/_index.html#//apple_ref/doc/uid/DTS40010376-CH1-TNTAG24 and it looks like the problem is that APSD never connects to the *development* iCloud environment on macOS because: I get neither the success nor the failure delegate callback when registering for remote notifications apsctl status shows: daemon status:																Running certificate status:													 Provisioned, using existing certificate app refresh activity:												 Yes connection environment:											 development 	 courier status:														Not connected because there are no eligible topics 			enabled:																Yes 			stream connected:											 No 			connected to service:									 No I'm guessing "there are no eligible topics" means "you are not running any apps that connect to the development environment", so perhaps the problem is that it's not noticing that I'm launching my app that wants the dev environment? I'm kinda stuck at this point though because I don't see any documentation on apsctl that would allow me to troubleshoot further.

I submitted a feedback request to have this added, because right now there doesn't seem to be a way to make Form() containing TextField() look right on macOS because of the missing labels. FB8636648. I suggest you submit a feedback request as well.

Sorry, here is an example. Paste this into a new macOS swiftUI project and do a live preview to see what I mean. import SwiftUI struct ContentView: View {     @State var isPopped = false     var body: some View {         Button("Popover") {             isPopped = true         }         .popover(isPresented: $isPopped, content: {             MyPopover()         })         .padding()     } } struct MyPopover: View {     @State var moreControls = false     var body: some View {         Form {             Text("Text")             Button("Toggle") {                 withAnimation {                     moreControls.toggle()                 }             }             if moreControls {                 Text("More Controls")             }         }         .padding()     } }

I noticed the same issue in an ObjC app that has no swift (or swiftUI) at all so I don't think that's related. Xcode 12.2 beta, iOS/iPadOS 14.0

Using a file with 0700 permissions seems like the best I can do then. Thanks! That fits more easily into my existing design than adding a special install mode to the daemon.

I'm a swiftUI newbie, but so far my experience has been that your cross-platform swiftUI views will be full of #if os(...) And for modifiers, I guess you have to do something like this, which makes it even more annoying /// Workaround since .collapsible isn't available on iOS and there's no way to #if out the modifier function directly extension Section where Parent: View, Content: View, Footer: View {     func noCollapseIOSCompat() -> some View {         #if os(macOS)         return self.collapsible(false)         #else         return self         #endif     } }

Looks like just about anything inside a sheet on macOS doesn't layout correctly. For example: .sheet(...) { 		 NavigationView {             Form {                 Section() {                     TextField("Name", text: $name)                 }                 Section(header: Text("Title")) {                         TextField("Address", text: $address)           								}        			}       }.navigationTitle("New Item") } Looks great on iOS but on macOS has clipped controls, incorrect margines, sections running together with no/incorrect padding, etc.

Wondering the same thing. In particular there doesn't seem to be a way to place items in the toolbar area above a source list on macOS (like in Calendar for example).

Ok I had some more time to experiment. It looks like the package repository must have a branch called "master" for this to work. If the main branch in the package you're trying to import is called anything else, like "trunk" or "main" for example, adding the dependency will fail. This is particularly bad because creating a new package in Xcode (File -> New -> Swift Package...) creates a git repo with a branch called "main", not "master"!

Thanks! I was not aware dispatch had man pages. That explained exactly what I was seeing with the completion handlers. I can't use them the way I wanted, but at least I know what's going on now.

Well, my actual situation is more complicated. I'm creating mutiple channels from the same FD, and each channel has some channel-specific cleanup code that needs to run when it's finished. The final cleanup of the FD happens much later. This is not an insurmountable problem, obviously I could manually call the channel-specific cleanup code when I close the channel, however it would be a lot more convenient and better factored if it was encapsualted in the cleanupHandler and worked like the documentation says.

Regarding programming errors, the documentation specifically states (emphasis mine):"The channel takes control of the specified file descriptor until the channel closes ... It is a programmer error for you to modify the file descriptor while the channel owns it."So this sounds like after I call channel.close() it is ok for me to close the underlying file descriptor. This is the scneario in which my cleanup handler is called. I close the channel, then I close the file descriptor, then my cleanup handler is enqueued. If I don't close the FD, I get no cleanup.Your point about DispatchIO code spiraling out of control is well noted. I'm not too far along on this part of the project, but so far everything has been working as I expected, except for the cleanup handlers, however if weird behavior like this keeps cropping up I'll be prepared to go with a different solution. The key feature that drove me to DispatchIO in the first place is large (100's of MB) asynchronous, cancellable, streaming read operations. I'm definitely open to other suggestions.