It's end-year 2021, and the file-descriptor method works till now, like: let tunFd = self.packetFlow.value(forKeyPath: "socket.fileDescriptor") as! Int32; . But we need to do: Remove beginning's 4 byte prefix when reading. Maybe prefix with Mac-header instead (if tap-layer packet is required). Later, when writing add back the 4 bytes (and remove any Mac-header instead). See also How to parse network-extension packets?

Still same In Xcode 12.4 (and probably forever). But attaching seems work fine, if you know the trick: Call waitForDebugger(...) method (somewhere you're sure to be executed, by step #5), and place breakpoint after that (at least one). Run App normally (or with debugger). From within Xcode's "Debug" menu, click the "Attach to Process by PID or Name..." entry. In resulting dialog, write your extension-target's Name ONLY (instead of bundle-id), and click "Attach". Start your extension, so that it triggers step #1's logic (and later breakpoint). Now Xcode should be attached and paused on breakpoint; In "Show the Debug navigator" tab (of left sidebar), select extension-process's "Memory" section, then click "Profile in instruments" button. In resulting dialog, click "Profile" button, at last profiler did open, but go back to Xcode and resume the execution (remember was paused on breakpoint). Wait for Debugger (Swift 5 Example) public static func isDebuggerAttached() -> Bool {     var info = kinfo_proc()     var mib : [Int32] = [CTL_KERN, KERN_PROC, KERN_PROC_PID, getpid()]     var size = MemoryLayout.stride(ofValue: info)     let junk = sysctl(&mib, UInt32(mib.count), &info, &size, nil, 0)     assert(junk == 0, "sysctl failed")     return (info.kp_proc.p_flag & P_TRACED) != 0 } @discardableResult public static func waitForDebugger(_ timeout: Int = 30000) -> Bool {     var now: UInt64 = DispatchTime.now().uptimeNanoseconds     let begin = now     repeat {         if isDebuggerAttached() {             // Wait a little bit longer,             // because early breakpoints may still not work.             Thread.sleep(forTimeInterval: 3.0)             return true         } Thread.sleep(forTimeInterval: 0.1)         now = DispatchTime.now().uptimeNanoseconds     } while Double(now - begin) / 1000000.0 < Double(timeout);     return false; } Note that: Once the profiler is attached, for some reason the 15MB memory limit (or whatever) gets removed, and App takes about 3 times more memory!? Just ignore this profiler issues, and somehow count real memory usages :-(

"iOS puts limits on the address space" OMG! The only advantage of 64 bit (vs 32 bit) is/was the support for up to 16 Exa-Byte memory, no system has that much "physical" memory (of course), but at least virtual-address-space should NEVER be limited to physical-address-space. Isn't it time to fix iOS mistakes? (Instead of telling people that mapped files are useless)

Maybe Apple's answerer did not understand what exactly was meant, but coming from Android and knowing nothing of Apple API (except Swift and ObjC++ languages), I will point out what a normal developer would like to know. How to achieve VpnService's protect in an iOS VPN? An iOS App's life ends the moment the views are closed, hence a permanent VPN-Service is ONLY possible in an extension, which is a completely different target than that of your views (because iOS has no Service concept). In addition to knowing above, learn the fact that any socket (aka connection) created from within your extension (aka Provider) is magically excluded (aka protected) from going through packetFlow (aka Tunnel), no matter if it's a Raw-socket made by C/C++ or OOP-Wrapped class in Swift5. Surprisingly enough, actually making your extension's socket go through tunnel is much harder, and you would need to use NEPacketTunnelProvider class's methods: - createTCPConnectionThroughTunnelToEndpoint:enableTLS:TLSParameters:delegate: - createUDPSessionThroughTunnelToEndpoint:fromEndpoint: Note that above are instance methods, which is what minus sign in ObjC means, so only available in extension context (but there is no escaping from the tunnel for App-targets anyway). See also: https://developer.apple.com/forums/thread/94430

No, actually it's #if TARGET_OS_MACCATALYST, also, nowadays TARGET_OS_IOS is defined for both iOS and Mac's Catalyst!! See complete macro list on StackOverflow answer.

Too bad that L2TP is NOT accessible through NEVPNManager class, At least, according to another post of Eskimo - https://developer.apple.com/forums/thread/29909?page=1#675601022!! But there is also mentioned something like, NEVPNManager supports third-party transports (beside the built-in IPsec and IKEv2 transports), with the caveat that you have to develop the protocol yourself.

Too bad that L2TP is NOT accessible through NEVPNManager class, At least, not without the caveat that you have to develop the protocol yourself. But for anyone interested; I will link how codes would look like - https://developer.apple.com/forums/thread/47944 if it was supported.

In our company (where I am developer), my Xcode 12.4 (current latest) App runs fine with my 8 GB RAM, And actually, I even always have 3 GB unused RAM (as cached-files and Xcode only uses about 1.5 GB RAM). To be precise, I have iMac 4K with Core i5 @3 GHz while 70% or 90% CPU is almost always (if not compiling) unused as well. So in short, OMG you are not Bitcoin-Mining! what do you think you need all that 32 GB RAM for???