What is the point of retaining a singleton you've accessed?

Question

Is there any point to using retain on a singleton? I believe the whole point of using the singleton pattern is to keep one global object to access from various classes. What would be a case to use retain on such an object?

Generally, the implementation of retain in a singleton class returns self (not singleton instance) like below:

-(id)retain
{
   return self;
}

I recently went through some open source code, and the author repeatedly retained the singleton

object = [[SingletonClass shareObject] retain]

and released it in dealloc.

So when I tried to build this project, it worked at first, then crashed when it attempted to access variables on singleton object later.

What would happen exactly, if I retain a singleton object and attempt to access it?

possible duplicate of [Do I use retain or copy in my singleton?](http://stackoverflow.com/questions/6183434/do-i-use-retain-or-copy-in-my-singleton) — Lithu T.V, Sep 18 '13 at 04:44
It's different question I'm not talking about variable in singleton, I'm talking about singleton object itself. — REALFREE, Sep 18 '13 at 04:46

score 2 · Accepted Answer · answered Sep 18 '13 at 04:52

Just because it's a singleton doesn't mean its lifetime is necessarily the lifetime of the process. For example, you might have some singleton that obtains a resource. But until you need that resource, there's no point in creating it. Likewise, you might know that all instances are done with that resource, so why keep it around? An easy way to keep track of whether a singleton needs to continue to exist is its retain count.

For example, you might have a singleton that represents the video camera built-in to a user's device. There might be different parts of your application that need to access the camera. But it might also be possible to use your app without the camera, or the workflow may dictate that the camera is turned off at some point (for privacy, or whatever). So you don't allocate the singleton until the user initiates an action that starts camera use. They may do several actions with the camera, such as take a picture, scan a QR code, record some video, etc. Then they may end all of those actions and need the memory taken by the camera freed up (especially on a mobile device). So they end those actions. If each camera-related actions retained the camera singleton, then each released it when they were done, you could free up the memory and other resources used by the camera, even though it's still a singleton.

I'm still lost. I kinda get your point tho. But generally `release` method in singleton class is empty and usually. And mostly singleton object's lifetime is whenever user is actively using an application. So I don't see why retain and release methods are used in some place if you ever going to free its memory while application is actively running. — REALFREE, Sep 18 '13 at 05:01

score 0 · Answer 2 · answered Sep 18 '13 at 04:51

Consistency. Make a point of always retaining objects that you keep references to, even if they're singletons, and you won't make mistakes down the road when you forget to retain objects that reference counts do matter for.

score 0 · Answer 3 · answered Nov 20 '19 at 18:54

Never hold on to a singleton. There is no guarantee that the underlying library/class/manager doesn't replace that singleton with a new object in the application's lifetime. The point of a singleton access static method is for the current valid singleton to be available at any time to any caller.

Singletons are written by anyone and there is no guarantee that the singleton is not switched. The only guarantee is that a specific class will only have one existing instance at any time.

If you retain a singleton at some point the object you retained could be invalid or even worse, be completely different from the one being held to by the class singleton() method.

What is the point of retaining a singleton you've accessed?

3 Answers3