Cocoa Programming for OS X by Aaron Hillegass, Adam Preble and Nate Chandler covers the major design patterns of Cocoa and includes an introduction to the Swift language.

Chapter 1: Let's Get Started

Cocoa programming is object-oriented (an application consists of objects doing their jobs and coordinating with each other to get things done).

Follows MVC design pattern:
- View objects (views). Views exist in a hierarchy. Each view object is an instance of an existing Cocoa class. For example, NSWindow, NSView, NSButton, and NSTextField.
- The model layer is an abstraction of the real-world problem that the application is built to solve. Models for these applications might include various data, data stores, calculations, and web services.
- The controller layer manages the flow of the application. It consists of controller objects, or controllers. Unlike view classes, controller classes are usually custom classes that you write for a specific application.

A XIB file is an XML representation of objects and their connections. Representing a connection requires representing the two objects at either end of the connection.

Connecting Actions
The action of a button has a partner: the target of the button. The action is the name of the method to be executed, and the target is the object whose class implements that method.

Chapter 2: Swift Types

Swift types can be arranged into three basic groups: structures, classes, and enumerations.

All three can have:
- properties: values associated with a type
- initializers: similar to a function, code that initializes an instance of a type
- instance methods: functions specific to a type that can be called on an instance of that type
- class or static methods: functions specific to a type that can be called on the type itself

Structures and enumerations also conform to protocols and can be extended.  numbers, boolean values, string and collection types provided by the Swift standard library are all structures.  This means that standard types have properties, initializers, and methods of their own and can conform to protocols and be extended. Finally, an optional type allows you to store either a value of a particular type or no value at all.

You can find out what type was inferred using Quick Help. Option-click on item to see the Quick Help information.

Numbers & Bool

Apple recommends using Int unless otherwise have to.  Float for 32-bit numbers, Double for 64-bit numbers, and Float80 for 80-bit numbers are also available.  Bool is also available for boolean true / false.

Collections

The Swift standard library offers three collections: arrays, dictionaries, and sets.

The array type is written as Array, where T is the type of element that the array will contain.

A dictionary is an unordered collection of key-value pairs. The values can be of any type, including structures and classes. The keys can be of any type as well, but they must be unique. Swift dictionaries are strongly-typed and can only contain keys and values of the declared type.

A set is similar to an array in that it contains a number of elements of a certain type. However, sets are unordered and the members must be unique as well as hashable. The unorderedness of sets makes them faster when you simply need to determine whether something is a member of a set.

Initializers

You can also create new instances of a specific type. An instance is a particular embodiment of a type. Historically, this term has been only used with classes, but in Swift it is used to describe structures as well.
let emptyString = String()

Properties

A property is a value associated with an instance of a type. For example, Array<T> has the property count.

Instance Methods

An instance method is a function that is specific to a particular type and can be called on an instance of that type.

Optionals

Swift has a generic optional type, Optional. In practice, an optional is indicated by appending ? to a type name:
var anOptionalFloat: Float?

An optional lets you express the possibility that a variable may not store a value at all. The value of an optional will either be an instance of the specified type or nil.  Before you can read the value of an optional variable, you must address the possibility of its value being nil. This is called unwrapping the optional.

There are two ways of unwrapping an optional variable:
1. optional binding (safest); and
2. forced unwrapping (less safe).

Forced unwrapping

To forcibly unwrap an optional, you append an ! to its name.  This tells the compiler you are sure the optional will not be nil and can be treated as if it were a normal Type.  If force unwrap a nil values, results in fatal error.

Optional binding

Optional binding works within a conditional if-let statement:  You assign the optional to a temporary constant of the corresponding non-optional type. If your optional has a value, then the assignment is valid and you proceed using the non-optional constant. If the optional is nil, then you can handle that case with an else clause.

NO:
let avgReading = (reading1! + reading2! + reading3!) / 3

YES:

if let r1 = reading1,  
   let r2 = reading2,
   let r3 = reading3 {
    let avgReading = (r1 + r2 + r3) / 3
} else {
    let errorString = "Instrument reported a reading that was nil."
}

Subscripting Dictionaries

If the key is not in the dictionary, the result will be nil. As with other optionals, it is common to use if-let when subscripting a dictionary:

NO:
let spaceAssignee: String? = nameByParkingSpace[13]

YES:

if let spaceAssignee = nameByParkingSpace[13] {  
    println("Key 13 was in the dictionary!")
}

Loops and String Interpolation

Swift has all the familiar control flow statements: if-else, while, for, for-in, do-while, and switch. The key differences with C-like languages is that while enclosing parentheses are not necessary on these statements’ expressions, braces on clauses are necessary. Additionally, the expressions for if and while-like statements must evaluate to a Bool.

Enumerations and the Switch Statement

An enumeration is a type with a discrete set of values.

enum PieType {  
  case Apple
  case Cherry
  case Pecan
}

Enums can have raw values associated with their cases:

enum PieType: Int {  
  case Apple = 0
  case Cherry
  case Pecan
}

Chapter 3: Structures and Classes

Structures

In Cocoa, structures are typically used to represent groupings of data.  Unlike Classes, structures do not support inheritance (sub-classes).

Structures are initialised with init().  An initializer must initialize all of the properties of its structure.

struct Vector {  
  var x: Double
  var y: Double

  init() {
    x = 0
    y = 0
  }
}

Self represents the instance of the type that is being initialized.

Methods allow you to add functionality to your data types. In Swift, you can add methods to structures as well as classes (and enums!).

By default, the first parameter of a method is not named. Note that there is a colon for each parameter. For example  vectorByAddingVector(_:numberOfTimes:)

Operator overloading

By overloading operators you can make your own types work with common (and even uncommon) operators.  

Classes

Classes are very similar to structures. They have a lot of the same features: initializers, properties, computed properties, and methods. Unlike structures, classes do not have automatic initialisers.

Designated and Convenience Initialisers

Like structures, classes can have multiple initializers. At least one of them will be the designated initializer. A designated initializer is an initializer which other, non-designated initializers – convenience initializers – must call.

The rule of thumb with designated initializers is that they are typically the one with the most parameters.

Inheritance

Can define a sub-class of class.  Must initialise the super and can override super methods.  Note that inheritance is one key differentiator between classes and structures: structures do not support inheritance.

Computed Properties

In Swift the general term for a read-only property is a computed property, which is in contrast to the stored properties:

struct Vector {  
  ...
  var length: Double {
    get {
      return sqrt(x*x + y*y)
    }
  }
}

The read-only computed property pattern (called a "getter") is so common Swift provides a shorthand means of expressing it:

struct Vector {  
  ...
  var length: Double {
    return sqrt(x*x + y*y)
  }
}

Computed properties do not have any storage associated with them. If you need to store a value, you must create a separate stored property for it.

Reference and Value Types

There is one major difference in how classes and structures operate: classes are reference types; structures, enums, and tuples are value types.

A value type is always treated as a single value, even if it is composed of several individual values via its properties. In practical terms, this means that when a value type is assigned or passed as a parameter, a copy is made.

Classes are reference types. A reference is similar to a pointer in C-based languages. However, a pointer stores the actual memory address of the object and you can access that address directly. A Swift reference does not provide direct access to the address of the object being referenced.

Passing by reference instead of by value has implications.

Mutability:
The code manipulating the value has complete control over it.  However, any part of the software that has a reference to an instance of a reference type can change it.

Choosing between reference (classes) and value types (structures).

The vast majority of Cocoa is built on reference types: subclasses of the Objective-C base class NSObject, which provides a lot of important functionality for Cocoa. As such, large portions of your app, namely the controller and view layers, will also need to descend from NSObject.

The model layer is where the answer is nuanced.

Swift and Objective-C

Although you will write your classes in Swift, the classes in the Cocoa frameworks are written in Objective-C.

Foundation Types

In Objective-C, a number of familiar types are implemented as classes as part of the Foundation framework: NSString, NSNumber, NSArray, NSDictionary, and NSSet.  These classes are toll-free bridged, meaning that there is minimal computational cost in converting between the two.

Swift types are automatically bridged to their Foundation counterparts:

let string = "Howdy"  
let objcString: NSString = string  
The reverse is not true, however:  
let swiftString: String = objcString // Error!  

Instead, you must explicitly cast it using as:
let swiftString: String = objcString as String // Ok!

Casting Foundation Types

Foundation collections can hold any kind of object – that is, the collection’s contents do not have to be of the same type!  The solutions to this problem are similar to unwrapping optionals: there are safe and unsafe paths.

The unsafe path is to use as!, the forced cast operator:
let swiftArray: [Int] = objcArray as! [Int]

If you are not so certain, you should use the optional type casting operator as?, which will evaluate to nil if the values cannot be safely cast:

if let swiftArray: [Int] = objcArray as? [Int] {  
  ...
}

Swift strings and collections are value types and the Foundation types are all reference types.

Chapter 4: Memory Management

Objects frequently live longer than the methods in which they are created. Cocoa uses reference counting to manage their lifetimes.

Strong and Weak References

By default, a reference is a strong reference. A weak reference allows you to access the object it references, but it is not included in the object’s reference count. Thus, a weak reference will not keep an object in memory.

When two objects have strong references to each other – either directly or indirectly – a strong reference cycle occurs. In a strong reference cycle, none of the objects can be deallocated because all of them have a non-zero reference count.

An unowned reference is a non-strong, non-optional reference. Like a weak reference, it does not add to an object’s reference count.

Chapter 5: Controls

While writing a Cocoa application, you seldom subclass the classes that represent windows, buttons, or events. Instead, you create objects that work with the existing classes. Also, you do not create code to get controls on windows. Instead, the XIB file contains all this information. 

A XIB file is an XML representation of objects and their connections. Representing a connection requires representing the two objects at either end of the connection.  If the objects at both ends of a connection are included in the XIB, then you can make the connection directly. However, many times an object in a XIB needs connecting to an object outside of the XIB. This is where placeholders come in and, in particular, File's Owner.

File's Owner is a placeholder that stands in for the object that will load the NIB file at runtime. Typically, this is the controller that will control the hierarchy of objects represented in the XIB. When you want a connection to this controller, you make a connection to File's Owner.

Controls

A control is a view that is designed specifically for user interaction.   A control is implemented as a subclass of NSControl, which is a subclass of NSView. Controls are not part of the controller layer, so keep the terms “control” and “controller” separate in your mind. It may help to think of controls as "user controls."

What is a cell? A cell handles the implementation details of the control. For the most part, the cell’s properties and methods are “covered” by identical properties and methods in the corresponding control.

In the attributes inspector for an object, the sections reflect the inheritance hierarchy of the object. The attributes in each section are properties on a Cocoa class that have been exposed so that you can set them in Interface Builder. 

Every control has an enabled property.  When enabled = false control will not respond to user interaction.  By default, enabled = true.

If you want to access a control outside of its action method, you need to create and connect an outlet.

An implicitly unwrapped optional is an optional that you never have to unwrap. You can think of it as an implicitly and forcibly unwrapped optional, and they come with all the dangers of forcibly unwrapping optionals.

MARK: - Comment in Xcode allows you to jump to sections of the file:
// MARK: - Jump

Chapter 6: Delegation

A delegate is a role – possibly one of many – that an object may take on.  In Cocoa, roles are defined by protocols.

The beauty of having delegate roles defined by protocols (delegation) instead of classes (subclassing) is that any object whose type conforms to the protocol can serve in that capacity. Thus, you can assign critical duties without associating them with any particular object class. Moreover, an object can take on multiple roles as needed.

The steps to follow to implement a delegate method:
1. declare that the class conforms to the protocol

class MainWindowController: NSWindowController, **NSSpeechSynthesizerDelegate** {  
  @IBOutlet weak var textField: NSTextField!
  @IBOutlet weak var speakButton: NSButton!
  @IBOutlet weak var stopButton: NSButton!
  ...
}

2. implement method from the protocol
3. set the delegate property to point to the class
speechSynth.delegate = self

Chapter 7: Working with Table Views

A table view can have two helper objects: a delegate and a data source. Typically, a single object plays both roles.

One of the roles of the table view’s delegate is to respond to user interaction with the table view. When the user interacts with a table view – such as by selecting a row – the table view notifies its delegate.

To set up the delegate for the table, the class of the object to be the data source must conform to the NSTableViewDelegate protocol. The class implements the necessary delegate methods. The table view’s delegate property is set to an instance of that class.

The table view’s data source supplies the table view with the data it should display. A table view knows how to display data, but in keeping with Model-View-Controller, the table view should not know about the data itself. Thus, the table view requires a data source (a controller) to talk to the model on its behalf.

Like the delegate, the data source is a role that is defined by a protocol. The class of the object to be the data source must conform to the NSTableViewDataSource protocol. The class implements the necessary data source methods. The table view’s dataSource property is set to an instance of that class.

The data source waits on the table view to ask for data.  In addition, the table view asks for its data one piece at a time rather than all at once. The table view asks for a single object to display at a specific row and column combination. The data source complies by returning the object that holds that specific data.

Cell-based tables (NSCell) can technically still be used, but they have been deprecated in favor of view-based tables. In a view-based table, a table cell is an instance of NSView or one of its subclasses – most commonly NSTableCellView.

Chapter 8: KVC, KVO and Bindings

Key-value coding (KVC) is a mechanism that allows you to get and set the value of a property indirectly using a key. A key is the name of a property as a string.  KVC methods are defined on NSObject.

With KVO, an object can sign up to observe changes to the value of a key. When the key’s value changes, the observer is notified.

Use the KVC method setValue(_:forKey:) to update its properties. valueForKey returns the value.

Bindings use KVC as well as KVO. Bindings can simplify and, in some cases, eliminate the code that links the view layer and the model layer of an application.

In order for KVO to see changes, the changes must be made in a KVO-compliant manner. KVO and KVC both rely on the Objective-C runtime to work.  Most of the time you will use the dynamic keyword on a property to make a property KVO-compliant.  If more control is required, use the willChangeValueForKey(_:) and didChangeValueForKey(_:) methods.

Chapter 9: NSArrayController

In a document-based application, the majority of the user interface is built around presenting a document. Typically, a window which displays a document – the document window.

A document window is presenting a single document, it is easy enough to instantiate multiple document windows, each of which presents a different document. As a result, in a document-based application, you can have multiple documents open simultaneously, each with its own window. 

A subclass of NSDocument is used as the controller for the window or windows (subclass called Document by default).

NSArrayController, like any controller, serves as the glue between a view and its model, an array of objects.  The two most important properties on NSArrayController are content and arrangedObjects. If content is the input to the array controller, arrangedObjects is the output. You will almost never use the content property, however. Instead, you will know it by its binding name, Content Array, and you will bind it to a model array.

Chapter 10: Formatters and Validation

Formatters

Formatters also provide validation at the controller layer, while Key-Value Validation allows you to validate at the model layer.

NSNumberFormatter works with numeric types, while NSDateFormatter works with NSDate objects.

For example:

let date = NSDate() // "Feb 28, 2015, 8:07 PM"  
date.description // "2015-03-01 01:07:59 +0000"  
let dateFormatter = NSDateFormatter() // <NSDateFormatter: 0x7f8a558016c0>  
dateFormatter.dateStyle = .MediumStyle  
dateFormatter.timeStyle = .ShortStyle  
dateFormatter.stringFromDate(date) // "Feb 28, 2015, 8:07:59 PM"  

Validation

Once a value is accepted by a formatter, if present, there is a second opportunity for validation via Key-Value Coding (KVC), or, more specifically, by Key-Value Validation. Key-Value Validation is done at the model and/or controller layers. That is, the model objects themselves can opt in to validating changes.

Chapter 36: Distributing

Select Archive in the Product menu. Your target will rebuild.  You can then extract the app bundle from the archive by using the Export button. You will be prompted for the format to share it in. Choose Export as a Mac Application to share only the app bundle.

Mac App Store

Most aspects of distribution in the Mac App Store are fairly straightforward and similar to the iOS App Store. You will need to use Xcode to sign your application binary, provide a description of your application and screenshots, and, finally, submit the app by using Xcode’s Organizer.