Singleton in iOS Objective C doesn't prevent more than one instance

Question

I know there are several threads on this, but none answer my questions.

I've implemented my singleton class like this (being aware of the controversy about singletons):

+ (MyClass*) sharedInstance {
    static MyClass *_sharedInstance = nil;
    static dispatch_once_t oncePredicate;
    dispatch_once(&oncePredicate, ^{
        _sharedInstance = [[MyClass alloc] init];
    });
    return _sharedInstance;
}

- (instancetype)init{
    self = [super init];
    if (self) {
        //setup code
    }
    return self;
}

I tried instantiating a different object and compared it to the one returned by sharedInstance with '==' and they were indeed different.

Questions:

Shouldn't creating more than one object of the singleton class be impossible? Isn't that the point? Singleton implementation in Java prevents it.
And if so, how? Should I make a setup method and call it instead of having the init implemented and doing it?
Is this correct implementation?

@Sven That's not very helpful. Could you elaborate? Why shouldn't I be doing it like this? It seems to be the standard. — VeryPoliteNerd, Jun 15 '15 at 11:32
This is nothing else than mutable global state. Not better than global variables. This leads to code that is hard to reason about, hard to reuse and hard to test. Also at some point in time you're probably going to need more than a single instance. If you only need a single instance then create only one. With proper Dependency Injection this is really easy to do. — Sven, Jun 15 '15 at 21:33
@VeryPoliteNerd just mark the `init` and `new` methods as unavailable: ``` - (instancetype)init __attribute__((unavailable("Use +[MyClass sharedInstance] instead"))); + (instancetype)new __attribute__((unavailable("Use +[MyClass sharedInstance] instead"))); ``` *See my answer below for better code readability* — esttorhe, Jul 07 '15 at 17:42

score 15 · Answer 1 · answered Jun 14 '15 at 11:06

Your observation is correct, many of the "singleton" patterns you see in Objective-C are not singletons at all but rather a "shared instance" model where other instances can be created.

In the old MRC days Apple used to have sample code showing how to implement a true singleton.

The code you have is the recommended pattern for ARC and thread-safe singletons, you just need to place it in the init method:

- (instancetype) init
{
   static MyClass *initedObject;
   static dispatch_once_t onceToken;
   dispatch_once(&onceToken, ^{
      initedObject = [super init];
   });
   return initedObject;
}

This code will ensure that there is only ever one instance of MyClass regardless of how many [MyClass new] or [[MyClass alloc] init] calls are made.

That is all you need to do, but you can go further. First if you wish to have a class method to return the singleton it is simply:

+ (instancetype) singletonInstance
{
   return [self new];
}

This method ends up calling init which returns the singleton, creating it if needed.

If MyClass implements NSCopying then you also need to implement copyWithZone: - which is the method which copy calls. As you've a singleton this is really simple:

- (instancetype) copyWithZone:(NSZone *)zone
{
   return self;
}

Finally in Objective-C the operations of allocating a new object instance and initialising it are distinct. The above scheme ensures only one instance of MyClass is initialised and used, however for every call to new or alloc another instance is allocated and then promptly discarded by init and cleaned up by ARC. This is somewhat wasteful!

This is easily addressed by implementing allocWithZone: (like copy above this is the method alloc actually ends up calling) following the same pattern as for init:

+ (instancetype) allocWithZone:(NSZone *)zone
{
   static MyClass *allocatedObject;
   static dispatch_once_t onceToken;
   dispatch_once(&onceToken, ^{
      allocatedObject = [super allocWithZone:zone];
   });
   return allocatedObject;
}

The first time an instance is created then allocWithZone: will allocate it and then init will initialise it, all subsequent calls will return the already existing object. No discarded unneeded allocations.

That's it, a true singleton, and no harder than the faux-singletons that are so common.

HTH

I would not recommend this implementation, since keyword "new" means something to developers, new instance is expected to be return from "new" but not singleton. — Codebear, May 30 '16 at 15:44
@Codebear - The above is essentially Apple's old MRC design from *Cocoa Fundamentals*. The point is there only ever is one object regardless of how many are requested, it is a true singleton. If that does not suit then you use the *shared instance* model (often called singleton) where a factory method provides the shared instance but `new` *et al* still create new distinct objects. Both are valid models, you pick the appropriate one for the circumstances, and in this case the true singleton was what the Question sought help with. — CRD, May 30 '16 at 17:23

Glorfindel · Answer 2 · 2015-06-12T09:38:11.707

5

You can't make the init method private, like you would do in Java with the constructor. So nothing stops you from calling [[MyClass alloc] init] which indeed creates a different object. As long as you don't do that, but stick to the sharedInstance method, your implementation is fine.

What you could do: have the init method raise an exception (e.g. with [self doesNotRecognizeSelector:@_cmd]) and perform the initialization in a different method (e.g. privateInit) which is not exposed in the header file.

edited Jun 12 '15 at 09:38

answered Jun 12 '15 at 09:33

Glorfindel

21,988
13
81
109

You can save up a variable telling whether the `init` has been already called or not, however when the users try to circumvent the public interface, there is really no robust way to prevent them. – Sulthan Jun 12 '15 at 09:42
It's not that I strictly need to prevent it. I just thought it was an important part of the concept with a singleton. – VeryPoliteNerd Jun 12 '15 at 09:55

score 5 · Answer 3 · answered Oct 23 '15 at 07:42

With objective-c, you can prevent your singleton class to create more than one object. You can prevent alloc and init call with your singleton class.

#import <Foundation/Foundation.h>

@interface SingletonClass : NSObject

+ (id) sharedInstance;
- (void) someMethodCall;
- (instancetype) init __attribute__((unavailable("Use +[SingletonClass sharedInstance] instead")));
+ (instancetype) new __attribute__ ((unavailable("Use +[SingletonClass sharedInstance] instead")));

@end


#import "SingletonClass.h"

@implementation SingletonClass

+ (id) sharedInstance{
    static SingletonClass * sharedObject = nil;
    static dispatch_once_t onceToken;

    dispatch_once(&onceToken, ^{
        sharedObject = [[self alloc] initPrivate];
    });

    return sharedObject;
}

- (instancetype)init {
    @throw [NSException exceptionWithName:NSInternalInconsistencyException reason:[NSString stringWithFormat:@"You can't override the init call in class %@", NSStringFromClass([self class])] userInfo:nil];
}

- (instancetype)initPrivate {
    if (self = [super init]) {

    }
    return self;
}


- (void) someMethodCall{
    NSLog(@"Method Call");
}

@end

1# If you will try to call init or new methods on SingletonClass, then these methods would not be available to call.

2# If you comment out mentioned below methods in header file and try to call the init on SingletonClass method then app will be crashed with reason "You can't override the init call in class SingletonClass".

   - (instancetype) init __attribute__((unavailable("Use +[SingletonClass sharedInstance] instead")));
   + (instancetype) new __attribute__ ((unavailable("Use +[SingletonClass sharedInstance] instead")));

Just use this code to create single object to Singleton Pattern and prevent alloc init call for singleton pattern from other classes. I had tested this code with xCode 7.0+ and its working fine.

score 1 · Answer 4 · answered Jun 12 '15 at 10:07

To prevent creating multiple objects of single class, you need to do following things. you just fine to created singleton object. but while calling init, copy, mutable copy, you need to handle such way.

- (instancetype)init{

    if (!_sharedInstance) {
        _sharedInstance = [MyClass sharedInstance];
    }
    return _sharedInstance;
}




- (id)copy{

        if (!_sharedInstance) {
            _sharedInstance = [MyClass sharedInstance];
        }
        return _sharedInstance;
    }

the same things for mutable copy as well. so this implementation make sure that once one instance is available throughout..

May this help you.

Note that this doesn't look thread safe. And the copy method could just return self - there must be an instance around that it's called on. — Eiko, Jun 14 '15 at 11:13

score 1 · Answer 5 · answered Jul 07 '15 at 17:44

1

@VeryPoliteNerd just mark the init and new methods as unavailable on the .h:

- (instancetype)init __attribute__((unavailable("Use +[MyClass sharedInstance] instead")));

+ (instancetype)new __attribute__((unavailable("Use +[MyClass sharedInstance] instead")));

This will cause the compiler to complain if a caller tries to manually instantiate this objects

answered Jul 07 '15 at 17:44

esttorhe

142
1
5

In this case am not able to use init on self. Then how would i alloc and init the my object. – Javeed Jul 15 '16 at 07:19
@Javeed in your `.m` you create a `initInternal` or whatever you want to call it and use that when creating the singleton – esttorhe Oct 27 '17 at 10:21

score 0 · Answer 6 · answered May 30 '16 at 15:15

This works for me:

static AudioRecordingGraph * __strong sharedInstance;

+(instancetype)sharedInstance {

    @synchronized(self) {

        if(!sharedInstance) {

            sharedInstance = [AudioRecordingGraph new];
        }
        return sharedInstance;
    }
}

score 0 · Answer 7 · answered Aug 25 '20 at 19:07

I wanted to add observation for a modern implementation of Objective-C singletons for optimal Swift interoperability. But let me start with the code. Let’s assume for a second that the class was to manage a series of requests, so I might call it a RequestManager:

// RequestManager.h

NS_ASSUME_NONNULL_BEGIN

@interface RequestManager : NSObject

@property (nonatomic, strong, readonly, class) RequestManager *sharedManager;

- (instancetype)init NS_UNAVAILABLE;
- (instancetype)copy NS_UNAVAILABLE;
- (instancetype)mutableCopy NS_UNAVAILABLE;

- (void)someMethod;

@end

NS_ASSUME_NONNULL_END

And

// RequestManager.m

@implementation RequestManager

+ (instancetype)sharedManager {
    static RequestManager *_sharedInstance = nil;
    static dispatch_once_t oncePredicate;
    dispatch_once(&oncePredicate, ^{
        _sharedInstance = [[self alloc] init];
    });
    return _sharedInstance;
}

- (instancetype)init {
    self = [super init];
    if (self) {
        //setup code
    }
    return self;
}

- (void)someMethod { ... }

@end

Note:

Note, I made the singleton a class property rather than a class method.

From the Objective-C side, it is a distinction without difference, but from Swift, you can do things like MyClass.shared without the noise of the (). This is the pattern that Apple has adopted with all of their singletons.
One might give the singleton a more meaningful name. For example, if the class was a RequestManager, the singleton might be called sharedManager rather than sharedInstance.

If you do this, Swift will automatically detect the salient portion of the instance name and will expose it to Swift as shared, not sharedInstance or whatever.

If you really want to use the name sharedInstance in your Objective-C code, then will just need to supply an explicit NS_SWIFT_NAME of shared to adopt the nice, concise, and consistent singleton naming practice in Swift:
```
 @property (nonatomic, strong, readonly, class) RequestManager *sharedInstance NS_SWIFT_NAME(shared);
```
Note the use of NS_UNAVAILABLE. This prevents callers from accidentally instantiating their own copies. E.g. from Objective-C:

Or from Swift:
Probably needless to say, I’ve audited this for nullability, namely using the NS_ASSUME_NONNULL_BEGIN/END to make the default non-null. Or, obviously, you could just mark the singleton property as nonnull.

score -1 · Answer 8 · answered Jul 07 '15 at 18:38

-1

Calling alloc / init to get a second instance of a Singleton class is considered a blatant programming error. To avoid this kind of programming error, you don't write complicated code to prevent it, you do code reviews and tell off everyone trying to do it, as you would with any programming error.

answered Jul 07 '15 at 18:38

gnasher729

51,477
5
75
98

Yes, it's a coding error, but your recommendation for preventing this is not a good one. As other answers here show, there are much better ways to tell the user that he's doing something wrong than requiring them to figure this out themselves with peer reviews, training or documentation. – Thomas Tempelmann Mar 27 '21 at 19:33

score -2 · Answer 9 · answered Jun 12 '15 at 10:59

-2

This works for me :

static DataModel *singleInstance;

+ (DataModel*)getInstance{
    if (singleInstance == nil) {
        singleInstance = [[super alloc] init];
    }
    return singleInstance;
}

You can call it with

_model = [DataModel getInstance];

answered Jun 12 '15 at 10:59

kursus

1,396
3
19
35

4

Completely broken when multiple threads are used. The dispatch_once is there for a reason. – gnasher729 Jul 07 '15 at 18:35

Singleton in iOS Objective C doesn't prevent more than one instance

9 Answers9

Linked

Related