iOS Memory leaks , memory graph debugger shows no leaks but in parallel Xcode-Instruments-leaks shows leaks

in my Project When I started to look for leaks in memory graph debugger, I found few and fixed them , and now with memory graph no leaks is found . the problem with Instruments->leaks , sometimes it show leaks and sometimes not , the leaks appears immediately from the beginning as described in the photo, which I barely understand what causes the leaks . if the memory graph shows no leaks can I trust it ? or there is a kind of a leaks which is not caught by memory graph . The code how do I initialize the mainViewController:

  func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    self.window = UIWindow()
    
    let controller = MainViewController()
    let navigationController = UINavigationController(rootViewController: controller)
    let rootViewController = navigationController
    self.window?.rootViewController = rootViewController
    self.window?.makeKeyAndVisible()
           
    return true
        
}

In the 2013 video, Fixing Memory Issues), Apple made a distinction between “leaks”, “abandoned memory”, and “cached memory”, discussed below. For more contemporary discussions, see WWDC 2021 video Detect and diagnose memory issues, WWDC 2019 video Getting Started with Instruments, and WWDC 2018 video iOS Memory Deep Dive.

• Leaked memory is that which can’t be accessed again, memory for which there are no references left, i.e., memory that has been malloc’ed but never free’d.

• Abandoned memory consists of memory that which does have references, but which won’t be accessed again.

• Cached memory is that which might not be used again, held in memory for fast retrieval in case the app needs it again.

The “debug memory graph” excels at finding and visualizing issues arising from strong reference cycles. The “Leaks” instrument will not identify these issues. As strong reference cycles and the like, are more prevalent in Swift code, often the “Debug Memory Graph” is a more fruitful first line of defense.

When debugging memory issues, we worry less about the memory usage between the first and second iterations as we cycle through the app, but rather focus on subsequent iterations.

Anyway, the “Leaks” tool and the “debug memory graph” were focusing on different problems and would generate different results. Leaks does not find strong reference cycles. At the same time, the “debug memory graph” feature has gotten much better at finding traditional leaks.

FWIW, in Swift, strong reference cycles are far more common than traditional malloc-but-no-free leaks. Your Swift code is unlikely to have traditional leaks unless you start delving into manual allocation of buffers, unmanaged Core Foundation API, etc.

And if you are seeing memory growth in your app, before you worry about leaks, make sure it’s not the third memory issue identified in the aforementioned video, namely, cached memory, that which might not be used again, but will be automatically reclaimed when the device runs low on memory.

As an aside, occasionally there are reported leaks buried in the OS or frameworks. If (a) you do not see your target referenced in the stack traces; or (b) the leaks are inconsequental, then I might suggest not worrying too much about them at all. In your case, we’re talking about 384 bytes, not something I’d worry too much about.