Skip to content

Instantly share code, notes, and snippets.

Last active January 6, 2024 07:24
Show Gist options
  • Save steipete/9482253 to your computer and use it in GitHub Desktop.
Save steipete/9482253 to your computer and use it in GitHub Desktop.
Declare on your main init that all other init methods should call. It's a nice additional semantic warning. Works with Xcode 5.1 and above. Not tested with earlier variants, but should just be ignored. A reference to this macro shortly appeared in…
#if __has_attribute(objc_designated_initializer)
#define NS_DESIGNATED_INITIALIZER __attribute((objc_designated_initializer))
Copy link

Interesting. It breaks with the pattern of overriding another initializer and asserting in there with a note that you must use the class' designated initializer. E.g. on a UIView subclass:

  • have your designated initializer -initWithSomeCriticalData:, and
  • override
- (id)initWithFrame:(CGRect)frame {
    NSAssert(NO, @"Use -initWithSomeCriticalData: and supply the critical dataas an argument to initialize an object of CustomView.");
    return nil;


Copy link

If you're gonna do that, it's also a good idea to add -initWithFrame: to your UIView subclass' header file like so:

@interface XXMyUIViewSubclass : UIView

- (id)initWithSomeCriticalData:(id)criticalData;

- (id)initWithFrame:(CGRect)frame  __attribute__((unavailable("Use -initWithSomeCriticalData: instead"))); 


This way you won't only crash at runtime, clang will emit a warning if you try to call the wrong init method.

Copy link

Or if still want to crash at runtime with an assertion you can do that (and this is what I usually do):

@implementation XXMyUIViewSubclass

- (instancetype)initWithCriticalData:(id)criticalData
    // ....

- (instancetype)initWithFrame:(CGRect)frame
    return [self initWithCriticalData:nil];


I think that this can be mixed with @JaviSoto approach because is nice to warning the user with a warning but if you're designing API that need to be used by others you need to enforce this and you cannot rely on the fact that the consumer of your API will necessarily play nice.

Copy link

nzhuk commented Mar 15, 2014

This attribute is problematic in UIViewController subclasses. If you introduce your own init method and mark it as __attribute((objc_designated_initializer)), you'll get compiler warnings even if you do call the designated initializer of the superclass from it (i.e. [super initWithNibName:bundle:] ), since -[UIViewController initWithNibName:bundle:] is documented as designated initializer but not marked as such with this attribute.

Copy link

janodev commented Mar 23, 2014

@lukabernardi unavailable produces a compiler error that prevents accidental misbehavior. Intentional wrongdoers will be able to skip any other check you add.

Copy link

Mazyod commented Jul 9, 2014

@nzhuk This is so stupid :( And when you use the unavailable attribute, you can't redefine that method in the subclass in order to make it available again >__< .. Need.. Swift.. Now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment