Yep so for asynchronous operation I capture the pointer value of the void* data parameter of my SSLWriteFunc callback so I can send the client hello on my socket write pipeline after returning from SSLHandshake. On Intel the correct bytes for the TLS client hello are still at the address upon returning from from SSLHandshake but on M1 all zeroes :(

The cause of the error has been identified: For asynchronous operation I capture the data pointer (to avoid memcpy) provided by my SSLWriteFunc callback triggered by SSLHandshake calls so I can queue the bytes to be sent on my library's custom kernel queueing pipeline after returning from SSLHandshake. On Intel and iOS arm products prior to M1 support I observe the bytes at this address are still valid after returning from SSLWriteFunc callback but on M1 these bytes are already zeroed. Despite that it doesn't help me in the present I thank you for your response. However, as long as there is production code somewhere still relying on SecureTransport and doing truly asynchronous writes/reads with the underlying socket this matters to the world just not to Apple. What I'm hearing is even though we are savvy enough as a company to make no guarantee we wouldn't do this, we broke expected empirical behavior between the way the library used to operate with CPUs in our old products and the fact that you are developer that spent his slim amount of hard earned disposable income on our new architecture specifically to port his libraries and applications means little to us. But that was always expected and I thought I'd give the forum a try anyway. The reason I'm not ready to tackle updating to Network yet is because I am in the middle of a long winded cross-platform feature addition resulting in significant architectural changes that originated on the other platforms I support. Again, I haven't had the professional cycles across all the fields I am obligated to dig into yet but one of the things I'm skeptical of is that it's going to provide road blocks for async non-blocking + direct BSD socket access that SecureTransport didn't and I know you are Apple and all but I still like to verify the integrity of each and every modern and legacy library you've published independently, and if you left something out of a "modern" replacement that I require I'm going to reach for the deprecated one. I still intended to expose SecureTransport as an option for client code relying on that path after I integrate with Network. I'm not just going to throw that code away. After I shown that I've integrated with Network then will I be worthy a non-boiler plate response when filling a bug report re SecureTransport?

So I've looked into Network.Framework a little further. If Apple wants to anger cross-platform devs by "deprecating" the socket paradigm that's fine and I was even prepared to drink your cool aid despite the weak arguments made during its wwdc introduction about how it's so superior to sockets. However, where you've completely lost me is the inability to queue network operations for sending/receiving and dequeue completion notifications of those operations via kqueue on our own thread pools to avoid your GCD rails. I've been developing for your platforms for long enough and am familiar with the internals of GCD such as to be sure that I don't want your GCD implementation indirectly managing kevents for me. By forcing use of Network you have forsaken any library that wishes to do scheduling itself and I don't really think Apple is qualified to dictate what a network architecture for a multiplayer game engine should look like nor should that be the prerogative of anyone but the engine developer.

Very good, thank you, I will do that. To better pose my report what is the best resource to get an understanding of how Network operates under the hood? Can you point me to the source? Is it even available? To clarify you are saying the entire transport stack from application send/recv to NIC has been moved into userspace such that there are no kernel transitions as in a custom HFT solution? Was AIO completion a la FreeBSD ever once considered?

Sigh I know that you know I have already watched that video and I know you know the answer to my question regarding whether the userspace transport code operates without going through a driver extension/kext to interface with the NIC is not addressed in it. None of this really matters. Regardless of whether all operation is in userspace, the userspace applications still needs to dequeue results with kqueue whether it reaches into the kernel or not on whatever thread pool I choose as the userspace application architect. Duh. Duh, right? GCD uses kqueue internally so it's not even compatible with GCD. Terry spent years porting FreeBSD kernel code to XNU for you. Your OS even has kqueue extensions that FreeBSD doesn't (albeit to my irritation no AIO) used for priority queueing by GCD. Why did you just abandon all that? The conclusion that I've come to with Network.Framework is going to be that which most other opensource network lib devs have arrived at: https://github.com/nanomsg/nng/issues/497 You can't provide any legitimate reasons that it's actually superior to sockets as you claim. I'm not going to waste my time filing a bug report that you have all but guaranteed will never be addressed. Instead of abandoning all the work I've done on my library I will just abandon support for natively provided security on Darwin platforms in favor of 3rd party encryption like I am already using even though it hurts my soul to have to exclude Darwin platforms from full cross-platform feature parity. https://github.com/3rdGen-Media/CoreTransport

Ok my mistake, at ~50 minutes in the the video deterministically expresses that you've moved the Transport layer into userspace but not the entire stack. So you are taking liberties and fibbing when you say you've moved operation into userspace bc you haven't entirely. My point remains, you could have just implemented all this as a pure c api wherein kqueue reads from userspace memory based on some endpoint file descriptor. There are active FreeBSD kernel extensions that do so.

I come back to this a few months later and all traces of the video WWDC 2018 Introducing Network.framework: A modern alternative to Sockets and sample projects have completely been removed from the internet.

Still the case in 15.1. I must have started and stopped the ~8 GB download about 10 times before finding this post. I never install the simulators.

@hassaands Quinn's workaround does not work for me either. When I attach the breakpoints become dotted again as well. Also when I simply toggle between activate/deactivate breakpoints Xcode can't seem to present the appropriate UI update for the breakpoint based on the expected state. Been dealing with this since the release of XCode 15. I have project targeting Mac and iOS targets. Breakpoints have always worked for iOS targets against my old iPad Pro running 15.7 but NOT for Mac targets. Currently using latest XCode 15.3 and Mac OS 14.4. Is this some post-silicon-advent specific bug? Concerning that Apple hasn't been able to offer a fix in a more timely manner.