Not really at this moment, I'm trying to isolate the issue but not still no clue. I'm guessing the reason is that the legacy code tried to tweak the tab bar controller's view. I see code that added views into tab bar VC's view, after remove it will work fine, but our logic is dead then, so not an option to me. I had an idea to how to create the demo project but that would cost me some time and the top priority for me is to fix our code rather than creating a demo and find the root cause. I have filed a code level support for this, and will post the result if it's our side issue.

sorry typo, Xode should be Xcode

if an Apple FTE see this, I already had a radar:FB9958917, but after 2 weeks, no response at all

@eskimo is fetchCurrentWithCompletionHandler synchronous or aysnchronous in terms of the completion handler? e.g. Our code base using CNCopyCurrentNetworkInfo is synchronous, but if fetchCurrentWithCompletionHandler is aysnchronous for the completion handler, our code base might have a problem. And in terms of mem leak, thew shiny new API is still proposing leaking, I only write a simple for loop with a pool:    for (int i = 0; i < 100000; i++) {     @autoreleasepool {       [NEHotspotNetwork fetchCurrentWithCompletionHandler:^(NEHotspotNetwork * _Nullable currentNetwork) {         NSString *ssid = currentNetwork.SSID;         NSString *bssid = currentNetwork.BSSID;         NSString *network = [[NSString alloc] initWithFormat:@"%@,%@", ssid, bssid];       }];     }   } I'm not sure if it's real leaks. I filed both API with bug number 9936268: https://feedbackassistant.apple.com/feedback/9936268

@eskimo as of 2022-02-25, we came across this thread from another article saying calling CNCopyCurrentNetworkInfo will lead to massive memory leak, with Xcode 13.2.1, iOS 14, while the app has no location auth and call this API. It will return NULL, and lots of internal objects leak, please see attached screenshot. our test code: for (int i = 0; i < 100000; i++) { @autoreleasepool { NSString *ssid = [UIDevice currentWifiSSID]; NSString *bssid = [UIDevice currentWifiBSSID]; } } currentWifiBSSID will be like: NSArray *interfaces = (__bridge_transfer NSArray *)CNCopySupportedInterfaces(); NSString *ssidStr = nil; for (NSString *name in interfaces) { NSDictionary *networkInfo = (__bridge_transfer NSDictionary *)CNCopyCurrentNetworkInfo((__bridge CFStringRef)name); ssidStr = [networkInfo objectForKey:(__bridge NSString *)kCNNetworkInfoKeySSID]; if([ssidStr isKindOfClass:[NSString class]] && ssidStr.length > 0) { return ssidStr.copy; } } return nil; } Any plan to fix CNCopyCurrentNetworkInfo?

Sure I will consider. Thanks for you big support!

Hi @eskimo, I tried CFNetwork Diagnostic Logging today, and I can see the diagnostic log, and indeed, one of the request is missing all the time. I can search and find other brother requests, but the problematic request is not showing up in the diagnostic log. What could go wrong then? The missing request is a NSURLMutableRequest. What are the options that it can ignore the proxy? I mean I wanted to let the request through the proxy, in order to let other team to check and debug the request.

Hi @eskimo, first they are HTTPS requests, and I can see the HTTPS request is sent from the debugger and I can add break points at the response handler, so IMO it's sent. My new first question is, if my iPhone setup a proxy, can I use RVI to capture all iOS traffic on interface rvi0? My current setup is iPhone setup a proxy, and my macOS is the proxy (Charles or Burp), and my macOS is connected to company VPN to test the requests, I used to having trouble that the rvi0 seems not able to capture iPhone's traffic. The new second question is, what possible ways are there that the HTTPS client can ignore the proxy to send a request to server and get response? Because I can see all other requests in Charles, and only this specific request cannot be seen most of the time. Occasionally I can capture once or twice, but it's really random to me.

No the request is not cached. It is sent to server and get get a response back. because it contains timestamp and requesting new resource, not a same URL that can be cached.