Storyboard Segues Causing Memory Leaks

Storyboard segues causing memory leaks

You aren't using the modal segues correctly. The way you have implemented it, you are creating a new instance of each view controller when you segue instead of returning to the instance you came from. That is why your memory usage continues to increase.

Before iOS 6, the correct way to handle this was to:

1) define a method such as viewController2Done in view controller 1

2) in view controller 2, create a property called delegate of type id.

3) in prepareToSegue for view controller 1, set delegate in view controller 2 to self
4) in view controller 2, when it is time to return to view controller 1, call [delegate viewController2Done]
5) in viewController2Done call [self dismissModalViewControllerAnimated:YES]

This method still works in iOS 6, but there is also a new unwind segue that can be used instead. To use it, you would define a method in your view controller 1 like so:

Objective-C:

- (IBAction)unwindFromViewController2:(UIStoryboardSegue *)segue
{
    NSLog(@"and we are back");
}

Swift:

@IBAction func unwindFromViewController2(_ segue: UIStoryboardSegue) {
    print("and we are back")
}

Then you'd control drag from the button in view controller 2 to the orange exit icon in the bar above the view controller in the Storyboard. In the pop up, you'd select unwindFromViewController2 and voila, you're done.

What's causing this memory leak?

How are you unwinding from your various view controllers? I note that you mention that when the game ends you're pushing another VC onto the stack, but I presume this VC chain will at some point unwind back to your initial menu? (In essence, I wonder if you're just looping around, hence adding new VCs to the stack everytime you play a game.)

To create an un-wind segue, simply create an empty method in the destination VC (i.e.: your main menu) as such:

- (IBAction)unwindToMainMenu:(UIStoryboardSegue*)sender
{
    // Intentional NOP
}

(N.B.: Make sure it's also listed in the header.)

You can then call this as you would any other segue in your storyboard by dragging from the source object in question to the exit option at the top of the VC that contains the source object in the storyboard. This will present you with a list of segues to choose from. (You can verify that the segue is setup correctly by selecting the source object in the storyboard - the Connections inspector should list the unwind segue within the Triggered Segues section.)

Any memory leak (or over-instantiation of objects) when using iOS Storyboard Seque Model or Push style?

@trapper is absolutely correct. You segues will stack them up, but it won't leak as long as you dismiss your "modal" with dismissViewControllerAnimated:completion: or pop your pushed view controller with popViewControllerAnimated:. If you erroneously have a segue from your login/register screen back to the main view, then that memory won't be released (which isn't technically a leak, but it's wrong and you won't release the memory).

XCode: Memory Leak When Performing Modal Segue

What you are doing is not going "back" but rather, you are presenting a copy of the previous view on top of the one you already have. That's why memory is building up, because you just keep stacking more and more views on top of eachother. Assuming you are using a modal segue to present your chat view, try calling:

[self dismissViewControllerAnimated:YES completion:nil];

iOS Photo Gallery Memory Leak / Crash when using Push Segues

To resolve this issue I simply resized the images - I noticed I accidentally used a gigantic (6000 x 4000) image and even though I compressed the images iOS had to crunch pretty hard to resize them into the view... thereby causing the memory leak and subsequent crash.

Resizing them to 600x400 did the trick.

How do I clean up UIViewController instances created by Storyboard Segues?

It turns out, in my case, the thing holding a reference to my controllers (question #1) was a scheduled NSTimer that the controller was creating with itself as the target. To clean it up (question #2), I needed to invalidate the timer prior to leaving the controller (in my case, in the viewWillDisappear: method) via [myTimer invalidate].

I still haven't found the answer to question #3, and I'm still curious to know how Apple keeps track of which controllers are still alive and, therefore, need the memory warning, but question #3 isn't as important to me, anymore, now that my memory leak is gone. :)

---

Related Topics