Fixes #3.

Aspects is a significantly thinner library than RAC, yet still provides the feature we're interested in: a block-based callback for a message-send. This even simplifies the implementation by discarding the extra power (and thus complexity) that RAC provides.

When I try to use the class I get the following error:

Cannot convert value of type '(_) -> ()' to expected argument type 'Any!'

I'm not sure it can be the cause but I'm using Swift 4.

My code is as follows: perform(.embedPromotions) { promotionsVC in promotionsPageController = promotionsVC promotionsPageController.promotionsData = promotionsData }

Any help will be greatly appreciated.

It'd be nice to be able to do this (and our code does only use the app extension API), but since we're linking in Aspects (which doesn't only use the app extension API), we actually can't make that guarantee. We should disable it to avoid the resulting warnings as well as any confusion that we might run into.

Upgrades the pod from using Swift 4 to Swift 4.2, avoiding having to do compatibility checks in the Podfile of a project built in Xcode 10.1 (specifying the version of Swift needed to build the target, such as https://github.com/CocoaPods/CocoaPods/issues/6791).

After this is merged to master, the plan is to tag 2.0.0. Going forward, future development will likely be for Swift 3 unless there's a compelling reason to backport the change to Swift 2.

The use of _printHierarchy is purely for debugging purposes, and should be excluded from release builds where it could cause app rejections.

Unfortunately this means that anyone using prebuilt Carthage binaries probably will never see the debug version of the message.

Fixes #6.

Simplifies passing dependencies to tabs within a tab bar controller by searching within each tab's view controller hierarchy for a matching view controller to configure.

It would be nice to expose the functionality of UIStoryboardSegue.destinationViewController(ofType:) in a more general way that is useful in different contexts.

For example, lets say you wanted to configure the tabs in a UITabBarController:

final class MyTabBarController: UITabBarController {
  override func viewDidLoad() {
    super.viewDidLoad()

    nextTab: for tab in viewControllers {
      for child in tab.hierarchy {
        switch child {
        case let feed as FeedViewController:
          // configure feed
          continue nextTab
        case let profile as ProfileViewController:
          // configure profile
          continue nextTab
        }
      } 
    }
  }
}

For each tab, this code searches the view controller hierarchy until it finds a matching view controller, then continues to the next tab.

This would be more concise:

for tab in viewControllers {
  if let feed = tab.childViewController(ofType: FeedViewController.self) {
    // configure feed
  }

  if let profile = tab.childViewController(ofType: ProfileViewController) {
    // configure profile
  }
}

But has the disadvantage of searching each tab N times, where N is the number of different things you need to configure.

I think there should be a way to encapsulate the first search strategy using a higher-level construct.

I decided to try and test drive this, which worked pretty well, as it uncovered a weird Swift type checker behaviour (that is quite possibly a bug).

See commit log for more info.

Why

• Old Xcode version used on Circle was causing tests to fail.
• Circleci 1.0 is going away on March 15 (~a week from today)

How

• Specify Xcode 10.1.0 and use circle 2.0

We currently use RAC to dynamically implement prepareForSegue(_:sender:), but it's not exposed via the public API. It really simplifies this library, but it would be nice to investigate removing that dependency before 1.0.

CocoaPods and Carthage are awesome tools and make our life really easier, but there are some devs who still don't know how to use them.

It would be cool to add the Manual installation guide in your README.md. You can take a look at my iOS Readme Template to see how you can do it.

This is a pretty useful method for doing DI with UITabBarController, but there's currently no documentation for it other than the documentation comment.