Teaching an Old Dog New Tricks: Objective-C in the Age of Swift

Teaching an Old Dog New Tricks: Objective-C in the Age of Swift

Everyone seems to love Swift, Apple’s jack-of-all-trades language of the future, but what about Objective-C, everyone’s favorite oddball? Are we destined to trade in our square brackets for a language whose syntax is more generic? Well, probably. But in the meantime, especially for those of us with apps that still target older iOS and OS X versions, the arrival of Swift has ushered in a new set of possibilities for our Objective-C code. Lightweight generics, nullability annotations, and other new features allow us to jazz up our existing code, make our intentions more clear, and make it easier for those newfangled Swift developers to use our code. In this talk, we’ll cover these new additions to the language, learning how our Objective-C code is made better by them. Then, we’ll look at how these new features impact the Swift side of our code, with live previews of the Swift interface as we add them to our classes. When you leave, your Objective-C code will still be Objective-C, but it’ll have a little more spring in its next step.

8d92e9730c561c120200f34e7e50ed46?s=128

Jeff Kelley

May 20, 2016
Tweet

Transcript

  1. TEACHING AN OLD DOG NEW TRICKS OBJECTIVE-C IN THE AGE

    OF SWIFT
  2. None
  3. Why Make Objective-C Better? There’s still a ton of Objective-C

    code in production All of Apple’s frameworks A huge library of open-source projects A huge amount of apps Apps written in Swift import Objective-C code Even if only Apple frameworks Not everyone has moved to writing Swift instead
  4. How Has Objective-C Improved? More expressive with more information for

    the compiler More self-documenting with additional type information Cleaner with fewer casts and nil checks More modern with lightweight generics
  5. What We’ll Cover Today Nullability Annotations Tell the compiler (and

    other developers) when nil is allowed Generics in Apple collection clases Tell the compiler (and other developers) what kind of object is in your collection Generics in your classes Write generic Objective-C code with Xcode integration and compile-time checking
  6. NULLABILITY ANNOTATIONS

  7. Nullability Annotations Decoration for pointers to specify whether or not

    they can be nil NSString * _Nonnull myString = @"foo";
 foo = nil; // Analyzer warning NSString * _Nullable bar = @"bar";
 bar = nil; // A-OK Within method declarations, you can use non-underscored versions - (nullable id)objectAtIndex:(NSUInteger)index; Inside of property declarations, too
  8. Nullability-Audited Regions Often you want to mark an entire header

    file as nonnull, then go through and explicitly mark nullable items Use NS_ASSUME_NONNULL_BEGIN and NS_ASSUME_NONNULL_END to audit an entire region of source code
  9. Nullability Annotations Recap Use nullability annotations to: Better interact with

    Swift when your Objective-C is imported Add inline documentation to methods that accept nil (or don’t) and methods that can return nil (or can’t) Get better compile-time information and warnings to prevent nil- related bugs before they start
  10. GENERICS IN APPLE COLLECTION CLASSES

  11. Generics in Apple Collection Classes Has been on my personal

    wish list since 2008 Define the type of object inside of an array NSArray <NSString *> *arrayOfStrings; NSDictionary <NSString *, NSNumber *> *stringsToNumbersMap; Assist Xcode in code completion pop-ups Compile-time help only; type erasure means no runtime support
  12. Generics in Apple Collection Classes You can constrain membership to

    include protocol conformance: NSArray <id <NSCopying>> *arrayOfCopyableItems; And use the __kindof keyword to allow for easier down casting NSArray <__kindof UIView *> *subviews; UIImageView *imageView = subviews.firstObject;
  13. Generics in Apple Collection Classes Recap Use these generics to:

    Provide inline documentation about your classes’ structure Give the compiler more information about your types Import code into Swift with typed collections
  14. CREATING GENERIC CLASSES IN OBJECTIVE-C

  15. Creating Generic Classes in Objective-C Just like NSArray, NSDictionary, and

    NSSet, you can define your own generic classes @interface NSArray<__covariant ObjectType> : NSObject - (ObjectType)objectAtIndex:(NSUInteger)index; Define a name for the associated type—Apple uses ObjectType for collections, swift-evolution mailing list examples use T ObjectType is now a stand-in for the class
  16. Creating Generic Classes in Objective-C Declare the associated type when

    you create an instance of the class MyObject <NSString *> *foo = [[MyObject alloc] init]; Unlike Swift, this generic system uses type erasure so you can’t get the type back from foo in that example Compile-time checking only—you can cast anything to the object type and pass it to the method Not (currently) imported into Swift
  17. None
  18. Creating Generic Classes in Objective-C Recap Create your own generic

    classes to: Ensure that a given instance is used with the same type of object Provide constraints on the type of object that can be used Impress your friends Write more expressive code that (some day) interacts extremely well with Swift