How to call an Objective C class method in Swift

Question

On my Objective-C header, I have the following class method declaration:

@interface WXMediaMessage : NSObject

    +(WXMediaMessage *) message;

Answer 1

The problem is the name. Swift does not import factory constructors. It detects these by noticing that the name is the same as the end of the class name.

Change the message method name to something like singletonMessage and all will be well.

If the name is message, you will see this:

But if I change the name to, say, messager, it compiles just fine.

For an analogy, try this:

var thing : HeyHo = HeyHo.ho()

You will get the same error message.

Answer 2

I mean: BUT WHY?

That's what we're left asking. Matt's answer is correct in that renaming the method will fix the problem, but we're still left asking why.

The answer is because Swift actually remaps convenience methods to constructors.

So while we'd have to call the method like this in Objective-C:

[WXMediaMessage message];

In Swift, we should instead be simply calling WXMediaMessage(). In Objective-C, this is the equivalent to calling:

[[WXMediaMessage alloc] init];

---

It's important to note that the actual factory method doesn't get called when we use the Swift default initializer. This will go straight to init without calling the factory wrapper. But best practice would suggest that our factory method should be nothing more than [[self alloc] init];. The one notable suggestion might be a singleton, but if we have a singleton factory method, we should follow the pattern Apple has set, and name our factory method with the "shared" prefix:

+ (instancetype)sharedMessage;

And the following Swift code would be perfectly valid:

let message = WXMediaMessage.sharedMessage()

But if message isn't a singleton, then it should be no more than return [[self alloc] init];, which is what we'd get with the following Swift code:

let message = WXMediaMessage()

And this is what the error message is telling us to do:

'message()' is unavailable: use object construction 'WXMediaMessage()'

The error message tells us to use the default Swift initializer rather than the Objective-C factory method. And this makes sense. The only reason anyone ever wanted factory methods in Objective-C was because [[MyClass alloc] init] looks ugly. All of our initialization should still be done in the init method however... not in the factory method we create because we'd rather not look at alloc] init]...

---

Consider the following Objective-C class:

@interface FooBar : NSObject

+ (instancetype)fooBar;

- (void)test;

@end

@implementation FooBar

- (instancetype)init {
    self = [super init];
    if (self) {
        NSLog(@"initialized");
    }
    return self;
}

+ (instancetype)fooBar {
    NSLog(@"initialized with fooBar");
    return [[self alloc] init];
}

- (void)test {
    NSLog(@"Testing FooBar");
}

@end

Now using the following Swift code:

let var1 = FooBar()
var1.test()

We get the following output:

2014-11-08 10:48:30.980 FooBar[5539:279057] initialized
2014-11-08 10:48:30.981 FooBar[5539:279057] Testing FooBar

As we can see, the method fooBar is never called. But truly, if you're building your Objective-C classes correct with good practice in mind, a class method named as such should never be any more than:

return [[self alloc] init];

And your init method should be handling all the set up.

What's happening becomes more obvious when we use less simply initializers and factory methods.

Consider if we add a way to initialize our class with a number:

@interface FooBar : NSObject

+ (instancetype)fooBarWithNumber:(int)number;
- (void)test;

@end

@implementation FooBar {
    int _number;
}

- (instancetype)init {
    self = [super init];
    if (self) {
        NSLog(@"initialized");
    }
    return self;
}

- (instancetype)initWithNumber:(int)number {
    self = [self init];
    if (self) {
        NSLog(@"init with number: %i", number);
        _number = number;
    }
    return self;
}

+ (instancetype)fooBarWithNumber:(int)number {
    NSLog(@"fooBar with number: %i", number);
    return [[self alloc] initWithNumber:number];
}

- (void)test {
    NSLog(@"Testing FooBar (number: %i)", _number);
}

@end

At this point, note that our .h exposes the fooBarWithNumber: method, but not the initWithNumber: method.

Now let's go back to the Swift code:

let var1 = FooBar(number: 3)
var1.test()

Swift has turned our fooBarWithNumber: method into an initializer: FooBar(number:Int32)

And here's the output:

2014-11-08 10:57:01.894 FooBar[5603:282864] fooBar with number: 3
2014-11-08 10:57:01.894 FooBar[5603:282864] initialized
2014-11-08 10:57:01.895 FooBar[5603:282864] init with number: 3
2014-11-08 10:57:01.895 FooBar[5603:282864] Testing FooBar (number: 3)

Our fooBarWithNumber: method is called, which calls initWithNumber:, which calls init.

---

So the answer to the question, "WHY" is because Swift translates our Objective-C initializers and factory methods into Swift style initializers.

To expand on this further, the problem isn't even just with the method name itself. It's a combination of the method name, class name, AND return type. Here, we've used instancetype as a return type. If we use instancetype, or our specific class type, we run into the problem. But however consider this:

@interface FooBar

+ (NSArray *)fooBar;

@end

And presuming some valid implementation of this class method which matches the class name, but the return type does NOT match our class.

Now the following method is perfectly valid Swift code:

let fooBarArray = FooBar.fooBar()

Because the return type doesn't match the class, Swift can't translate this into a class initializer, so our method is fine.

It's also worth noting that if we choose id as the return type of our method, as such:

+ (id)fooBar;

Swift will let us get away with it... but it will warn us that our variable is inferred to have the type 'AnyObject!' and recommends we add an explicit type, so it'd recommend this:

let var1: FooBar = FooBar.fooBar()

And it'd allow us to do that... but best practice almost certainly recommends against using id as your return type. Apple just recently changed almost all of its id return types over to instancetype.