How to Fix Memory Leaks in iOS Applications

How to investigate into memory leaks in ios?

Starting from your second question.

With instruments aside, your code is segueing a UIViewController and dismiss it if simple as that, let us not think about retain cycles just yet.

Strong vs Weak vs Unowned –

1- Usually, when a property is being created, the reference is strong unless they are declared weak or unowned.

2- With the property labelled as weak, it will not increment the reference count

3- An unowned reference falls in between, they are neither strong nor or type optional
Compiler will assume that object is not deallocated as the reference itself remain allocated.

What is retain cycle:

Unless there is some other reference to the parent or child, they both become orphaned. But the retain cycle between the parent and child prevent either from
being released and they become wasted memory.

A child should never retain a parent. If anything, use a weak
reference in the child to maintain a reference to the parent.

Now lets take a look on what you have, you are using UINavigationController & segue, well the UINavigationController is a LIFO stack, also according to apple

A navigation controller is a container view controller that manages one or more child view controllers in a navigation interface. In this type of interface, only one child view controller is visible at a time.

So checking your UIViewController deinit function i think you would have no problem telling that the reference deallocated.

Now lets try to look to something else in the UIAlertAction you have this [unowned self].

When to use unowned self or weak self

The only time where you really want to use [unowned self] or [weak
self] is when you would create a strong reference cycle. A strong
reference cycle is when there is a loop of ownership where objects end
up owning each other (maybe through a third party) and therefore they
will never be deallocated because they are both ensuring that each
other stick around.

In the specific case of a closure, you just need to realize that any
variable that is referenced inside of it, gets "owned" by the closure.
As long as the closure is around, those objects are guaranteed to be
around. The only way to stop that ownership, is to do the [unowned
self] or [weak self]. So if a class owns a closure, and that closure
captures a strong reference to that class, then you have a strong
reference cycle between the closure and the class. This also includes
if the class owns something that owns the closure.

And as you said switching both [unowned self] and [self] did nothing.

Now the first question,

Well instruments leak checks are simple its a simply compare the significant increases in memory in the period of time, and compares it all to each others based on whats going on, this is not a 100% description but close, so whenever that green tick pops up it means you passed the test. doesn't mean 100% you are safe yet, you can visually see the allocation in the bottom section of instrument, observe the values changes (increasing/ decreasing) .. if something in increasing without ever decreasing, i think you found you problem.

Looking into your case i don't think you would find one

New empty iOS app has dozens of memory leaks

The release notes for Xcode 10.3 say:

Resolved an issue where running an app in iOS 12.2 or later under the Leaks instrument resulted in random numbers of false-positive leaks for every leak check after the first one in a given run

That sounds exactly like this issue. So it was a bug (a Heisenbug?), and now it’s fixed.

Memory leak in Swift structures - How to fix this?

Although I haven't got a response from Apple neither on the dev forums nor in the bug tracker and I haven't found anything related to this issue in the release notes of the latest beta versions, it seems to be solved in the Swift compiler in Xcode 7 beta 5. (Maybe it also works in beta 4. The last version I've checked was beta 3.)

The demo project doesn't produce the memory leak anymore. The same is true for my app. Yay!

---

Related Topics