Después de leer las respuestas a unpregunta sobre singletons en el objetivo C parece que cada solución hace una compensación en lo que respecta al subprocesamiento en el descriptor de acceso de instancia. es decir

@synchronized(self)
{
    if (sharedInstance == nil)
            sharedInstance = [[MySingleton alloc] init];
}
return sharedInstance;

Este acceso esencialmente de subprocesos individuales al singleton, y si es algo que se usa con frecuencia en una operación, parece algo que podría hacer que los subprocesos contengan innecesariamente.

¿Cuál es la desventaja de simplemente usar el objeto de clase como instancia singleton y exponer la funcionalidad a través de métodos de clase, es decir?

@interface MySingleton : NSObject {
}

+ (void)doSomething;
@end

@implementation MySingleton    
+ (void)initialize {
   //do some setup if necessary
}

+ (void)doSomething {
    //do something
}
@end

De esta forma, evitamos hacer el bloqueo + verificación cada vez que queremos hacer referencia al objeto singleton y también podemos eliminar tener que almacenarlo en un ivar local o de método.

Este enfoque también permite que el tiempo de ejecución garantice que solo exista una instancia (el objeto Class) en el sistema en un momento dado.

EDITAR

Aquí hay más que solo enhebrar, con un singleton tradicional generalmente se escribe código como este:

MySingleton *instance = [MySingleton getSharedInstance];
NSObject *someResult = [instance getResult];
//or
if (instance.someProperty) {
  //do something
}

Sin embargo, si su singleton es una instancia de clase, esencialmente elimina la necesidad de llamar a getSharedInstance todo el tiempo. Considera este código:

NSObject *someResult = [MySingleton getResult];
//or
if ([MySingleton someProperty]) {
  //do something
}

Escuché el punto de que debe almacenar sus datos en variables locales estáticas de archivo o en variables globales (qué asco). Pero en realidad no es tan diferente de un singleton tradicional con la excepción de que pierde las propiedades de Objective-C 2.0 (en su lugar, debe usar métodos de acceso tradicionales).

Aquí hay una compensación clave para mí que parece una victoria. En un singleton tradicional, terminas anulando -copyWithZone, + allocWithZone, -retain, -retainCount, -release y -autorelease si realmente quieres hacer las cosas bien.

Esto parece mucho trabajo cada vez que quieres escribir un objeto Singleton simple (resultan ser bastante útiles). Entonces, ¿por qué no simplemente reemplazarlo con esto?

@implementation MySingleton
+ (void)initialize {
    //do your setup
}

- (id)init {
    NSAssert(NO, @"You should read the documentation on singletons.");
}
@end

Es mucho más ligero en términos de código, y a menos que sus consumidores sean realmente astutos, nunca crearán dos instancias.

Ve al punto ya Mi pregunta es realmente esta:

¿Hay algún inconveniente en usar el objeto Class como la instancia de su singleton?

Parece que puede seguir los mismos pasos en términos de seguridad de hilos, eficiencia de memoria, etc. sin tener que recordar anular tantos métodos y accesores o ensuciar su código con verificaciones de instancia.