In the Apple documentation, it says:
The AppKit and UIKit frameworks process each event-loop iteration
(such as a mouse down event or a tap) within an autorelease pool
block. Therefore you typically do not have to create an autorelease
pool block yourself, or even see the code that is used to create one.
Now, this should be obvious, but I’ll ask for confirmation anyway.
If I’m developing for what would eventually be a background process (via Grand Central Dispatch), but for simplicity I first just put it in viewDidLoad of the very first loading view so that my view actually won’t be shown on the screen until all that (say) 2 minutes of processing is done, then during this two minutes all that default autorelease pool is never freed because it has not gone through the event loop-iteration yet, right? It would be just plain insane to hear a no, but I’m stuck in this growing memory problem, so I’m going to ask for a confirmation and hope for a good news.
If so, I should put my own autorelease block(s). I would still need the autorelease blocks if the processing is done in a background process via GCD, right?
I’ll try to give you a complete answer of both your questions.
Part one. First pay attention to long running operations in the main threads. If for example your operation takes two minutes, the main thread will be blocked until it has completed. From the user point of view, the app will not be responsive for two minutes.
Anyway, yes in the application delegate there is a pool where autoreleased objects are inserted. When the loop ends, the objects inside the pool are released since the pool is drained automatically.
If you have memory problem you could take a look at Use Local Autorelease Pool Blocks to Reduce Peak Memory Footprint. As written in doc you should wrap an operation in a autorelease block. At the end of the block, the temporary objects are released, which typically results in their deallocation thereby reducing the program’s memory footprint.
About the GCD question I would say no. You don’t have to create an autorelease pool when you deal with GCD. Usually, as also written in Do you need to create an NSAutoreleasePool within a block in GCD?, GCD manages an autorelease pool per queue automatically. So, if you have few objects you don’t have to worry about it but if you create a lot of them, yes, create an autorelease pool. The latter allows you to reduce memory footprint as well.
The app is not responsive since the main thread (through the run loop) executes tasks in a sequential order. If you block the run loop the app freezes until the long running operation is finished (I think the app is killed by iOS if you exceed a specific period of time). To avoid this, you could perform (as you wrote) the long running operation in a different thread.
The goal of using thread is to make the application highly responsive but it could lead to various problem like inconsistent data (race condition) or deadlocks.
For further info I really suggest to read The pogo stick of NSRunLoop, Understanding NSRunLoop and NSDefaultRunLoopMode vs NSRunLoopCommonModes.