Depois de ler as respostas a umPergunta, questão sobre singletons no Objetivo C, parece que cada solução faz alguma troca em relação ao encadeamento no acessador da instância. isto é

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

Esse acesso essencialmente de thread único ao singleton e, se é algo que é usado com freqüência em uma operação, parece algo que pode causar threads desnecessariamente.

Qual é a desvantagem de simplesmente usar o objeto de classe como instância singleton e expor a funcionalidade por meio de métodos de classe, ou seja,

@interface MySingleton : NSObject {
}

+ (void)doSomething;
@end

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

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

Dessa forma, evitamos fazer o bloqueio + verificação toda vez que queremos fazer referência ao objeto singleton e também podemos eliminar a necessidade de armazená-lo em um ivar local ou de método.

Essa abordagem também permite ao tempo de execução garantir que apenas uma instância (o objeto Class) exista no sistema a qualquer momento.

EDITAR

Aqui há mais do que apenas encadeamento, com um singleton tradicional, você geralmente escreve um código como este:

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

No entanto, se o seu singleton for uma instância de classe, você basicamente elimina a necessidade de chamar getSharedInstance o tempo todo. Considere este código:

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

Ouvi dizer que você precisa armazenar seus dados em variáveis estáticas locais do arquivo ou em variáveis globais (eca). Mas, na verdade, não é tão diferente de um singleton tradicional, com a exceção de que você perde as propriedades do Objective-C 2.0 (em vez disso, é necessário usar os métodos tradicionais de acessador).

Aqui está uma troca importante para mim que parece uma vitória. Em um singleton tradicional, você acaba substituindo -copyWithZone, +ocallWithZone, -retain, -retainCount, -release e -autorelease se realmente deseja fazer as coisas direito.

Parece muito trabalho a fazer sempre que você deseja escrever um objeto Singleton simples (eles são bastante úteis). Então, por que não simplesmente substituí-lo por este:

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

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

É muito mais leve em termos de código e, a menos que seus consumidores sejam realmente sorrateiros, nunca criarão duas instâncias.

Vá direto ao ponto Minha pergunta é realmente esta:

Existe alguma desvantagem em usar o objeto Class como a instância do seu singleton?

Parece que você pode executar as mesmas etapas em termos de segurança de thread, eficiência de memória, etc., sem ter que se lembrar de substituir tantos métodos e acessadores ou desarrumar seu código com verificações de instância.