Skip to content
Choose a tag to compare


@danthorpe danthorpe released this Dec 23, 2015
· 860 commits to development since this release
Choose a tag to compare


This is a relatively large number of changes with some breaking changes from 2.4.*.

Breaking changes

  1. [OPR-140]: OperationObserver has been refactored to refine four different protocols each with a single function, instead of defining four functions itself.

    The four protocols are for observing the following events: did start, did cancel, did produce operation and did finish. There are now specialized block observers, one for each event.

    This change is to reflect that observers are generally focused on a single event, which is more in keeping with the single responsibility principle. I feel this is better than a single type which typically has either three no-op functions or consists entirely of optional closures.

    To observe multiple events using blocks: add multiple observers. Alternatively, create a bespoke type to observe multiple events with the same type.

    BlockObserver itself still exists, however its usage is discouraged and it will be removed at a later time. It may also be necessary to make syntactic changes to existing code, in which case, I recommend replacing its usage entirely with one or more of StartedObserver, CancelledObserver, ProducedOperationObserver or FinishedObserver, all of which accept a non-optional block.

  2. [OPR-139]: Removed Capabiltiy.Health. Because this capability imports HealthKit, it is flagged by the app review team, and an application may be rejecting for not providing guidance on its usage of HealthKit. Therefore, as the majority of apps probably do not use this capability, I have removed it from the standard application framework. It is available as a subspec through Cocoapods:

    pod 'Operations/+Health'


  1. [OPR-121,OPR-122, OPR-126, OPR-138]: Improves the built in logger. So that now:

    1. the message is enclosed in an @autoclosure.
    2. there is a default/global severity threshold
    3. there is a global enabled setting.

    Thanks to Jon (@jshier) for raising the initial issue on this one.

  2. [OPR-128]: Improves how code coverage is generated.

    Thanks to Steve (@stevepeak) from for helping with this.

  3. [OPR-133, OPR-134]: DelayOperation and BlockOperation have improved response to being cancelled.

    Thanks to Jon (@jshier) for raising the initial issue on this one.

  4. [OPR-132]: BlockObserver now supports a cancellation handler. However see the notes regarding changes to OperationObserver and BlockObserver above under breaking changes.

  5. [OPR-135,OPR-137]: Result Injection.

    It is now possible to inject the results from one operation into another operation as its requirements before it executes. This can be performed with a provided block, or automatically in the one-to-one, result-to-requirement case. See the programming guide for more information.

    Thanks very much to Frank (@difujia) for the inspiration on this, and Jon (@jshier) for contributing to the discussion.

  6. [OPR-141]: Operation now uses precondition to check the expectations of public APIs. These are called out in the function’s documentation. Thanks to the Swift evolution mailing list & Chris Lattner on this one.

  7. [OPR-144, OPR-145]: Supports adapting the internal logger to use 3rd party logging frameworks. The example project uses SwiftyBeaver as a logger.

    Thanks to Steven (@shsteven) for raising the issue on this one!

  8. [OPR-148]: Location operations now conform to ResultOperationType which means their result (CLLocation, CLPlacemark) can be injected automatically into appropriate consuming operations.

Bug Fixes

  1. [OPR-124]: Fixes a bug where notification names conflicted.

    Thanks to Frank (@difujia) for this one.

  2. [OPR-123,OPR-125, OPR-130]: Fixes a bug where a completion block would be executed twice.

    Thanks again to Frank (@difujia) for raising the issue.

  3. [OPR-127, OPR-131]: Fixes a bug where an operation could fail to start due to a race condition. Now, if an operation has no conditions, rather than entering a .EvaluatingConditions state, it will immediately (i.e. synchronously) become .Ready.

    Thanks to Kevin (@kevinbrewster) for raising this issue.

  4. [OPR-142]: Operation now checks the current state in comparison to .Ready before adding conditions or operations. This is unlikely to be a breaking change, as it is not a significant difference.

    Thanks to Frank (@difujia) for this one.

  5. [OPR-146]: Fixes a subtle issue where assessing the readiness could trigger state changes.

Thanks to @difujia, @jshier, @kevinbrewster, @shsteven and @stevepeak for contributing to this version. :)