Software Architecture Patterns

A software architecture pattern is a “general, reusable solution to a commonly occurring problem in software architecture within a given context.”
Wikipedia

Our industry spends a lot of time and resources to define and understand architectural patterns because building software is hard, especially when we want to maintain it over time with larger teams.

Patterns discussed here:

Layered architecture
Hexagonal architecture
Onion architecture
Package by feature
Clean architecture

Software architecture concepts

Cohesion
Coupling
Separation of concerns
Layers of isolation
Dependency inversion principle (DIP)
Inversion of control (IOC)

Grzegorz Ziomonski has a good overview of these architectural patterns. His approach is to describe the principles of each, identify pros and cons, and to see how the architecture would affect a project. His analysis is sometimes shallow, however, so it is important to refer to more authoritative literature, such as that written by the creator of a pattern.

Introduction

Why should we look at architecture? In his article Screaming Architecture, Robert “Uncle Bob” Martin describes good architecture like this:

A good software architecture allows decisions about frameworks, databases, web servers, and other environmental issues and tools, to be deferred and delayed. A good architecture makes it unnecessary to decide on Rails, or Sprint, or Hibernate, or Tomcat or MySql, until much later in the project. A good architecture makes it easy to change your mind about those decisions too. A good architecture emphasizes the use-cases and decouples them from peripheral concerns.
`Robert “Uncle Bob” Martin, Screaming Architecture

Each of the architecture patterns described here provide some or all of the benefits described by Uncle Bob, but they all come with their own costs as well. We’ll try to analyze these factors as we compare the patterns.

Layered Architecture

A layered architecture organizes the project structure into horizontal layers, each layer performing a specific role within the application. While this pattern does not specify the number or types of layers that must exist, most layered architectures consist of four standard layers:

Presentation layer
Business layer
Persistence layer
Database layer

There are two important rules for this pattern:

No logic related to one layer’s concern should be placed in another layer.
All dependencies go in one direction.

The first rule states that no logic related to one layer’s concern should be placed in another layer.

One of the powerful features of the layered architecture pattern is the separation of concerns among components. Components within a specific layer deal only with logic that pertains to that layer. For example, components in the presentation layer deal only with presentation logic, whereas components residing in the business layer deal only with business logic. This type of component classification makes it easy to build effective roles and responsibility models into your architecture, and also makes it easy to develop, test, govern, and maintain applications using this architecture pattern due to well-defined component interfaces and limited component scope.
Mark Richards, Software Architecture Patterns

The second rule states that all dependencies go in one direction. In its simplest form, an implementation of the layered architecture pattern would dictate that components in one layer can only depend on components in the layer directly below it, known as a closed layer. This concept is known as layers of isolation. This concept means that changes made in one layer of the architecture generally don’t impact or affect components in other layers. This reduces coupling between layers. It also means that each layer is independent of the other layers, thereby having little or no knowledge of the inner workings of other layers in the architecture.

There are times when it makes sense for certain layers to be open, such as when adding shared service components (e.g. data and string utilities or auditing and logging facilities).

Analysis

Benefit	Notes
Simplicity	The concept is very easy to learn and visible in the project by inspection.
Consistent across different projects	The layers and overall code organization is pretty much the same in every layered project.
Guaranteed separation of concerns	Developers can focus on the details of the layer they are working on.
Browsability from a technical perspective	When changing something in some/all objects of a given kind, they’re very easy to find and they’re kept all together.

Drawback	Notes
No built-in scalability	When the project grows too large, this pattern doesn’t aid in refactoring.
Hidden use cases	You can’t say what a project is doing by simply looking at the code organization. You need to read class names and sometimes even the implementation.
Low cohesion	Classes that contribute to common scenarios and business concepts are far from each other because the project is organized around separating technical concerns.
No dependency inversion	The pattern does not describe how dependencies should be implemented, so if components are implemented without consulting other patterns, direct dependencies are defined instead of abstractions.
Not use-case focused	This pattern organizes components based on type of function and does not provide any help to discover use cases when taking a high-level look at the code.

Resources

Layered Architecture is Good by Grzegorz Ziomonski
Chapter 1. Layered Architecture from Software Architecture Patterns by Mark Richards (O’Reilly)

Hexagonal Architecture

The Hexagonal Architecture – also known as the Ports and Adapters Architecture – was created by Alistair Cockburn with the primary aim of decoupling the applications core logic from the services it uses. This allows different services to be “plugged in” and it allows the application to be run without these services.

This pattern prescribes that every piece of functionality the application offers is available through an API or function call, and that the application accesses external entities (e.g. databases, networking, UI) via a well-defined interface. The application communicates over these “ports”, and an adapter is implemented for each port.

This can be build down to the following principles:

The inside part knows nothing about the outside part.
Any adapter that fits a given port can be used.
No use case or domain logic is implemented in the outside part.

Benefit	Notes
Easy to learn	It’s just ports and adapters.
Application and domain purity	The most important code in the application is not cluttered by technical details.
Flexibility	Adapters can be swapped out easily.
Testability	Test replacements for the outside dependencies can be provided without using extra mocking tools.

Drawback	Notes
Heaviness	A lot of extra classes are required, especially when only one UI and one database need to be supported.
Indirections	To follow the flow of control you must look at the implementation of a port and be aware of the state of the application.
Confusing to apply with frameworks	It’s now always clear what should be considered the outside.
No code organization guidelines	How code is organized is not informed by this pattern.
Not use-case focused	This pattern organizes components based on type of function and does not provide any help to discover use cases when taking a high-level look at the code.

Resources

Hexagonal Architecture is Powerful by Grzegorz Ziomonski
Hexagonal architecture by Alistair Cockburn
What is Hexagonal architecture by Philip Brown
Ports-And-Adapters / Hexagonal Architecture by Patrick van Bergen
Hexagonal Architecture by Marcus Biel

Onion Architecture

The Onion Architecture was created by Jeffrey Palermo to provide the following benefits:

Supports long-lived applications
Supports applications with complex behavior
Emphasizes the use of interfaces for behavior
Forces the externalization of infrastructure

This pattern can be viewed as an evolution and combination of the Layered Architecture and the Hexagonal Architecture.

The primary differences between this pattern and the Layered Architecture are:

Infrastructure is pulled to the outer ring (aka top layer).
Dependency layers are open.
The Dependency Inversion Principle is prescribed for defining communication between layers.

It shares the following premise with the Hexagonal Architecture:

Externalize infrastructure and write adapter code so that the infrastructure does not become tightly coupled.

Key tenets of the Onion Architecture:

The application is built around an independent object model.
Inner layers define interfaces. Outer layers implement interfaces.
Direction of coupling is toward the center.
All application core code can be compiled and run separate from infrastructure.

Dependency Inversion Principle

As mentioned above, the Dependency Inversion Principle is core to this pattern. This principle refers to a specific form of decoupling software modules that reverses the conventional dependency relationship.

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

This design principle inverts the way some people may think about object-oriented programming, dictating that both high- and low-level objects must depend on the same abstraction.

Inversion of Control (IoC)

Another core to this pattern is Inversion of Control (IoC). Typical implementations of this principle use one of the following patterns:

Factory pattern
Service locator pattern
Dependency injection
Strategy design pattern

Analysis

Benefit	Notes
Plays well with DDD (domain-driven design)
Directed coupling	The most important code in the application depends on nothing, everything depends on it.
Flexibility	From an inner-layer perspective, you can swap out anything in any of the outer layers and things should work just fine.
Testability	Since the application core does not depend on anything else, it can be easily and quickly tested.

Drawback	Notes
Learning curve	For some reason, people tend to mess up splitting responsibilities between layers, especially harming the domain model.
Indirection	Interfaces everywhere!
Potentially heavy	Looking at Palermo’s project, the application core has no dependencies on frameworks due to the abstractions.
Multi-layer dependencies	Does not protect outer layers from changes in inner layers.
Not use-case focused	This pattern organizes components based on type of function and does not provide any help to discover use cases when taking a high-level look at the code.

Resources

Onion Architecture is Interesting by Grzegorz Ziomonski
Onion Architecture : part 1 by Jeffrey Palermo
Onion Architecture : part 2 by Jeffrey Palermo
Onion Architecture : part 3 by Jeffrey Palermo
Onion Architecture Part 4 by Jeffrey Palermo

Package by Feature

In a typical Layered Architecture, code is often organized based on the layers, with all the components in one layer provided in the same package. This is often called Package by Layer.

The problem with this approach is that cohesion (the strength of relationships between pieces of functionality) inside each package is usually low and the coupling (the degree of interdependency) between packages is very high. This seems like exactly the opposite of what we want to achieve.

The Package by Feature Architecture pattern attempts to address these concerns by building layers within each feature.

The essence of this pattern can be described like this:

Maintaining high cohesion and low coupling at the package model level and being able to recognize what an application does by looking at its package/module structure.

From Grzegorz Ziomonski:

In a typical Layered Architecture, the cohesion inside a package is low and the coupling between packages is high. We rarely change technologies or conventions regarding a particular layer, comparing to how often we add a single feature, hence low cohesion. And, in most cases, each class in a layer (package) depends on at least one class in another layer (package), making the coupling between them high.
In Package by Feature style, we ideally change classes only in a single package – the one related to the feature we’re working on – so cohesion is high, and there are only a few dependencies between features, so coupling is low.

Analysis

Benefit	Notes
More informative package structure	The system’s main features or behaviors can be deduced from the code structure.
High cohesion and low coupling	Components that are packaged together are related to each other, and dependencies on other packages are limited.
Better encapsulation	You can make effective use of access modifiers to hide the information that ought to stay hidden.
Better growth potential (in the code volume sense)	Unless you develop too big or too small features, you shouldn’t encounter the problem of too big or too many packages.
Use cases may be visible	“If features are identified properly, they will tend to represent use cases supported by the application.

Drawback	Notes
Unspecified feature size	There is no clear guidance or proof that one understanding of feature is better than another.
Learning curve	The concept is simple, but since you need to find your own way to slice a system into features, mastering it can be really hard.
Messiness potential	In a tangled domain, in which everything is connected to everything, the slicing into features might become artificial and the low coupling promise might not be fulfilled.

Resources

Package by Feature is Demanded by Grzegorz Ziomonski
Package by feature, not layer by Java Practices
Package by feature by Kostis Kapelonis
Package by component and architecturally-aligned testing by The Coding Architecture

Clean Architecture

The Clean Architecture, created by Robert “Uncle Bob” Martin, is an attempt at integrating the benefits of all of the other architecture patterns. These include:

Independent of Frameworks
Testable
Independent of UI
Independent of Database
Independent of any external agency

This architecture, like the onion architecture, is represented by concentric circles and makes heavy use of a dependency rule:

The Dependency Rule

The Dependency Rule for this pattern states that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle, similar to the Layered Architecture and unlike the Onion Architecture. So when we pass data across a boundary, it is always in the form that is most convenient for the inner circle.

The layers in this pattern are organized in such a way as to move things that may change further from the center.

Entities – encapsulate enterprise-wide business rules. An entity can be an object with methods or it can be a set of data structures and functions. They encapsulate the most general and high-level rules and are least likely to change when something external changes (e.g. page navigation or security). No operational change to any particular application should affect the entity layer.
Use Cases – application-specific business rules, encapsulating and implementing all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities. Changes in this layer should not affect entities, and changes in externalities (databases, UI, common frameworks) should not affect this layer. Changes to the operation of the application will affect the software in this layer.
Interface Adapters – Like the Hexagonal Architecture, these adapters convert data from the format most convenient for the use cases and entities to the format most convenient for some external agency, such as the database or the UI. This layer will contain the architecture of the GUI (e.g. MVC etc.), including presenters, views, and controllers. This layer will also contain any other adapters necessary to convert data from some external form to an internal form used by the use cases and entities.
Frameworks and Drivers – frameworks and tools such as database, the web/UI framework, etc. Not much code is written in this layer other than glue code. (One thing I have still to determine is how this glue code is different from interface adapters in the green layer.)

Analysis

Benefit	Notes
Use cases are clearly visible
Flexible	Switching between frameworks, databases, or application servers is explicitly enabled.
Testable	The heavy use of interfaces allows tests to be written for any part of the application.


No idiomatic framework usage	The application components would not be familiar to a developer who is familiar with focusing on frameworks.
Learning curve	It’s harder to grasp than the other styles due to lack of references to frameworks.
Indirect	There will be a lot more interfaces than one might expect.
Heavy	You might end up with a lot more classes than in projects that follow other architecture patterns.

Resources

Clean Architecture is Screaming by Grzegorz Ziomonski
The Clean Architecture by Robert “Uncle Bob” Martin
Robert C Martin – Clean Architecture (video)

Object Oriented Programming vs. Functional Programming

Reference: Object Oriented Programming vs. Functional Programming by Bill Gathen

Object oriented programming as a programming paradigm has been around for a long time – since the late 1950s and early 1960s, with the term being introduced in the 1970s with the Smalltalk language. It is defined as:

Object-oriented programming (OOP) is a programming paradigm based on the concept of “objects”, which are data structures that contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods.
Wikipedia

Functional programming as a programming paradigm has its roots in lambda calculus, with Lisp being an early functional-flavored language in the late 1950s, although it hasn’t received popular use until the last decade or so and can be seen in many languages not dedicated to this paradigm with frameworks such as React and Reactive Extensions (Rx). It is defined as:

Functional programming is a programming paradigm – a style of building the structure and elements of computer programs – that treats computation as the evaluation of the mathematical functions and avoid changing-state and mutable data.
Wikipedia

Both paradigms have the shared goal of creating understandable, flexible programs that are free of bugs, but they have two different approaches for how to best create those programs.

In an article posted in 2014 on this subject, Uncle Bob boils these two paradigms down to this:

FP imposes discipline upon assignment. Immutability provides safety, particularly in multiprocessing and multiprocessor environments.
OOP imposes discipline on function pointers. Polymorphism allows stable high-value business rules to be kept from depending upon volatile low-value modules such as user interfaces and databases.

OOP and FP each have their appropriate use cases. Neither is a panacea.

Richard Warburton’s eBook Object-Oriented vs. Functional Programming: Bridging the Divide Between Opposing Paradigms attempts to compare the two paradigms, primarily using the SOLID principles as a means of comparison. Based on my review of his eBook, I walked away with the following points:

FP avoids or can easily satisfy all the SOLID principles.
FP and OOP can coexist in the same codebase.

From When FP? AND when OOP? on ragenwald.com:

The biggest difference between the two “schools of thought” concerns the relationship between data and operations on the data.
The central tenet of OOP is that data and the operations upon it are tightly coupled: An object owns its data and it owns the implementation of the operations on the data. It hides those from other objects via its interface, a collection of methods or messages it responds to. Thus, the central model for abstraction is the data itself, hidden as it is behind a small API in the form of its interface.
The central activity in OOP is composing new objects and extending existing objects by adding new methods to them.
The central tenet of FP is that data is only loosely coupled to functions. You can write different operations on the same data structure, and the central model for abstraction is the function, not the data structure. Functions hide their implementation, and the language’s abstractions speak to functions and the way they are combined or expressed, such as generic functions or combinators.
The central activity in FP is writing new functions.

I like the final statement made by this article:

Good software is written in both styles, because good software has more than one need to satisfy.

WWDC 2016

I had the opportunity to go to my 3rd WWDC (Apple’s World Wide Developers Conference). WWDC is a great place to learn about the new things Apple is introducing in upcoming versions of their products as well as to talk with Apple engineers and others who are developing for their platforms.

All of the content from the sessions delivered at WWDC is available online.

High-Level Summary

New features in iOS 10
- SiriKit
- New user notification framework with more ways to display and manage notifications
- New extension points in iMessage
- Improvements in UIKit animations and transitions
- Improvements in collection views and table views
New features in watchOS 3
- Button modified to bring up a dock of active apps. Glances removed in favor of docked view of app.
- Background app refresh
- Changes to navigation by using the digital crown to navigate between elements at the same level.
- Access to the digital crown.
Swift 3
- The API design guidelines were applied to the language and Cocoa/CocoaTouch frameworks.
Networking
- HTTP/2 Server Push is now supported
- Network statistics

Evaluation

The changes in the notification system and in watchOS can really improve the user experience for presenting notifications.

The changes to Swift continue to improve the safety provided by the language to reduce the occurrence of bugs.

Good info on improving the performance of table and collection views.

HTTP/2 Server Push can significantly improve the responsiveness of mobile apps.

Apple made some really nice changes in watchOS (notifications, background refresh, navigation) that should make the watch a lot easier to use.

Sessions

What's New in Swift

Video

Mission Control, the accessibility engine were rewritten in Swift.

15% less code in Swift than in Objective C
Engineers love using Swift

Open source – swift.org

Big emphasis of Swift 3
Everyone follows the same procedure for getting changes incorporated, even Apple, using the swift-evolution repository on GitHub

Naming

Strive for clarity at the point of use – not terseness or brevity
Capture essential information
Omit redundant information/boilerplate
https://swift.org/documenetation/api-design-guidelines/

New features for controlling how Objective-C APIs are imported into Swift

Whole module optimization is now turned on for al new projects. Existing projects will get a warning to modernize.

Swift API Guidelines

Video

Principles

Clarity at the point of use
- Design APIs to make uses clear and concise
- Uses of APIs always have surrounding context
- Don’t optimize for bad code
Clarity is more important than brevity
- Brevity itself is not a worthwhile goal
Concise code is a consequence of using contextual cues

Omit needless words, those that don’t contribute to clarity

Brevity itself is not a worthwhile goal

Make uses of your APIs read grammatically

If the first argument is part of a prepositional phrase, give it a label
If the first argument is not pat of a grammatical phrase, give it a label
Use a verb to describe the side effect
Use a noun to describe a result

Name methods based on their side effects

Use a verb to describe the side effect
Use a noun to describe the result

Mutating/non-mutation pairs

ed/ing rule
- “reverse” – mutating
- “reversed” – non-mutating

Objective-C names in Swift

Avoid strings for selectors and key paths.
Use #selector for selectors (introduced in Swift 2.2). Swift 3 adds support for getters and setters.
Use #keyPath for key paths (introduced in Swift 3)
NS_EXTENSIBLE_STRING_ENUM – allows you to provide stronger type-safety for Objective-C string values that are intended to be used in a specific way.

Migrating code

Swift 3 migrator
Compiler helps with renaming-related problems
Near-miss detection

Using Store Kit for In-App Purchases with Swift 3

Video

Expanded categories
Increased proceeds for longer held subscribers (longer than a year)
Territory pricing
Preserve prices
Upgrades and downgrades

Types of in-app purchases

Consumable products
Non-consumable products
Non-renewing subscriptions
Auto-renewing subscriptions

Rely on the payment queue and only the queue

What's New in Cocoa Touch

Video

Core technologies

Name changes in Swift
Grand Central Dispatch
Foundation
- New ISO 8601 date formatter

UIPasteboard

A paste operation might have to retrieve remote content
Control over content

UIGraphicsRenderer

Fully color managed
Block-based
Subclasses for images and PDF
Manages context lifetime

Asset Management

Compression

Accessibility Inspector

View and audit accessibility support

Speech Recognition

SFSpeechRecognizer
Continuous speech recognition
From audio files or buffers

Text content type

Dynamic Type

Content size
- No longer a property on UIApplication

Tab Bar customization

Improved WKWebView support for peek and pop

Custom peek and pop animation on UIPreviewInteraction

Full support for UIRefreshControl on UIScrollView and UICollectionView

Collection view

Now supports automatic self-sizing cells in flow mode
Smooth scrolling with cell prefetching, cell at a time, not by row, for free
Data prefetching – new protocol, also on table views

Animation

Interruptible
Scrubbable
Reversible
Rich timing features
Dynamic
Interactive and gesture-driven, all in one animation

Improving openURL

Async with completion handler
Let’s you check if a handler app is installed

NSUserActivity

Capture the state of your application
Infrastructure for Handoff, Spotlight
Now supports locations
Search results can now be continued in your app

SceneKit

New realistic rendering
Available on watchOS

New display modes for widgets

Widgets can be shown on the lock screen
Consider privacy in your use of this feature

New user notification framework

Unifies local and remote notifications
Better delivery management
In-app presentation option
Multi-platform (iOS, watchOS, tvOS)
Service extensions
- Non-UI extension point
Content extension
- Custom views
- Cannot interact

CallKit

Directory extension
Blocking
Identification
Call provider API

SiriKit

Intents and responses
Intents are domain specific
IntentsUI extension for displaying your own UI

What's New in watchOS 3

Video

Watch app objectives

Glanceable
Actionable
Responsiveness

The Glance functionality has been merged into the new Dock

Spend time figuring out how to shorten interactions with the watch

Background App Refresh

All the user’s favorite apps are in memory. They are launched and then suspended. This includes apps associated with complications and those placed in the Dock.

The OS takes a snapshot of an app to show in the dock the last time it was visible. Use the background refresh APIs to update the snapshot.

The system schedules a refresh when:

The user leaves your app
Your notification is dismissed

You may want to snapshot a simpler view for display in the dock and then transition to a more complete view when the user brings the app to the foreground

Silent Complication Push Update

Each app on the watch face can get up to 50 push updates

If the dock is full, each app in the dock can be updated once per hour

If it is not full, the total number of updates will be distributed amongst the remaining apps

Your app on the phone can also push updates to the app on the watch

Navigation Enhancements

Use segues so that the watch system can generate views in the hierarchy

Fit as much of your detail view on a single “page”

Crown

You can use the crown to scrub through a graph

This requires that you don’t use a scroll view

Introduction to Notifications

Video

New User Notifications Framework

Feature parity with existing API
Same code path for local and remote notification handling
Your app has access to pending and delivered notifications
In-app presentation optino

Local notifications on the watch

Access to user-defined settings

Title always shown. Subtitle available as well. Media attachments can also be shown.

Triggers

Push (remote only)
Time interval
Calendar
Location

Notification Management

Access to pending and delivered notifications
Remove notifications
Update notifications
New field on the HTTP/2 request header on push notifications

Notification Actions

Default action
Custom actions
- Background (lets your app process the results in the background
- Foreground (launches your app)
- iOS and watchOS
Dismiss action (new in iOS 10)
- Action performed when user dismisses or clears the notification

Service Extension

Non-UI iOS extension (runs in the background)
Purpose: Augment or replace the content of visible remote notifications
Short execution time
Fallback called
Can perform end-to-end encryption and add attachments
New key – “mutable-content” – to signal that the extension should be called

Q: How can service extensions be supported for multiple versions of iOS?

Advanced Notifications

Video

Media Attachments

Requires using the new Service Extension feature in iOS 10
Allows the app to download the media before the notification is displayed to the user
Available for local and remote notifications
Limited processing time and size
When added, file is moved and managed by the system
GIFs are supported

Custom User Interface

Allows you to add your own views
No interaction with your views
Your app can respond to notification actions

Quick Interaction Techniques for watchOS

Video

What is a quick interaction?

Starting a timer
Checking the weather
Checking an item on your grocery list

Apps need to be:

Glanceable
Actionable
Responsive

How long is a quick interaction? 2 seconds

New kinds of user input

Gesture recognizers
Digital crown rotation
Improved table navigation
Support for new notifications framework
Support for SpriteKit and SceneKit

New gestures

Swipe (discrete)
Tap (discrete)
Pan (continuous)
Long Press (continuous)

Add gestures to groups instead of controls

Some system gestures will have precedence
- Scroll, Force Touch, Long Press

Digital Crown Support

Rotations per second
Rotational delta (1 full rotation = accumulated delta of 1)

Vertical paging

Kind of like paging on iOS – user doesn’t have to go back to table
Must use segues for the table

Notifications

Similar notification APIs across platforms
Can schedule local notifications
Background actions now delivered to extension if scheduled on the watch
If scheduled on the watch, only delivered on the watch
Notification identifiers used to avoid duplicate alerts
- Apple Watch notifications take precedence over forwarded notifications with the same ID

Complications

Recommendation is that all apps provide a complication
Providing a complication keeps app in memory
Accelerates users into your app
Complications can be configured on the phone

SpriteKit & SceneKit

Not just for gaming
SpriteKit is a good choice for graphing
Can use the digital crown for scrubbing across a graph

Drop Wrist

Avoid showing the loading indicator
Show feedback and then use a background NSURLSession and local notifications

Designing Great Apple Watch Experiences

Video

3 components of a watch app

Complication – Any feature on a watch face beyond showing hours, minutes, seconds
Notification
App

Challenge yourself to use quicker and less complicated user flows

Shoot for 2 second user flows

If you’re going to make an Apple Watch app, you should make a complication

Adding extra large complication style

The watchOS Human Interface Guidelines describe all the styles and sizes in detail

Glanceable Notifications

PRoide a meaningful title
Only show what’s necessary
Present important information first
Establish visual hierarchy
Use color, graphics, and animation

Snapshot Best Practices

Anticipate user interests
Account for user preferences and contextual factors
Be logical and predictable
Be recognizable – not radically different than your app
Awkward views
Prepare to get small

Glances evolved into the Dock, which then caused Glances to become redundant

Simplified Navigation

Stickiness

Apps can stick around for 8 minutes on watchOS 3

Improving Existing Apps with Modern Best Practices

Video

Minimum deployment of iOS 8 – this hits 95% of all iOS devices

Set it to iOS 8.4. When iOS 10 is released, set the minimum to iOS 9.3

Resolve issues, such as deprecated APIs

Treat warnings as errors. Now available for Swift in Xcode 8

Accessibility is as much a part of your user interface as the artwork

New locale-aware APIs

Dimension and MeasurementFormatter

Add peek, pop, and quick actions

Run the Swift Migrator

File bug reports – bugreport.apple.com

Incorporate new APIs

Asset Catalogs

Use asset catalogs

UIImage(named:) finds image files whether they are stored in an asset catalog or not

It also performs caching

Scaled Assets

Provide all versions to avoid scaling on the device
- Scaling up produces blocky image
- Scaling down uses a lot of memory on the device

Vector Assets

Scaled and rasterized at build time

Both

Allows you to provide overrides, e.g. if there is too much detail on the vector to be displayed properly in 1x

Rounded/Capped Images

Slices can now be performed in the asset editor in Xcode

Dependency Injection

Don’t put everything in the app delegate and access it from everywhere.

Instead, inject required components

Other

Start with data bundled with your app and then download an update. That way the app starts with data.

Playgrounds

You can now run code in playgrounds that finished asynchronously

Import PlaygroundSupport

Can show live views in the playground (e.g. a table view)

You can now include code and resources (e.g. plist files) in a playground that is not in the main window of the playground

Adding Platforms

Design for the platform

Pivot the data model

Visual Debugging with Xcode

Video

Runtime issues

Elevates issues encountered at run time to the same level as build time issues
- Threading issues
- UI layout issues
- Memory leaks

Thread sanitizer

Data races
Use of uninitialized mutexes
Unlock from wrong thread
Thread leaks
Unsafe calls in signal handlers

Xcode can now render blurred views starting with Xcode 8 beta 2

More Auto Layout properties are displayed

Ambiguous layouts are detected at runtime

Advances in UIKit Animations and Transitions

Video

UIViewPropertyAnimator

Interruptible
Scrubbable
Reversible
Broad availability of timing functions
Running animations can be modified

What's New in UICollectionView in iOS 10

Video

Topics

Smooth scrolling
Improvements to self-sizing cells
Interactive reordering

Smooth Scrolling

Cells will be brought in before they are needed
Cells will be brought in one at a time instead of a row at a time

Cell Pre-Fetching

Enabled by default for apps compiled on iOS 10
Can be disabled
Do heavy lifting in cellForItemAtIndexPath
Do minimal work in willDisplayCell / didEndDisplayingCell
cellForItemAtIndexPath prepared cell may never display
New delegate for pre-fetching: UICollectionViewDataSourcePrefetching with prefetch and cancel prefetching functions
- This allows fetching to be performed on a background thread

Pre-Fetching API Tips

Use GCD or NSOperationQueue
Use cancelPrefetching API to adapt to shifting user focus

Same functionality also available to UITableView

UITableViewDataSourcePrefetching

Improvements to Self-Sizing Cells

Introduced in iOS 8

Full support in UICollectionViewFlowLayout – set estimatedItemSize
Three options for specifying actual cell size: auto layout, override sizeThatFits(), override preferredLayoutAttributesFittingAttributes()

Picking a good estimated item size

Hard to guess
Now can be automated in iOS 10 with UICollectionViewFlowLayoutAutomaticSize
iOS will use the sizes of all the other cells to estimate the size
Works best if cells have similar widths and heights

Interactive Reordering

Added in iOS 9
Paging support added in iOS 10
Behaves similar to reordering apps on the home screen

UIRefreshControl

Now supported directly in UICollectionView, UITableView, and UIScrollView because it is a scroll view property

NSURLSession: New Features and Best Practices

Video

NSURLConnection officially deprecated in 2015

Good sessions from WWDC 2014 and 2015 on NSURLSession

Benefits

HTTP/1.1, SPDY, HTTP/2 (RFC 7540)
App Transport Security (ATS)
HTTP Strict Transport Security (HSTS) – no code changes required
Cache, cookies, proxy, authentication
Configuration

Avoid 1-task-to-1-session model

Have 1 session service many tasks
- Better performance and resource utilization

HTTP/2 Protocol

Multiplexing and concurrency
Header compression
Stream priorities
Server Push (new)

HTTP/2 Server Push

Prevent network round trips
Server support required
Now available in NSURLSession
Provides 2x to 3x improvement

Network Statistics

NSURLSessionTaskMetrics
NSURLSessionTaskTransactionMetrics
- Request and response
- Protocol and connection
- Load info
- Connection establishment and transmission

Transport Layer Security (SSL) is the predecessor

Protects data
The RC4 cipher is no longer supported

Command-line tool – nscurl

nsurl — enable-rc4 – use to find dependencies on RC4

App Transport Security

2 new keys
- NSAllowsArbitraryLoadsInWebContent
- NSRequiresCertificateTransparency

Making Apps Adaptive, Part 1

Video

Takeaway

The system is going to do most of the work so you don’t have to

Traits – describe the environment that your application is running in

Layout
- Size Classes
- Dynamic Type
- Layout Direction
Appearance
- Display Gamut
- Interface Style
Capabilities
- 3D Touch

Size Classes

Screen size
Orientation
Adaptation (e.g. multi-tasking)

Takeaway

Base layout on available space, not device, orientation, or adaptation
Size classes express (user) experience

Only have to think about four combinations of size classes

But most commonly just two, because width is most common

If you use UISplitViewController, changes between master-detail and navigation will come for free

traitCollectionDidChange: is the key method for adapting changes in traints

Interface Builder is using the simulator to render views

You can now quickly switch between devices and orientations to view how a storyboard would be rendered

Architecting for Performance on watchOS 3

Video

2-second tasks

Complications for all

All Apple apps now have a complication

Memory limit

30 MB per application in watchOS 3

Tips for keeping memory footprint down

Use appropriately sized images
Use appropriately sized data sets
Use lightweight APIs
Don’t keep around things you no longer need

Resume Time

Key path to optimize

Lifecycle – extension delegate

applicationDidFinishLaunching
applicationDidBecomeActive
applicationWillResignActive
applicationDidEnterBackground
applicationWillEnterForeground (not on first launch)

Lifecycle – interface controller

awakeWithContent
willActivate
didAppear
willDisappear
didDeactivate

Resume Time Tips

Use discretion when updating WKInterface objects
- Setting a property sends data to the watch, so only set them if they have changed
WKInterfaceTable is not a UITableView
- All cells are created up front
- Keep the size down – it’s best to keep the size to a maximum of just over 20
- Avoid reloading a table when possible – use insertion and deletion APIs

Design

Glanceable
Focused purpose
Navigation

Improve layout update performance

Setting values on a WKInterfaceConnector are not cached, so only set them wifi they have changed

Think small

Keep tasks small and easy to perform
Simplify your user interface
Make use of new Background Refresh APIs

Focus on resume time

Pay attention to WKInterfaceController lifecycle methods (especially willActivate and didAppear)
Make use of cancelable operations
Optimize when updating your user interface

A Peek at 3D Touch

Video

Static Quick Actions

Defined in your app’s Info.plist
Available as soon as your app has been installed

Dynamic Quick Actions

Created by your app at runtime
Available after the first launch of your app
Shows after any static quick actions (space permitting) – only 4 total
Can include a system icon, custom icon, or Address Book contact

Best Practices

Every app should provide quick actions
Focus on providing quick access to high-value tasks
Make quick actions predictable
Be prepared to handle dynamic quick actions from previous versions of your app
- Include the app version in the info provided with the dynamic action
Don’t add functionality that is only accessible using quick actions

Set self as the delegate

Make sure that similar looking stuff is previewable in similar ways

Preview quick actions

Peek and Pop Best Practices

Content that can be tapped should support Peek and Pop
Return a preview view controller consistently – similar looking content should be previewable in a similar way
Don’t take too long in the previewing delegate
Set the previewing context sourceRect to lift the previewing interface element on-screen

UIPreviewInteraction

Low-Level Force API

Normalized access to force data

Using and Extending the Xcode Source Editor

Video

New in Xcode 8

New font – SFMono – designed for retina displays
Current line highlight
Command-Option-Slash – inserts documentation comment block
Documentation comments use SFMono-medium for keywords and SFMono-light for other text
Image and color literals

Not new

Command-Option-] – Selects lines and allows you to move them
Command-Control-G – Navigates to search results

Source Editor Extensions

Add commands to the source editor
Edit text
Change selections
One extension, several commands
They are Application Extensions
- Each runs in its own process
- Sandboxed and uses entitlements
- Gets access to text at invocation
- Distributable on the Mac App Store

Built into a host application

Extension commands:

Your extension’s Info.plist
Your extension’s commandDefinitions property, overriding the Info.plist
- Overrides collection stored in the Info.plist

Speed

Text editing is “user-synchronous”
Users will invoke your command via typing
User changes to a document are prevented while a command is running
The user can cancel your command
- A command that takes a while gets a cancellation banner

How Xcode helps

Keeps your extension alive for fast invocation
Optimizes data transfer for performance

How you can help Xcode

Start up quickly
Use GCD and follow standard asynchronous patterns
Don’t replace the whole buffer if you don’t need to

Making Apps Adaptive, Part 2

Video

Asset Catalogs

Alignment Insets and Slicing

Dynamic Type

Now part of the trait environment with UITraitCollction.preferredContentSizeCategory
Set up your text views
- .font = UIFont.preferredFont(forTextStyle:)
- .adjustsFontForContentSizeCategory = true
Be sure to test with all Dynamic Types sizes

Layout Guides

UIView.layoutMarginGuid
UIView.readablContentGuide

UIAppearance

Design you app for different adaptations

Consider the possible combinations of device, orientation, and size
Make designs
Define rules for which design to use

Defining Rules

Don’t check if size exactly matches
Do define Boolean conditions
- Use size class
- Compare value to a threshold
- Compare values to each other

Implement the Designs

Find the size of the app
Use the rules to decide which design to use
Apply the design to the UI

Where does the code go?

Don’t put design-specific code in viewDidLoad
Put it in viewWillLayoutSubviews
This is called very often, so do as little work as possible
Find out what has changed since last time
Don’t cause a layout loop

Reusable Elements

Build your app out of pieces that can be reused in different designs
Each piece is typically a view controller
View tree and constraints
Connections to other view controllers
Connections to the rest of your app

Design Object

Stores information describing a design
Immutable struct for safety
Allows comparison

Iterative UI Design

Video

Understanding Swift Performance

Video

Understanding the implementation to understand the performance

Dimensions of Performance

Allocated on the stack or the heap
How much reference counting
Statically or dynamically dispatched

Allocation

Stack – very fast

Decrement stack point to allocation
Increment stack pointer to deallocate

Heap

Advanced data structure
Search for unused block of memory to allocate
Reinsert block of memory to deallocate
Thread safety overhead

Structs are allocated on the stack

Class references are allocated on the stack, instances on the heap. It also allocates more memory than is needed

Changing an instance of a class will also change other instances.

Reference Counting

There’s more to reference counting than incrementing, decrementing

Indirection
Thread safety overhead

There’s no reference count overhead with a struct that has only value type members

A struct incurs reference counting overhead proportional to the number of reference type members

Foundation added UUID type in iOS 10 that’s a value type (struct)

An enum backed by a string doesn’t require heap allocation

Method Dispatch

Static

Jump directly to implementation at run time
Candidate for inlining and other optimizations

Dynamic

Look up implementation in table at run time
Then jump to implementation
Prevents inlining and other optimizations

Marking a class as final will allow the compiler to statically dispatch functions on that class

Performance Types

Polymorphism without inheritance or reference semantics
Protocol Witness Table (PWT)
Dynamic dispatch without a V-Table
The Existential Container
Boxing values of protocol types
- Inline Value Buffer – currently 3 words
Large values stored on heap
- The Value Witness Table (VWT)
- Allocation, Copy, Destruction of any Value
Reference to Value Witness Table
Reference to Protocol Witness Table

// Protocol Types
// The Existential Container in action
func drawACopy(local: Drawable) {
    local.draw()
}
let val: Drawable = Line()
drawACopy(val)
// Generated code
func drawACopy(val: ExistContDrawable) {
    var local = ExistContDrawable()
    let vwt = val.vwt
    let pwt = val.pwt
    local.type = type
    local.pwt = pwt
    vwt.allocateBufferAndCopyValue(&amp;local, val)
    pwt.draw(vwt.projectBuffer(&amp;local))
    vwt.destructAndDeallocateBuffer(temp)
}

Protocol Type Stored Properties

struct Pair {
    init(_ f: Drawable, _ s: Drawable) {
        first = f
        second = s
    }
    var first: Drawable
    var second: Drawable
}

var pair = Pair(Line(), Point())

Expensive Copies of Large Values

let aLine = Line(1.0, 1.0, 1.0, 3.0)
let pair = Pair(aLine, aLine)
let copy = pair

References Fit in the Value Buffer

Indirect Storage with Copy-on-Write

Use a reference type for storage

class LineStorage { var x1, y1, x2, y2: Double }
struct Line: Drawable {
    var storage: LineStorage
    init() { storage = LineStorage(Point(), Point()) }
    func draw() { ... }
    mutating func move() {
        if !isUniquelyReference(&storage) {
            storage = LineStorage(storage)
        }
        storage.start = ...
    }
}

Summary – Protocol Types

Dynamic polymorphism
Indirection through Witness Tables and Existential Container
Copying of large values causes heap allocation

Generic Code

protocol Drawable {
    func draw()
}
func drawACopy(local: T) {
    local.draw()
}

let line = Line()
drawACopy(line)
// ...
let point = Point()
drawACopy(point)

Generic code implements static polymorphism – one type per call context

Type substituted down the call chain

Implementation of Generic Methods

One shared implementation
Uses Protocol/Value Witness Table
One type per call context – passes tables instead of using existential container

Specialization of Generics

Static polymorphism – uses type at call-site
Creates type-specific version of method
Version per type in use
Can be more compact after optimization

When does specialization happen?

Infer type at call-site
Definition must be available

Whole Module Optimization

Increases optimization opportunity
Now enabled by default in Xcode 8

Specialized Generics – Struct Type

Performance characteristics like struct types
- No heap allocation on copying
- No reference counting
- Static method dispatch

Specialized Generics – Class Type

Performance characteristics like class types
- Heap allocation on creating instance
- Reference counting
- Dynamic method dispatch through V-Table

Unspecialized Generics – Small Value

No heap allocation – value fits in Value Buffer
No reference counting
Dynamic dispatch through Protocol Witness Table

Unspecialized Generics – Large Value

Heap allocation (use indirect storage as a workaround)
Reference counting if value contains references
Dynamic dispatch through Protocol Witness Table

Summary

Choose fitting abstraction with the least dynamic runtime type requirements
- Enables static type checking, allows compiler to ensure correctness at compile time
- struct types – value semantics
- class types – identity or OOP style polymorphism
- Generics – static polymorphism
- Protocol types – dynamic polymorphism
Use indirect storage to deal with large values

isKindOfClass and XCTest

I learned something very useful today. My group uses Apple’s XCTest as a framework for test automation. Because of the way XCTest gets associated with the app, there are certain rules you need to follow that aren’t completely obvious in order to use certain very common features of CocoaTouch.

How XCTest Can Test Your App

When you create a test target to test your app, a separate executable image is built that doesn’t include the components of your app. When you run a test, your app is run and then the test image is injected into the app process. The result is that type information comparisons (e.g. isKindOfClass:) only work if the class objects are in the same image.

Fixing Type Comparisons

In order to compare types reliably, you must not include the same source files in both the app target and the test target. If your project is small, this is a relatively simple task. However, as your project gets larger and you start using CocoaPods or include libraries in other ways, you need to get a little more creative.

In our case, we use CocoaPods pretty extensively, and we build some of our code in libraries (and therefore separate pods) and some in the application. The result is that I needed to create multiple pod targets to ensure that no source file was included in both targets.

Other XCTest Tidbits

I ran into this problem because I was building some tests with mocks and other tests without them, and the mocks were located in a separate pod. In order to get my app to use the mocks, I created an app target that included the mocks directly. Why, you might ask? For the following reasons:

My app view controller need access to the data that is being mocked before my tests are run.
Setting a singleton value in a +load method doesn’t work because the +load method in the test target isn’t called
Swizzling in the test target doesn’t work.

References

Daniel Eggert: Testing View Controllers

Download data from mint.com

intuit_mint_logo_detail I’ve been using mint.com for managing my finances since 2009. It’s a terrific website for budgeting and visualizing how you spent your money. I recently joined Tableau Software and wanted to employ the power of Tableau against my data. The first step to doing this is to download my data into a file that Tableau can connect to. This turns out to be pretty straight-forward thanks to work done by Mike Rooney. He built a Python module called mintapi to pull data from your mint.com account using screen scraping.

If you’ve never used Python before, there are a few extra steps to get it working. Below are the steps for doing this on a Mac running Mac OS X 10.10 (Yosemite).

1. Install Homebrew.

Homebrew is a package manager for installing commonly-used software modules on Mac OS X.

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

2. Install the Homebrew-version of Python.

brew install python

Follow instructions in brew output. Typically this will include statements like this:

pip install --upgrade pip setuptools
brew linkapps python

3. Install mintapi and requirements.

pip install mintapi
pip install pandas

4. Download transactions from mint.com.

Now you’re ready to download your data.

mintapi -t -u MINT-EMAIL-ADDRESS -f FILENAME

where MINT-EMAIL-ADDRESS is the email address you use to log in to mint (e.g. myname@gmail.com), and FILENAME is the name of the file to save the data. The filename should end in .csv (e.g. mint.csv) to use with Tableau, although you can also specify a .json extension to get the data in JSON format.

To get help on the mintapi command, you can type the following command:

mintapi --help

That’s it. Super simple.

Git fix guide

I consider myself a fairly advanced user of Git. I’ve been using it for most of the past 5 years and really enjoy the workflow improvements, and in the circles I run I am typically consulted when folks have a question about Git. Of course, I couldn’t be nearly as effective without the help of others on the web.

For example, today I was looking for a way to remove a file from a commit that I hadn’t yet pushed, and my search led me to Seth Robertson’s page On undoing, fixing, or removing commits in git. This page walks you through solutions by asking a series of questions about the current state of your repository and your changes. Great guide!

Oh, and to remove a file from a commit, you can issue this command:

git reset HEAD^

which will undo the last commit, restoring your index to the previous commit, and leave the working directory with the changes uncommitted.

Double-Checked Locking and Objective-C

A common problem in software is to do something exactly once – e.g. create a singleton. A corollary of that action is to do something exactly once in the life of an instance. I have found myself using the corollary much more frequently as I move away from using singletons, which I’ve done to improve testability.

With singletons, a common solution is to use locking or, to avoid the performance penalty of locking, double-checked locking. Of course, double-checked locking has issues with most modern languages caused by CPU and compiler instruction reordering. Objective-C has provided an elegant solution to those problems, but the solution comes up a little bit short.

Creating a Singleton – Single-Threaded

In a single -threaded application, creating a singleton can be done without additional protection, like this:

+ (MyClass *) sharedInstance
{
    static MyClass * s_sharedInstance = nil;
    if (s_sharedInstance == nil)
    {
        s_sharedInstance = [MyClass new];
    }

    return s_sharedInstance;
}

Creating a Singleton – Multi-Threaded

In a multi-threaded application, it’s not so simple as you will want to protect yourself against multiple callers of this method. A simple solution simply adds a lock:

+ (MyClass *) sharedInstance
{
    static MyClass * s_sharedInstance = nil;
    @synchronized(self)
    {
        if (s_sharedInstance == nil)
        {
            s_sharedInstance = [MyClass new];
        }
    }

    return s_sharedInstance;
}

The problem with this solution is that you pay the price of locking even though you only need it the first time the method is called.

Double-Checked Locking

A common solution to avoid the penalty of locking is to use double-checked locking. With double-checked locking you check the value of the static instance both outside and inside the lock, like this:

+ (MyClass *) sharedInstance
{
    static MyClass * s_sharedInstance = nil;
    if (s_sharedInstance == nil)
    {
        @synchronized(self)
        {
            if (s_sharedInstance == nil)
            {
                s_sharedInstance = [MyClass new];
            }
        }
    }

    return s_sharedInstance;
}

At first blush, it would seem that this would solve the problem of assigning the static variable AND avoiding the penalty of the lock. The problem is that the CPU and/or the compiler could reorder the memory access instructions. A solution suggested by Mike Ash inserts memory barriers before accessing the variable and uses the volatile keyword. The memory barrier, available in libkern/OSAtomic.h, solves the CPU problem and the volatile keyword solves the compiler problem.

+ (MyClass *) sharedInstance
{
    static MyClass * volatile s_sharedInstance = nil;
    if (s_sharedInstance == nil)
    {
        @synchronized(self)
        {
            if (s_sharedInstance == nil)
            {
                OSMemoryBarrier();
                s_sharedInstance = [MyClass new];
            }
        }
    }

    OSMemoryBarrier();
    return s_sharedInstance;
}

The problem with this solution is that it is still quite expensive in the most common case. Apple has provided another solution: dispatch_once.

dispatch_once

dispatch_once is provided with Grand Central Dispatch to execute statements exactly once, like this:

+ (MyClass *) sharedInstance
{
    static MyClass * s_sharedInstance = nil;

    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        s_sharedInstance = [MyClass new];
    });

    return s_sharedInstance
}

This is a terrific solution for use with singletons, but what if you want to use it with an instance? It actually happens to work, but Apple has a warning against using it in this way in the documentation for dispatch_once:

The predicate must point to a variable stored in global or static scope. The result of using a predicate with automatic or dynamic storage (including Objective-C instance variables) is undefined.

Hmm, that’s unfortunate. Here’s hoping Apple will change their implementation. In the meantime, it would appear that the only solutions for the non-static and non-global case are:

Use a synchronized block for every call.
Use memory barriers.

References

Rolling a Ruby gem back to a previous version

I ran into a problem with the Ruby gem for a tool I use recently when I installed the latest version and then found it was broken. I wanted to roll back to the previous version, which turns out to be extremely simple. Here is the command I used and the responses I received:

> sudo gem uninstall cocoapods
Password:

Select gem to uninstall:
1. cocoapods-0.23.0
2. cocoapods-0.24.0
3. cocoapods-0.25.0
4. cocoapods-0.26.2
5. cocoapods-0.27.1
6. cocoapods-0.28.0
7. cocoapods-0.29.0
8. cocoapods-0.30.0
9. All versions
>

I selected 8 in the list, and when I checked the version of the gem after running this command, it had indeed been rolled back. Simple. Sweet. Just what I needed.

CocoaConf 2013 in San Jose

Last weekend I attended CocoaConf in San Jose. CocoaConf is a technical conference for developers working iOS or Mac OS X. Workshops and sessions are taught by form Apple developers and important developers in the industry, many of whom have written books. It was a great conference, both for the content and for the opportunity to mingle with other like-minded individuals.

Resources

Slides from the organizers of the conference.
Blog post by Mark Pospesel, one of the speakers.
Blog post by Ari Braginsky, another attendee.

My Highlights

Beautiful and Shiny – The iOS Graphics System (all-day workshop) – The info is all available, but the workshop was a great forcing function to learn about it and try things out.
Unit Testing Your iOS App With Kiwi – Very interesting way to write unit tests. Built on top of the unit testing framework (OCUnit) that comes with an Xcode installation.
Cocoa Gesture Recognizers – Awesome flexibility.
Stronger, Better, Faster With Instruments And Debugging – Great introduction to using Instruments. One thing I didn’t know is that there are different instruments when you’re connected to the device and when you use the simulator.
Exploring MVC-N – My favorite session of the conference. The concept isn’t all that earth shattering – have a single component that is responsible for communicating over the network – but it’s one that we haven’t implemented to date that could simplify our network code.
- The speaker is really down on 3rd party libraries because you’ve then delegated the knowledge of that area to a library you don’t know much about. Since networking is a core component of most apps, it should be something that is written in-house.
Cocoa Design Patterns – Presentation of using the Chain of Responsibility pattern to avoid singletons is very interesting.
NSPredicates for Fun and Profit – Very cool way to search through text and collections. Can make that logic very simple (or very complicated if you’re not careful).
Advanced Behavior and Performance Testing with UI Automation – Really interesting testing can be done with UIAutomation, but it’s all done in JavaScript and within Instruments.
- Great list of tools provided in this talk.
Making Successful Apps – Good stuff for program and product management, although applicable for anyone designing and building apps.

My Detailed Notes

Beautiful and Shiny – The iOS Graphics System (all-day workshop)

Bill Dudney

The Layer of a UIView uses memory for every pixel
The frame property is now (iOS 6) a computed value. Setting the frame sets the center and the bounds.size.
We shouldn’t be changing the frame on a view anymore as that messes up auto layout.
- Note: We don’t currently use auto layout anywhere.
If you use the simple masks and shadows APIs, it uses offscreen rendering and is expensive.
- Example: Rounded corners with clipsToBounds
- Instead, use clipping masks.
- Before you ship, always test with Debug -> Color Offscreen-Rendered in the Simulator to see what the app is doing.
You should avoid drawing unless you can build it in Photoshop, because drawing is expensive.
“Introduction to Geometric Modeling” video by professor at UC Davis who describes how Bezier curves work.
Don’t implement gesture handling using touchesBegan and touchesEnded. Instead, use a gesture recognizer.

Mastering The Project File

Michele Titolo

Slides
Apparently project.pbxproj files can be converted to JSON, although I couldn’t get it to work.
- plutil -convert json project.pbxproj

Unit Testing Your iOS App With Kiwi

Pete Hodgson

Slides
Kiwi is built on top of SenText (OCUnit) using blocks and syntax that looks vaguely like English.
Kiwi can handle stubbing and mocking, although he didn’t include any details in his talk.
It is recommended that we use CocoaPods to pull in 3rd party software.
“Test what you can isolate.”

Keynote: The People We Work For

Matt Drance

Customers
- Think about how what you are doing (designing, implementing a feature, fixing a bug) will make their lives better.
Peers
- Communication is important in helping the team be productive. This could be as simple as sending an email to let people know where you left off if you are going on vacation, moving to a different project or group, or leaving. “Reduce tension in the room.”
You
- Make sure you take care of yourself.
Tools
- Charles Proxy
- Kaleidoscope file comparison tool
- DeployMate – helps you identify unavailable, deprecated and obsolete API usage in your Xcode projects

Cocoa Gesture Recognizers

Jonathan Penn

Slides and sample code
Introduction to gesture recognizers, presented as state machine objects tracking user touches.
Walkthrough example
Gesture Lab – Cool tool for debugging gestures for designing a gesture recognizer.

Stronger, Better, Faster With Instruments And Debugging

Kyle Richter

Slides
This was a fairly basic overview of the debugger and Instruments, but very useful.
Breakpoints:
- Conditional breakpoints appear to be pretty performant.
Debugger command line:
- The list command will list the source code around the current breakpoint.
- The bt command will list the backtrace for the current break.
“Make sure you test against slower devices, such as the 3GS or the 4.”
There are different instruments for running on a device and running on the simulator.
Leaks that are the same size but aren’t grouped together may be the same leak but for some reason Instruments didn’t group them together. This is similar to behavior we see in BugSense when grouping crashes together.
Other tools:
- Network Link Conditioner.
- Blended Layers in the Simulator
  - Using a clear background color requires iOS to composite the view with the background which is expensive. Avoid clear background unless you can’t determine the background color.
- Misaligned Images in the Simulator
  - Misaligned images will be slightly blurry. Normally caused by math errors when laying out views.
- Slow Animations in the Simulator

Exploring MVC-N

Marcus Zarra

Slides
If you’re using other people’s code (e.g. a 3rd party framework) you’re probably doing the wrong thing. Why? Because you consider this a solved problem but you didn’t write the code and therefore likely don’t understand what that 10,000 lines of code are doing.
The concept of MVC-N is that networking is separated out from the view controllers.
The NetworkController talks to the network and stores the result in the persistent store – Marcus uses Core Data.
- Properties:
  - NSOperationQueue
  - NSMnagedObjectContext
- Method
  - Different method for each type of request
- How to create
  - Dependency injection
  - Singleton
  - AppDelegate property
Have one NSOperation subclass for each network call.
- He doesn’t recommend using blocks because blocks are not easily cancelable.
- Another problem with blocks is because of code bloat – a lot of code in one place.
For unit testing, he recommends setting up a simple server on the local network that always returns the same result.
If you can let network operation fail without notifying the user, do it.
Summary
- Own your network code.
- Don’t put network code in view controllers.
- Keep all network code together.
- All UI should feed from Core Data.
- Disconnect data collection and data display.
http://github.com/zarrastudios
Questions:
- I asked him about using Core Data for data we don’t need to persist (e.g. most of our data) and he recommended it using an in-memory store.
- NSManagedObjectContext can be used to represent data received from the network, which represents the data as key-value pairs.

Cocoa Design Patterns

Saul Mora

You don’t want to release crapps. You want to release apps.
Patterns
- Chain of Responsibility pattern, aka Responder Chain
  - Call sendAction:to:from:forEvent: to make a request of an object in the hierarchy.
    - Example: Dismissing the keyboard can be done by calling this method on the application object and specifying self for the “from” property.
  - Derive the app delegate from UIResponder.
- Command pattern
  - We do this with our operations by creating a separate object for each network operation.
- Template pattern
Anti-Patterns
- Factory, Abstract Factory
- Singletons
  - Consider a Singleton Manager – Service Locator pattern.

NSPredicates for Fun and Profit

Josh Smith

Slides
You can use it for scanning strings, arrays, and Core Data.
Predicates are basically search expressions which can be strings (BEGINSWITH, ENDSWITH, CONTAINS, etc.) or a block.

Advanced Behavior and Performance Testing with UI Automation

Jonathan Penn

Slides and sample code
UIAutomation is all in JavaScript in Instruments.
It is completely sandboxed so you can’t use NodeJS or other frameworks.
You can see screenshots within Instruments as your script runs.
You can use the accessibilityIdentifier to display various states in Instruments as you change the state.
He recommends including “use strict” at the top of the script.
Define tests in a function in the script. Doing this puts all messages displayed by the script on a single line that can be expanded. This also sets a log type (e.g. Pass or Fail) and shows a different color on the timeline.
- He showed raw JavaScript, which was very messy.
- Then he showed functionalizing the JavaScript so that the tests looked like single statements. Much cleaner.
He showed swiping up and then down repeatedly in a loop to find a memory leak. Very cool!
Tools:
- Reflector – AirPlay iOS device screen to your Mac
- UI Screen Shooter – Take screen shots of your app for the app store
- tuneup.js – Collection of JavaScript utilities that build upon and improve UIAutomation
- mechanic.js – Lets you take the power of UIAutomation with the simplicity of modern JavaScript CSS selector engines to make your UIAutomation scripts terse and beautiful
- Bwoken – iOS UIAutomation test runner runs UIAutomation tests from the command line in the simulator or on the device
- cisimple – Continuous integration in the cloud
- Book: Test iOS Apps with UI Automation
- UIAutoMonkey
- KIF (Keep It Functional) – iOS integration testing framework

Making Successful Apps

Michael Simmons

Co-owner of Flexibits who created Fantastical which was at one point the top app in the App Store. He also owns the company that does HockeyApp.
Why are you *really* doing this?
What are your goals?
- > You cannot be on autopilot. You have to question everything. Otherwise, how do you know that what you are doing is right?
- > (If the UI is good (easy to use, simple, etc.) it will be successful.)
- Why are you doing this?
- What do you want?
- Dream but be realistic!
  - Don’t be afraid to ship your 1.0 with limited features, but communicate with your users what your plans are to provide those features.
What is your plan?
- Too ambitious? Not enough? Real artists ship.
Who is your audience?
- Consumers? Professionals? Both?
  - How can it be for both? It can start out simple and then build up as the user uses it.
- Creating an appropriate app is vital.
What is your passion?
- What excites you?
- What makes you happy?
- What underwhelms you?
Details you should be thinking about
- Be the best.
- Are you doing something unique and original?
- Marketing is not an evil word. If you build it, they might come. Marketing doesn’t have to be sleazy. It is required to build awareness.
  - Marketing is also about the design of the app and of the icon.
  - They use the Icon Factory for their icons.
App Launch
- Sneak peek/teaser (public beta?). Create mystique.
- Last minute details dialed in.
  - For sales, they use Fast Spring for selling from their website as well as selling through the App Store. This also allows them to offer a free trial.
  - You can create promo codes to make your app available to press or others before you release.
- Marketing/PR
  - Embargoes are tricky. He doesn’t use them anymore because when you release through the App Store you don’t have any control on when it is actually available.
- Launch!
  - You should do your own support because it is the lifeline to your customers.
  - Negative emails are fantastic because your users are passionate about your app.
  - Don’t rely on your users to design your app.
  - 99 cents is not the right price for app. Is a a marketing tool. If your app is that good it will sell.
So, how do you make great apps?
- Define your goals.
- Create a plan. Or two.
- Find your passion.
- Admit your weaknesses.
Piwik (http://piwik.org/) – Web analytics.
Frequency of updates
- You want to get an update out at least every 3 months.
- Don’t update for the sake of updates.
3rd party support (e.g. Get Satisfaction)
- He doesn’t like them as it gets between you and your users.
- He hates forums.
- He prefers email support.
- He has a policy of responding within 24 hours. Users love it.
Release notes
- If just “Bug Fixes” include the release notes for the previous version as well.
Keywords
- Don’t use competitor names as keywords.
- The obvious ones are the important ones.

Mac App: Ejector

Does this ever happen to you? You download a DMG file to install an application, mount it, then install the app. At that point you go on your way and forget about the mounted image. Or how about you have connected an external drive or a flash drive and you can’t get to your desktop easily to eject them.

The Ejector app is a menu bar app that gives you a single place to see all the drives or disk images that have been mounted so you can eject them. This is one of my must-have apps on my Mac.