I’m using Apple’s Network framework to implement a UDP client using NWConnection, and I have a question regarding the lifecycle guarantees provided by the Network framework for NWListener and NWConnection when an iOS application transitions to the background and is subsequently suspended. I was going through this Technical Note TN2277 (specifically the Listening socket section), which describes that if the app has gone into the background and eventually gets suspended, then even though the underlying socket is still active/functional, new connections might be immediately rejected by the kernel. In the scenario where the system suspends the app and later reclaims the resources from underneath the listening socket, the app will no longer be able to listen for incoming connections. On resumption, it might be possible that the app is not even notified that the underlying resource has been reclaimed. Relevant Quotes from the Tech note: Once your app goes into the background, it may be suspended. Once it is suspended, it's unable to properly process incoming connections on the listening socket. However, the socket is still active as far as the kernel is concerned. If a client connects to the socket, the kernel will accept the connection but your app won't communicate over it. Eventually the client will give up, but that might take a while. Thus, it's better to close the listening socket when going into the background, which will cause incoming connections to be immediately rejected by the kernel. If the system suspends your app and then, later on, reclaims the resources from underneath your listening socket, your app will no longer be listening for connections, even after it has been resumed. The app may or may not be notified of this, depending on how it manages the listening socket. It's generally easier to avoid this problem entirely by closing the listening socket when the app is in the background. Does the above hold true for Network Framework UDP sockets, or is the stateUpdateHandler of the corresponding NWListener executed on resumption, indicating that the socket has been reclaimed and the state is either cancelled/failed (non-recoverable) or waiting (recoverable)? If yes, should the app close the NWListener when going into background since it might not be able to determine whether the underlying socket resource has been reclaimed or not on resumption? Additionally, for NWConnection client/accepted-client sockets, does the same semantics apply?

I’m using Apple’s Network framework to implement a UDP client using NWConnection, and I have a question regarding the lifecycle of the DispatchQueue associated with an NWConnection instance. Let's assume I have an NWConnection instance, and I associate it with a dispatch queue using the start(queue:) API, such that network OS events for the NWConnection instance can be delivered to this queue. My understanding is that this association would result in NWConnection holding a strong reference to the DispatchQueue object. Now, I perform some I/O (send/receive) on the NWConnection instance and immediately perform the following steps. Also, assume that the completion closures for those I/O operations do not capture or otherwise retain the NWConnection. Call connection.cancel() and then release my last strong reference to the NWConnection. Without waiting for the connection to transition to the .cancelled state, I also release my last strong reference to the associated DispatchQueue. My question is: Does NWConnection, during its teardown, retain the DispatchQueue until the cancellation completions for all pending I/O operations associated with the connection have been delivered/executed, given that the application no longer holds any strong references to either the NWConnection or the DispatchQueue? Or, once cancel() is called, does NWConnection immediately release its reference to the DispatchQueue, in which case whether the pending callbacks are ultimately executed depends on whether the application has kept the queue alive?

Hi, I’m using Network Framework to implement a UDP client via NWConnection, and I’m looking for clarification about the correct and fully safe shutdown procedure, especially regarding resource release. I have initiated some pending receive calls on the NWConnection (using receive). After calling connection.cancel(), do we need to wait for the cancellation of these pending receives? As mentioned in this thread, NWConnection retains references to the receive closures and releases them once they are called. If a receive closure holds a reference to the NWConnection itself, do we need to wait for these closures to be called to avoid memory leaks? Or, if there are no such retained references, we don't need to wait for the cancellation of the pending I/O and cancelled state for NWConnection?

Hi, I’m using Network Framework to implement a UDP listener via NWListener. I am looking for clarification about the correct and fully safe shutdown procedure, especially regarding resource release. After calling listener.cancel(), do we need to wait for the .cancelled state before exiting the application? Or can we just exit once the cancellation is initiated, assuming the OS will close the NWListener and there will be no resource leak? Is it recommended (or required) to set newConnectionHandler = nil when shutting down a UDP listener? My understanding is that if there is no NWListener attached, then whenever a connection is accepted by the OS, it will not be delivered to the application and the OS will simply drop it.

Hi Everyone, I have a query regarding capturing an NWConnection instance inside the receive closure, which gets invoked whenever some raw bytes are received. I want to know whether this will create a strong retain cycle or not. My understanding is that NWConnection holds a reference to the closure, and if I capture the NWConnection instance inside the closure, the closure will have a reference back to the connection, which, according to my understanding, creates a strong reference cycle. Is my understanding correct? If so, how can we break the strong reference cycle — using a capture list, or is there any other way as well? Thanks

I was exploring the scenarios where an NWListener or NWConnection can be invalidated or reclaimed by the OS itself. I came across the document TN2277: Networking and Multitasking, which discusses situations where iOS can reclaim the underlying socket descriptor. The document states: while the app is suspended the system may choose to reclaim resources out from underneath a network socket used by the app, thereby closing the network connection represented by that socket. From this, I understand that when the app is in a suspended state, the OS may reclaim the socket descriptor. My questions are: In what scenarios does the OS not reclaim the socket descriptor while the app is suspended, and in which cases does it reclaim it? When reclamation occurs, does the OS reclaim 'a' single NWListener/NWConnection, or does it reclaim 'all' NWListener/NWConnections opened by the application? Thanks.

Hi, I am exploring Closures and trying to understand how they works. Closure have a special key feature that they can capture the context of the variables/constants from surroundings, once captured we can still use them inside the closure even if the scope in which they are defined does not exist. I want to understand the lifecycle of captured variable/constant i.e., where are these captured variables stored and when these get created and destroyed. How is memory managed for captured variables or constants in a closure, depending on whether they are value types or reference types?

I have a Class defined in C++, I want to pass the instance of class from C++ to Swift as a reference type. By default swift maps C++ classes as value types but we can change this behavior by using SWIFT_IMMORTAL_REFERENCE annotation mentioned here. The example mentioned here is of Singelton class but I have a usecase where i require more than one instance. Cpp Class Skeleton. class Cpp { public: void Print () noexcept; void SetValue (int pValue) noexcept; // Method which is Invoked by Swift. static Cpp& ReturnObj () noexcept; private: int vValue; } SWIFT_IMMORTAL_REFERENCE; Definition of Return Obj Cpp& Cpp::ReturnObj () noexcept { static Cpp obj; return obj; } Swift Co var obj : Cpp = Cpp.ReturnObj() withUnsafeBytes(of: &obj) {(pointer : UnsafeRawBufferPointer) in print (pointer) print (pointer.baseAddress!) } Output Address Printed by C++ 0x100008000 Address Printed by Swift 0x00007ff7bfeff108 So from the above observation copy is passed. How to do pass by reference then?

I have a Usecase where I want to pass user-defined swift structure instance from Swift to C++ as argument to the C++ Function. In the documentation it's mentioned that swift exposes these structures to c++. Swift Structure. public struct MyStruct { public init (_ pValue : Int) { uValue = pValue } public var uValue : Int } I am able to Create Instance in C++ . Code void CppClass::CreateSwiftStruct () { Interop::MyStruct my_struct = Interop::MyStruct::init (20); } But when I define a C++ Function which takes Interop::MyStruct as argument then that function doesn't get exposed to swift, so i am not able to call it. Skeleton For CppClass class CppClass { static void PassStruct (Interop::MyStruct pStruct); static void Test (); } Here PassStruct Method doesn't get exposed to C++ but Test does. How can I pass Struct Instance in swift to C++ Function as In Param?

I have a struct defined in Swift, i want to pass it's instance pointer from swift to C++. When I am trying to directly return Typed Pointer from Swift Function to C++, the function doesn't get expose to C++. Code which i have tried. // Defined Structure public struct MyStruct { public init (_ pValue : Int) { uValue = pValue } public var uValue : Int } var my_struct = MyStruct(20) // Function which returns Struct Pointer to C++ // When I return typed pointer this function doesn't get exposed to C++ public func PassStructPointer () -> UnsafeMutablePointer<MyStruct> { withUnsafeMutablePointer(to: &my_struct) { pointer in return pointer } } But when I pass UnsafeRawMutablePointer instead of type pointer then the function does get expose to C++ var my_struct = MyStruct(20) // This get expose to C++. public func PassStructPointer () -> UnsafeMutableRawPointer { return withUnsafeMutableBytes(of: &my_struct) { pointer in return pointer.baseAddress! } } Can we not pass typed pointer of the types defined by us?

I am trying to use the swift type UnsafeMutablePointer directly in C++. According to the documentation mentioned, swift expose this type to C++. But I am not able to use it . void GetPointerFromSwift () { // Calls a swift function to get a pointer. swift::UnsafeMutablePointer<swit::Int> x = Interop::GetPointer () }

I have a use case where I want to return reference from Swift Function just like we can do in C++. This is How we do it in C++: int & ReturnIntRef () noexcept { static int a = 4; return a; } Do we have equivalent of this in Swift ?

When i instantiate a structure defined in swift in C++ and then i pass it to swift function as a IN param, it is passed as a constant value to the function. Here the same structure instance is passed or a copy is created?

When we pass a input to swift function it is passed as a constant, so does copy gets created or not here? public func Test (_ pValue : Int) { print (pValue) } let x : Int = 2 Test (x)

I have a usecase, where I have Data instance as Data is Value type copy will be created on assignment. I want to prevent copying for which I was using this Initializer of Data. Will it prevent copying?.