Lets say you get someone who knows memory management pretty well but forgets they are using a singleton class. So, they alloc/init and then when done they call release. Again, the running code comes back sometime later to the same point and calls alloc/init again....

They are screwed, even though they followed the correct memory management rules. Because you did not override release, the shared instance variable you check in init is not nil, but is now invalid!

No, it's still a valid object, because the singleton owns itself.

There may actually be a bug along those lines in the implementation shown above, though. I really need to put this into version control and write a bunch of tests for it.

I would argue if you are going to override release you may as well do retain as well to match, to keep the retain count at the value you would expect a singleton to have.

Correct. If you do override them, you should also override retainCount, to return UINT_MAX.

Your whole argument about leaving it out is that you are "hiding bugs". But if you override retain/release, by definition it is not a bug to call release on that object, you have changed the meaning for the class in a way that is compatible with the understanding the developer would have about how retain/release work.

Instead what you are doing, is making your application less robust and purposefully introducing a single point of failure that will probably lead to a crash. You are trying to make the code outside your class a little better, at the cost of potential frustration to the application owner who should at all times be paramount in your thoughts as an application developer.

The trouble is you think you are protecting bad coders from themselves but instead you are spreading code with a very nasty subtle bug that might well be overlooked by many programmers. What happens if in testing they only make use of the singleton once, and then call release? Everything works of course because the invalid reference is never used. But then the application reaches the real world, and the infrequently used singleton is finally accessed twice... you have not helped the poor developer at all, you have introduced a crashing bug to thousands of users and forced the developer to learn all about desymbolication.

In fact you aren't even putting just bad coders in peril. Lets say you get someone who knows memory management pretty well but forgets they are using a singleton class. So, they alloc/init and then when done they call release. Again, the running code comes back sometime later to the same point and calls alloc/init again....

They are screwed, even though they followed the correct memory management rules. Because you did not override release, the shared instance variable you check in init is not nil, but is now invalid! So your init code proceeds to return the now invalid instance, and crashing ensues. What did they do to deserve this cruel trick? They were again decent developers following the memory management rules, the only crime was that they did not read the source for the class they tried to use.

At the very minimum, you should override release to throw an exception in debug mode only and not actually release the object. Then the application will work, but any accidental or misguided release calls to the singleton will flag the error to the developer, not the application owner. This gives you the effect of developer guidance you were seeking without peril to the continued operation of the application.

I would argue if you are going to override release you may as well do retain as well to match, to keep the retain count at the value you would expect a singleton to have. But that part I am far more indifferent to since it doesn't really affect execution the way mishandling release can.

The point is that in sharedInstance = self, the sharedInstance is assigned and ownership is passed to the class, which means that the instance must be explicitly retained. In your code this extra retain count comes from the line in +initialize, which is wrong, because that's not the point where ownership is passed (the shared instance is assigned). The line [[self alloc] init] has a net retain count of 1, but there's no assignment, so nobody taking ownership. Therefore it goes against the memory management rules. To make this more obvious, think of introducing a setter method +setSharedInstance: to assign the shared instance; the implementation of that method should contain a retain as is normal for a setter. Just do the count when you follow my recommendations (all three of them).

As for the line self = sharedInstance, remember that self should have a retain count of one coming from the creation independent of what else happens, that is, not counting the global retain count of 1 for the shared instance. This means that it needs one extra retain. Think about when somehow the code would go through this line as it is now: in that case the retain count for sharedInstance would be the same, even though an alloc/init is used to get it, so a following release on the returned object should be valid. Let me rephrase this. Using [[[PRHEmptySingleton alloc] init] release] should be OK. However, if for some reason this would use the last part (for the sake of the argument), then this would lead to the retain count of sharedInstance to be reduced by one, and it would become invalid.

In short, this is the correct code.

+ (void) initialize {
    if (!sharedInstance) {
        // Nobody takes ownership here, so retain count should be balanced to 0
        [[[self alloc] init] release];
    }
}

+ (id) sharedFramistan {
    return sharedInstance;
}

+ (id) allocWithZone:(NSZone *)zone {
    // We should have one more overall retain because it's alloc
    return [sharedInstance retain] ?: [super allocWithZone:zone];
}

- (id) init {
    if (!sharedInstance) {
        if ((self = [super init])) {
            //Initialize the instance here.
        }
        // The class takes ownership over sharedInstance here, so retain explicitly, think of a setter, think of replacing it with
        // [[self class] setSharedInstance:self];
        sharedInstance = [self retain];
    } else if (self != sharedInstance) {
        // We reduce overall a retain count here...
        [self release];
        // ...so we need to balance with an extra retain count here. We should be allowed to follow this method with a further retain.
        self = [sharedInstance retain];
    }

    return self;
}

In -init you have two assignments that are not properly retained.

More like properly not retained. If the caller goes directly to alloc/init instead of going through sharedInstance, retaining the receiver in init will over-retain it (implicit retain by alloc + explicit retain in init). Thus, explicitly retaining in init is not an option if I want to maintain compatibility with the alloc/init path. Without explicitly retaining in init, an autorelease in sharedInstance would probably be the final release and would cause the object's death.

I'm not sure what to do about the Clang warnings. Second static variable, perhaps? (Using the first one in both places would probably beget a dead store warning.)

And the code in +initialize could easily go into +sharedInstance for lazy evaluation.

I want to display custom alerts that can be controlled with the Apple Remote, while [the app] is in fullscreen mode.

This implies that it can be switched in and out of full-screen mode. Is that correct?

E.g. I have an "alert manager" singleton that my code uses to show error messages. One app has a fullscreen mode where I want to display custom alerts that can be controlled with the Apple Remote, while it is in fullscreen mode. So I create a fullscreen alert manager subclass that knows the specific fullscreen stuff for that one app. All code just asks for [MyAlertManager sharedManager]. In the main() function of the fullscreen app, I do a [MyFullscreenAwareAlertManager sharedManager]. Since this is called first, the alert manager singleton is actually an instance of the subclass. All calls to the superclass in shared code modules now transparently end up with the subclass instead Shared code doesn't need to be aware of fullscreen support, no ugly ifdefs, no unnecessary dependencies on the fullscreen display code of one app in other apps.

For this to work, I can't use the +initialize method you have here (because the superclass's initialize always gets called before the subclass), instead, I'm doing that work in my sharedManager method. I use [self class] so the subclass automatically inits a subclass instance.

The only disadvantage of this technique is if other code accidentally refers to a third subclass of the base class first, my calls to the second subclass will go to the wrong kind of object.

To keep your comments in context, here's a record of what the code said:

+ (void) initialize {
    if (!sharedInstance)
        sharedInstance = [[self alloc] init];
}

- (id) init {
    if (!hasInited) {
        if ((self = [super init])) {
            //Initialize the instance here.

            hasInited = YES;
        }
    }

    return self;
}

hasInited was an instance variable.

You could make it even simpler. The hasInited ivar is totally unnecessary, you can just as well check whether sharedInstance is nil. Think about it.

Think about this: Where is sharedInstance assigned?

Also what I miss in your discussion is the reason why you need to override init. The reason is that when you need to instantiate an instance in a NIB, the NIB loader will always use alloc/init, it won't be using your custom class factory method. Of course in code you should always use the class factory method.

It's possible that they're both wrong. You should file a documentation bug.