In Swift, structures are very similar to classes, but in Objective-C, they are much more different. Structures in Objective-C are essentially just a way of giving a name to a collection of individual types. They cannot contain methods. Even more restrictive than that, structures can't contain Objective-C types. This leaves us with only basic possibilities:

struct Cylinder {
    var radius: Int
    var height: Int
}
var c = Cylinder(radius: 10, height: 10)
typedef struct {
    int radius;
    int height;
} Cylinder;
Cylinder c;
c.radius = 10;
c.height = 5;

Structures in Objective-C start with the keyword typedef, which is short for type definition. This is then followed by the struct keyword and the different components of the structure contained within curly brackets. Finally, after the curly brackets is the name of the structure.

Advanced C programmers will do a lot more with structures. There are ways to simulate some features of inheritance with structures and to do other more advanced things, but that is beyond the scope of this book and not very relevant in most modern programming projects. There are some types in Apple's APIs that are structures like CGRect so you should know how to interact with them, but you most likely won't have to deal with custom structure definitions when looking at Objective-C resources.

Enumerations are also much more restrictive in Objective-C. They are really just a simple mechanism to represent a finite list of related possible values. This allows us to still represent possible primary colors:

enum PrimaryColor {
    case Red
    case Green
    case Blue
} 
var color = PrimaryColor.Blue

typedef enum {
    PrimaryColorRed,
    PrimaryColorGreen,
    PrimaryColorBlue,
} PrimaryColor;
PrimaryColor color = PrimaryColorBlue;

Just like with structures, Objective-C enumerations start with the keyword typedef followed by enum with the name at the end of the definition. Each case is contained within the curly brackets and separated by a comma.

Notice that every case of the enumeration starts with the name of the enumeration. This is a very common convention, to make it easy for code completion and to show all possible values of an enumeration. This is because in Objective-C, you cannot specify a specific enumeration value through the name of the enumeration itself. Instead, every case is its own keyword. This is why when we are assigning our color variable to blue; we use the case name by itself.

Enumerations in Objective-C cannot have methods, associated values, or represent any other values except for integers. In fact, in Objective-C enumerations, every case has a numeric value. If you don't specify any, they start at 0 and go up by 1 for each case. If you want, you can manually specify a value for one or more of the cases:

typedef enum {
    PrimaryColorRed,
    PrimaryColorGreen = 10,
    PrimaryColorBlue,
} PrimaryColor;

Each case after a manually specified case will continue to increase by one. This means that in the preceding code PrimaryColorRed is still 0 but PrimaryColorBlue is 11.

Unlike Objective-C structures and enumerations, classes are very similar to their Swift counterparts. Objective-C classes can contain methods and properties, use inheritance, and get initialized. However, they look pretty different. Most notably, a class in Objective-C is split into two parts: its interface and its implementation. The interface is intended to be the public interface to the class, while the implementation includes the implementation of that interface in addition to any other private methods.

class Contact {
    var firstName: String = "First"
    var lastName: String = "Last"
}
@interface Contact : NSObject {
    NSString *firstName;
    NSString *lastName;
}
@end

@implementation Contact
@end

@implementation Contact
- (id)init {
    self = [super init];
    if (self) {
        firstName = @"First";
        lastName = @"Last";
    }
    return self;
}
@end

@interface Contact : NSObject {
}
@property NSString *firstName;
@property NSString *lastName;
@end

@implementation Contact
- (id)init {
    self = [super init];
    if (self) {
        _firstName = @"First";
        _lastName = @"Last";
    }
    return self;
}
@end

@implementation Contact
- (id)init {
    self = [super init];
    if (self) {
        self.firstName = @"First";
        self.lastName = @"Last";
    }
    return self;
}
@end

@interface SteeringWheel : NSObject
@property (weak) Car *car;
@end

@interface SteeringWheel : NSObject
@property (weak, readonly) Car *car;
@end

@implementation Contact
- (NSArray *)addToInviteeList:(NSArray *)invitees includeLastName:(BOOL)include {
    NSMutableArray *copy = [invitees mutableCopy];
    if (include) {
        NSString *newString = [self.firstName
           stringByAppendingFormat:@" %@", self.lastName
        ];
        [copy addObject:newString];
    }
    else {
        [copy addObject:self.firstName];
    }
    return copy;
}
@end

@implementation Contact
+ (void)printAvailablePhonePrefixes {
    NSLog(@"+1");
}
@end

[Contact printAvailablePhonePrefixes];

Categories in Objective-C are just like Swift extensions. They allow you to add new methods to existing classes. They look very similar to plain classes:

extension Contact {
    func fullName() -> String {
        return "(self.firstName) (self.lastName)"
    }
}
@interface Contact (Helpers)
- (NSString *)fullName;
@end

@implementation Contact (Helpers)
- (NSString *)fullName {
    return [self.firstName stringByAppendingFormat:@" %@", self.lastName];
}
@end

We know that this is a category instead of a normal class because we added a name within parentheses after the class name. Every category on a class must have a unique name. In this case, we are calling it Helpers and we are adding a method to return the contact's full name.

Here, for the first time, we are declaring a method inside the interface. This is also possible with classes. A method definition looks exactly like an implementation except that it ends in a semicolon instead of the code inside the curly brackets. This will allow us to call the method from outside the current file, as we will see in more detail in the upcoming projects section.

Categories can also add properties, but you will have to define your own getter and setter methods because just like Swift extensions can't add stored properties, Objective-C categories can't add attributes:

@interface Contact (Helpers)
@property NSString *fullName;
@end

@implementation Contact (Helpers)
- (NSString *)fullName {
    return [self.firstName stringByAppendingFormat: @" %@",
        self.lastName
    ];
}
- (void)setFullName:(NSString *)fullName {
    NSArray *components = [fullName
        componentsSeperatedByString:@" "];
    ];
    if (components.count > 0) {
        self.firstName = components[0];
    }
    if (components.count > 1) {
        self.lastName = components[1];
    }
}
@end

These types of properties are very similar to calculated properties. If you need to allow reading from a property, you must implement a method with the exact same name that takes no parameters and returns the same type. If you want to be able to write to the property you will have to implement a method that starts with set, followed by the same property name with a capital first letter, that takes the property type as a parameter and returns nothing. This allows outside classes to interact with the property as if it were an attribute, when in fact it is just another set of methods. Again, this is possible within a class or a category.

Like Swift, Objective-C has the idea of protocols. Their definition looks similar to this:

protocol StringContainer {
    var count: Int {get}
    func addString(string: String)
    func enumerateStrings(handler: () -> ())
}
@protocol StringContainer
@property (readonly) NSInteger count;
- (void)addString:(NSString *)string;
- (void)enumerateStrings:(void(^)(NSString *))handler;
@end

Here, we are using the @protocol keyword instead of @interface and it still ends with the @end keyword. We can define any properties or methods that we want. We can then say that a class implements the protocol similar to this:

@interface StringList : NSObject <StringContainer>
@property NSMutableArray *contents;
@end

The list of protocols that a class implements should be listed within angled brackets after the class it inherits from separated by commas. In this case we are only implementing a single protocol so we don't need any commas. This code also declares a contents property, so that we can implement the protocol as shown:

@implementation StringList

- (NSInteger)count {
    return [self.contents count];
}

- (void)addString:(NSString *)string {
    if (self.contents == nil) {
        self.contents = [NSMutableArray new];
    }
    [self.contents addObject:string];
}

- (void)enumerateStrings:(void (^)(NSString *))handler {
    for (NSString *string in self.contents) {
        handler(string);
    }
}

@end

Note that we don't do anything special in the implementation to implement a protocol; we just need to make sure the proper methods and computed properties are implemented.

The other thing you should be aware of is that protocols in Objective-C are not used in the same way as classes. You can't just define a variable to be a protocol; instead, you must give it a type and require that it implement the protocol. Most commonly, this is done with the id type:

    id<StringContainer> container = [StringList new];

Any variable declaration can require that it not only inherits from a specific type, but also implements certain protocols.

Lastly, blocks are the Objective-C alternative to closures in Swift. They are actually a late addition to Objective-C so their syntax is somewhat complex:

int (^doubleClosure)(int) = ^(int input){
    return input * 2;
};
doubleClosure(2);

Let's break this down. We start like any other variable with the variable's name and type before the equals sign. The name starts with a carrot symbol (^) inside the first set of parentheses. In this case, we are calling it doubleClosure. The actual type of the closure surrounds that. The type it starts with is the type the closure returns, which in this case is an int. The second set of parentheses lists the types of the parameters the closure accepts. In total, this means that we are defining a closure called doubleClosure that accepts int and returns int.

Then, we move on to the business of implementing the closure. All closure implementations start with a carrot symbol followed by any arguments in parentheses and curly brackets with the actual implementation. Once a closure is defined, it can be called similar to any other function. However, you should always be aware that it is possible for a closure to be nil, in which calling it will cause the program to crash.

It is also possible to define a function or method that accepts a closure as a parameter. First, a function:

id firstInArrayPassingTest(NSArray *array, BOOL(^test)(id)) {
    for (id element in array) {
        if (test(element)) {
            return element;
        }
    }
    return nil;
}
firstInArrayPassingTest(array, ^BOOL(id test) {
   return false;
});

Note that the type id signifies any Objective-C object and even though it doesn't have an asterisk, it is a reference type. The usage above looks exactly like a standalone block usage. However, the syntax looks somewhat different in a method:

- (id)firstInArray:(NSArray *)array
    passingTest:(BOOL(^)(id test))test
{
    for (id element in array) {
        if (test(element)) {
            return element;
        }
    }
    return nil;
}
[self firstInArray:array passingTest:^BOOL(id test) {
    return false;
}];

This is because a method's parameter name is separated by parentheses. This causes the name of the parameter to be moved from being with the carrot to after the parentheses. In the end, we can say that the nuances of the syntax aren't too important when reading Objective-C code and translating to Swift, as long as you recognize that a carrot symbol indicates a block. Many Objective-C programmers look up the syntax of a block on a regular basis.

All of the same memory concerns exist in Objective-C with blocks. By default, all arguments are captured strongly and the syntax to capture them weakly is much more convoluted. Instead of including the weak captures in the block itself, you must create weak variables outside of the block and use them:

@interface Ball : NSObject
@property int xLocation;
@property (strong) void (^onBounce)();
@end
@implementation Ball
@end

Ball *ball = [Ball new];
__weak Ball *weakBall = ball;
ball.onBounce = ^{
    NSLog(@"%d", weakBall.xLocation);
};

Here we use the keyword __weak (that has two underscores) to indicate that the weakBall variable should only have a weak reference to ball. We can then safely reference the weakBall variable within the block and not create a circular reference.