Lifecycle of singleton instance after iOS tuned from background - ios

Question

I have EventManager and Reg class singleton (Obj-C):
EventManager
class EventManager : NSObject {
override init() {
super.init()
Reg.shared().id = myId
Reg.shared().delegate = self
}
}
Reg (singleton)
#implementation Reg
//...
+(Reg*) shared{
static dispatch_once_t once;
static Reg *manager;
dispatch_once(&once, ^ { manager = [[Reg alloc] init]; });
return manager;
}
//...
#end
So here is my call in Controller:
class ViewController: UIViewController {
let manager = EventManager()
override func viewDidLoad() {
super.viewDidLoad()
let a = SomeHandler.instance
}
DispatchQueue.global(qos: .default).async {
SomeHandler.instance.registerBlocks({ obj in
let m = EventManager()
}, failureBlock: { (a, b, e) in
let m = EventManager()
}, status: { (a, b, c) in
}) { value in
let m = EventManager()
}
}
I get callback from SomeHandler.instance.registerBlocks sometimes after 10-15 sec when device entered to background and turned back to foreground
My question is: what happens with Reg instance?
If application is always active, each time when I call EventManager() I should get same instance of Reg because its singleton.
But when device enters to background OS deallocs all instances so when user opens app again Reg.shared() should return different instance, is it true?
What happens if old instance of Reg.shared() did some long job like sending HTTP requests?

Answer 1

To further elaborate on Paulw11's comment, please refer to the documentation about an app's life cycle.
A lot of people don't really specify what they mean with "background":
They just pressed the home button so the home screen or some other app is shown on the screen
The just put the device to sleep
They did either of this some time ago
They terminated the app with Xcode or restarted the device, seeing the app in the task manager (double pressing home button), so they assume it is in a background mode
Some other common unclear usages of "background" might also exist, but I think you'll get the picture.
As Paulw11 correctly said the only time your singleton will be deallocated is when the app enters the "not running" state, i.e. it is terminated. Note that this happens in case 4 I listed, but whether the app is listed in the task manager or not is not indicative of it running or not! I'm saying this since I have met people saying "my app just went to background, but when I put it to foreground again it appears all my on-start code is executed again!"
Case 3 can also ultimately result in your app being terminated (i.e. it goes from "suspended" to "not running"), but it needn't be so (depends on device usage and so forth).
The first two cases will result in the app at first entering background mode (your singleton is still there) and then suspended mode (the app is not doing anything anymore, but the memory is still intact, so your singleton won't be re-inited later).
In the end, a (true) singleton will only ever be deallocated when the app terminates, everything else would be grossly mis-using the term (also note that here lies the danger of singletons). The OS doesn't randomly go into your app's memory allocation and takes away its stuff. The only thing it does do is sending the memory warnings to let the app decide how to save memory on its own (if it's not suspended already). Only if even that does not "reign in" the app's resource usage memory is "freed": By killing it entirely.
#Paulw11: I didn't want to steal your answer, so why don't you make one from your comment. snaggs can then accept that. :)