The third release of the week updated our SwiftUINavigation library to take advantage of the @CasePathable macro. When that macro is applied to your enums describing all possible navigation destinations for a feature:

@Observable
class FeatureModel {
  var destination: Destination?
  
  @CasePathable
  enum Destination {
    case activity(ActivityModel)
    case settings(SettingsModel)
  }
  
  …
}

…then you get instant access to a simpler way of driving navigation off of that state:

-.navigationDestination(
-  unwrapping: $model.destination,
-  case: /FeatureModel.Destination.activity
-) { model in
+.navigationDestination(item: $model.destination.activity) { model in
   ActivityView(model: model) 
 }
-.sheet(
-  unwrapping: $model.destination,
-  case: /FeatureModel.Destination.settings
-) { model in
+.sheet(item: $model.destination.settings) { model in
   SettingsView(model: model)
 }

There’s no need to use a custom view modifier, and you get the benefits of Xcode autocomplete and type inference.

And finally we released an update to our Dependencies library that introduces a new @DependencyClient macro. If you design your dependencies using a struct interface rather than protocol, then you can apply this macro to your dependency like so:

@DependencyClient
struct AudioPlayerClient {
  var loop: (_ url: URL) async throws -> Void
  var play: (_ url: URL) async throws -> Void
  var setVolume: (_ volume: Float) async -> Void
  var stop: () async -> Void
}

This does a few things for you:

• It automatically generates a default implementation of the interface that simply throws an error and triggers an XCTest failure in each endpoint. You can create this instance by doing AudioPlayerClient(), and this is the best implementation to use for testValue when registering the dependency with the library.

• It defines methods with named arguments for each closure endpoint in the interface. This fixes one of the biggest downsides to using structs to model dependencies:

  -audioPlayer.play(URL(string: …))
  +audioPlayer.play(url: URL(string: …))
  

• It generates a public initializer for the client type that specifies every property in the type. That means you do not need to provide this initializer yourself if you separate the interface of your dependency from its implmenetation in separate modules, as is recommended for dependencies that take a long time to compile.

We did not release any updates to our Macro Testing this week, but we did want to give it a special shoutout for making it possible to test each of the macros released this week. Our assertMacro tool was immensely helpful in testing all of the tiny edge cases of our macros, of which there were many.

Shortly after releasing @CasePathable it was brought to our attention that we were not handling cases with multiple wildcard argument labels, for example:

case action(_ id: Int, _ message: String)

Luckily the fix was straightforward, and in order to test the fix all one has to do is invoke assertMacro with the string of code that you want to be expanded:

func testWildcard() {
  assertMacro {
    """
    @CasePathable enum Foo {
      case bar(_ int: Int, _ bool: Bool)
    }
    """
  }
}

Then run the test, and the expanded macro code will be generated and inserted directly into the test file. This makes it incredible easy to write as many tests as it takes to get confidence that you have covered all of your bases.

And we wrote a lot of tests. For example, our Dependencies library has 40 tests for its macros, exercising every little edge case we could think of:

• What happens when your client has a mixture of public and private endpoints?

• What happens when your client has computed properties?

• What happens with @Sendable and @MainActor attributes applied to closures?

• And a lot more…

We are even able to write simple tests that assert our macro’s diagnostics behave how we expect. For example, the @Reducer macro performs a light touch of linting on your reducer in order to make sure you don’t accidentally implement the reduce(into:action:) requirement and body requirement at the same time. Doing so is invalid, but the Swift compiler can’t help you, whereas our macro can.

And if all of that wasn’t good enough, if we ever make a fundamental change to our macro and want to re-record all macro expansions at once, that is as easy as a single line change:

override func invokeTest() {
  withMacroTesting(
    isRecording: true,
    macros: [DependencyClientMacro.self]
  ) {
    super.invokeTest()
  }
}

By putting the test suite in “record mode”, the Macro Testing library will automatically write the freshest macro expansion into the test files.

That concludes this week’s Macro Bonanza! Make sure you update all of your dependencies on our libraries to take advantage of these new tools, and let us know what you think!