The Point of Redacted SwiftUI: Part 1

Episode #117 • Sep 14, 2020 • Subscriber-Only

Not only can we easily redact the logic from a view using the Composable Architecture, but we can also insert new logic into our views without making any changes to the core logic of the view. To demonstrate this we will build an onboarding flow for a more complex application.

Part 1
What’s the point?
Redacting a todo app
Todo onboarding
Next time: guided onboarding

Unlock This Episode

Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.


This is so incredibly powerful, and this is what it means to take “separation of concerns” seriously. We have truly separated the logic from the view, so much so that we can wholesale replace the logic for a view with anything we want.

This episode is for subscribers only.

Subscribe to Point-Free

Access this episode, plus all past and future episodes when you become a subscriber.

See plans and pricing

Already a subscriber? Log in


  1. The unredacted helper is super cool, but it might be nicer to define a more general view modifier that can transform the current view in a trailing closure. Define an applying helper that would allow us to replace our unredacted code above:

    //.unredacted(if: self.onboardingStep == .filters)
    .applying {
      if self.onboardingStep == .filters {
      } else {
    extension View {
      func applying<V: View>(
        @ViewBuilder _ builder: @escaping (Self) -> V
      ) -> some View {
  2. Update the onboarding flow to allow for interacting with navigation actions when on the actions step.


    Watch next week’s episode 😁

  3. Update the onboarding flow to allow for filtering when on the filters step.


    Watch next week’s episode 😁

  4. Update the onboarding flow to allow for interacting with todos when on the todos step. How might you maintain the live behavior where completed todos are sorted to the bottom of the todos list after a second?


    Watch next week’s episode 😁


Separation of Concerns

“Separation of Concerns” is a design pattern that is expressed often but is a very broad guideline, and not something that can be rigorously applied.