Swift and Objective-C interoperability

Working with Objective-C

Exposed to Objective-C

All classes subclassed by NSObject, the methods will be exposed to objective-c

All methods are not private

All methods are not using swift feature

Protocol must be in @objc

Return type must be objective-c understand not (Int, String)? in Swift

anything marked as @IBOutlet, @IBAction and @NSManaged will be available in Objective-C

dynamic in swift for any property will be obversed by KVO also transfer to Obj-c

@objc for anything expose to objective-c

class CalculatorController : UIViewController {
    func performOperation(op: (Double) -> Double) {
    // ...
    }
    //swift knows diffenert function as agruments have different types but not for Obj-c. ERROR in this function
    func performOperation(op: (Double, Double) -> Double) {
    // ...
    }
    //this is okay
    func performBinaryOperation(op: (Double, Double) -> Double) {
    // ...
    }
    //not expose to swift
    @nonObjc
    func performOperation(op: (Double, Double) -> Double) {
        // ...
    }    
}

Error Handling

- (id)contentsForType:(NSString *)typeName error:(NSError **)outError;

is same as

func contentsForType(typeName: String) throws -> AnyObject

which both languages can call each other

@objc enum RequestError : Int, ErrorType {
    case Incomplete = 9001
}
// the enum error from Swift will give the same error in objc
NSError *error;
id result = [controller sendRequest:request error:&error];
if (!result) {
    //failure MyApp.RequestError: 9001
    NSLog(@"failure %@: %ld", error.domain, error.code);
    return nil;
}
// Generated by Swift 2.0.
typedef NS_ENUM(NSInteger, RequestError) {
    RequestErrorIncomplete = 9001
};
static NSString * const RequestErrorDomain = @"...";

nullability

• use the Qualifier for better swift compatibility
• helps to clarify the API should accept nil or not

• Compiler gives warning if nil is not expected

• Use audited Region for wrap all property are not nil

• evaluate values is nullable or not first. and then all the elements in the values array must not nil

Lightweight generic of Objective C

• clarity whats in the collection
• Enable better compiler type checking

@property (nonatomic, strong) NSArray<NSString *> stringArray;

@property (nonatomic, strong) NSDictionary<NSString *, NSString *> stringDict;

• no change to the Objective-C runtimes
• Use the below to remove type arguments

  NSArray<NSString *> *strings = …;
  NSArray *array = …;
  array = strings; // okay, drops type arguments
  strings = array; // okay, adds type arguments
  

"KindOf" type for objective c

• using __kindof to tell the instance is kind of a class or a subclass
• Swift will match the same type for __kindof
• No more isKindofClass checking and typecasting as the type already know

Should still use id in an API?

id has been replaced with more precise type

• instancetype for returning self
• typed collections
• __kindof x * for "some subclass of x
• id<SomeProtocol> for any type conform to SomeProtocol

Use id when there is needed for representing any objects

@property (nullable, copy) NSDictionary<NSString *, id> *userInfo;