Oliver Foggin - ios

Functional Thinking in Swift: Part 3 - The power of Reduce

2026-03-07T00:00:00+00:00

In Part 2</a> we looked at filter</code> and reduce</code> and how we can use them to shape the data that we start with. Removing elements with filter</code> or even combining them like adding numbers with reduce</code>.</p>

In this part we will show how reduce</code> is the powerhouse of the functional tools available. How it can be used to perform the same tasks that filter</code> and map</code> perform, but can also be used to create some really powerful ways of manipulating data.</p>

Map with reduce

#</span></a>
</h2>
To show how reduce</code> is really the primitive function that can be used to derive others, let's look at how we might map</code> an array and convert that to reduce</code>.</p>
let</span> numbers </span>=</span> [</span>1</span>, </span>2</span>, </span>3</span>, </span>4</span>]</span></span>
</span>
// The Map version</span></span>
let</span> doubled </span>=</span> numbers.</span>map</span> {</span> $0</span> *</span> 2</span> }</span></span>
</span>
// The Reduce version</span></span>
let</span> doubledWithReduce </span>=</span> numbers.</span>reduce</span>(</span>into</span>:</span> []</span>) {</span> acc, number </span>in</span></span>
  acc.</span>append</span>(</span>number </span>*</span> 2</span>)</span></span>
}</span></span></code></pre>
Here we can see that map</code> is just a specific implementation of reduce</code> where the accumulator is a new array and each operation appends into that new array.</p>
Filter with reduce#</span></a>
</h2>
Just as with map</code>, we can also perform a filter</code> with reduce</code>.</p>
let</span> numbers </span>=</span> [</span>1</span>, </span>2</span>, </span>3</span>, </span>4</span>]</span></span>
</span>
// The Filter version</span></span>
let</span> evens </span>=</span> numbers.</span>filter</span> {</span> $0.</span>isMultiple</span>(</span>of</span>:</span> 2</span>) }</span></span>
</span>
// The Reduce version</span></span>
let</span> evensWithReduce </span>=</span> numbers.</span>reduce</span>(</span>into</span>:</span> []</span>) {</span> acc, number </span>in</span></span>
  if</span> number.</span>isMultiple</span>(</span>of</span>:</span> 2</span>) {</span></span>
    acc.</span>append</span>(</span>number</span>)</span></span>
  }</span></span>
}</span></span></code></pre>
You can see a similar pattern here that we used for map</code>. We start from an empty array, but this time we only append if the number matches our condition.</p>
Reduce() and Reduce(into:)#</span></a>
</h2>
In both these examples we use reduce(into: [])</code>. This gives us an inout</code> value that we can mutate in the closure and can be more performant when we're returning a collection.</p>
The alternative is to use the version reduce([])</code>, in which we still provide an initial value, but this is not mutable in the closure and we must return the new value. This is better for use when we're reducing into a single value like summing an array of ints.</p>
Partitioning by value#</span></a>
</h2>
Here we've seen reduce</code> not just outputting a single value but an array. We can go further by really pushing the power of reduce</code>.</p>
If we have an array of dates, we might want to split those dates into groups of the same calendar month. At first this seems like it might be easier to start building up from scratch the imperative way. Start with an empty array, create a new array to build up the first month, then append to the parent array when reaching a new month, etc.</p>
But we can reduce (pun intended) this down in complexity and solve the problem once so that we can partition any sorted array into like groups.</p>
Thinking in data pipelines#</span></a>
</h2>
When using functional ideas I often find it easier to think about data pipelines. That is, what is it that we want to get out of the data at each point.</p>
For this problem we start with a sorted array of dates:</p>
[date1, date2, date3, </span>...</span>, dateN]</span></span></code></pre>
And out of it we want a nested array of dates where each subarray contains dates from the same calendar month.</p>
[[date1, date2], [date3, date4, date5], </span>...</span>, [</span>...</span>, dateN]]</span></span></code></pre>
As we work along the input we're going to have to ask ourselves what are the states we can be in? In this case, there are three possible states.</p>

The output array is empty. We haven't started yet.</li>
The last sub-array of the output array contains dates in the same month as the next date.</li>
The last sub-array of the output array contains dates in a different month as the next date.</li>
</ul>
In the above cases we can deal with each by:</p>

Just append a new array with the next date in it.</li>
Append the next date into the last sub-array.</li>
Just append a new array with the next date in it.</li>
</ul>
We can see that 1 and 3 require the same work, so we can combine these. Once we have these written down we can start to implement the grouping function.</p>
let</span> sortedDates:</span> [</span>Date</span>]</span> = ...</span></span>
</span>
// We know we need a nested array.</span></span>
let</span> groupedByMonth:</span> [[</span>Date</span>]]</span> =</span> sortedDates.</span>reduce</span>(</span>into</span>:</span> []</span>) {</span> acc, next </span>in</span></span>
  // First deal with case 2.</span></span>
  if let</span> lastDate </span>=</span> acc.last</span>?</span>.last,</span></span>
     Calendar.current.</span>isDate</span>(</span>next, </span>equalTo</span>:</span> lastDate, </span>toGranularity</span>:</span> .month</span>)</span></span>
  {</span></span>
    acc</span>[</span>acc.count</span> -</span> 1</span>]</span>.</span>append</span>(</span>next</span>)</span></span>
  }</span> else</span> {</span></span>
    // Everything else goes in here.</span></span>
    acc.</span>append</span>(</span>[next]</span>)</span></span>
  }</span></span>
}</span></span></code></pre>
This is great, but what if we want to group by dates in the same day, or year? Or what if we want to group by something else completely? Perhaps we want to group students by grade boundaries?</p>
Extracting the logic#</span></a>
</h2>
When working with functional patterns we often find that once we've written something like the above we can dissect it to remove the specifics about that scenario but still keep the logic around what it's doing.</p>
In this case, the specific logic is the check that the next date is in the same month as the last. Everything else is just the work to build the chunked array.</p>
We can extract that and allow the developer to provide that logic for us. Let's create a new group</code> function that does just this by providing a closure. The only thing we need to know is, given two elements, should they be in the same group or different. So we need two elements in and a bool out.</p>
extension</span> Array</span> {</span></span>
  // This is our new function with our closure.</span></span>
  func</span> group</span>(</span>by</span> matches</span>: </span>(</span>Element</span>, </span>Element</span>)</span> -></span> Bool</span>)</span> -></span> [[</span>Element</span>]] {</span></span>
    // Here we can use the same reduce but generalise it with the closure.</span></span>
    reduce</span>(</span>into</span>:</span> []</span>) {</span> acc, next </span>in</span></span>
      if let</span> prev </span>=</span> acc.last</span>?</span>.last,</span></span>
         matches</span>(</span>prev, next</span>) {</span></span>
        acc</span>[</span>acc.count</span> -</span> 1</span>]</span>.</span>append</span>(</span>next</span>)</span></span>
      }</span> else</span> {</span></span>
        acc.</span>append</span>(</span>[next]</span>)</span></span>
      }</span></span>
    }</span></span>
  }</span></span>
}</span></span>
</span>
let</span> sortedDates </span>=</span> [</span>...</span>]</span></span>
</span>
// Now we can group by month.</span></span>
let</span> groupedByMonth </span>=</span> sortedDates.</span>group</span> {</span></span>
  Calendar.current.</span>isDate</span>(</span>$0, </span>equalTo</span>:</span> $1, </span>toGranularity</span>:</span> .month</span>)</span></span>
}</span></span>
</span>
// Or we can group by day.</span></span>
let</span> groupedByDay </span>=</span> sortedDates.</span>group</span> {</span></span>
  Calendar.current.</span>isDate</span>(</span>$0, </span>equalTo</span>:</span> $1, </span>toGranularity</span>:</span> .day</span>)</span></span>
}</span></span>
</span>
// Or we can sort by something else entirely.</span></span>
let</span> groupedByGradeBoundary </span>=</span> sortedStudents.</span>group</span> {</span></span>
  $0.grade</span> ==</span> $1.grade</span></span>
}</span></span></code></pre>
By doing this we have created a reusable chunking algorithm that we can take to any project and reuse any time we need to chunk our data this way.</p>
We could even chain this together to group by year then month.</p>
let</span> monthYearGroups </span>=</span> sortedDates</span></span>
  .</span>group</span> {</span> last, next </span>in</span> // (Date, Date) -> Bool</span></span>
    Calendar.current.</span>isDate</span>(</span>next, </span>equalTo</span>:</span> last, </span>toGranularity</span>:</span> .month</span>)</span></span>
  }</span></span>
  .</span>group</span> {</span> last, next </span>in</span> // ([Date], [Date]) -> Bool</span></span>
    // This algorithm ensures that both values have at least one element,</span></span>
    // so we can safely force unwrap the first.</span></span>
    Calendar.current.</span>isDate</span>(</span>next.first</span>!</span>, </span>equalTo</span>:</span> last.first</span>!</span>, </span>toGranularity</span>:</span> .year</span>)</span></span>
  }</span></span></code></pre>
This small reusable function that we have created has encapsulated the work of grouping arrays into matching groups and allowed us to put the hard work in up front of understanding the problem and finding a solution.</p>
When to build functional tools#</span></a>
</h2>
Building functional tools like this builds up a toolkit of functions that can be used across multiple projects and each one is solved, tested, verified, and ready to be plugged in to your data.</p>
The trigger for building a function like this is boilerplate friction. If you find yourself writing the scaffolding, the empty arrays, the loops, the index management, more than the actual business logic, you've found a candidate for a functional tool. Move the how into an extension so your main code can stay focused on the what.</p>



Functional Thinking in Swift: Part 2 - Filter & Reduce
2025-12-23T00:00:00+00:00
In Part 1</a> we looked at map</code> and how it helps us transform data. But transforming data is only half the battle; often, we need to narrow down our datasets or combine them into a single value. This is where filter</code> and reduce</code> come in.</p>
We will look at how filter</code> and reduce</code> work on their own and what they do, but then also how we can compose these functions together to unlock the "super power" of functional thinking in Swift.</p>
Filter: The Gatekeeper#</span></a>
</h2>
The filter</code> function does exactly what it says on the tin: it takes a collection and returns a new collection containing only the elements that satisfy a specific condition.</p>
The Imperative Way#</span></a>
</h3>
Before functional patterns, we would create a "mutable bucket," loop through our data, and manually append items that meet our criteria.</p>
let</span> numbers </span>=</span> [</span>1</span>, </span>2</span>, </span>3</span>, </span>4</span>, </span>5</span>, </span>6</span>, </span>7</span>, </span>8</span>, </span>9</span>, </span>10</span>]</span></span>
var</span> evenNumbers:</span> [</span>Int</span>]</span> =</span> []</span></span>
</span>
for</span> number </span>in</span> numbers </span>{</span></span>
  if</span> number </span>%</span> 2</span> ==</span> 0</span> {</span></span>
    evenNumbers.</span>append</span>(</span>number</span>)</span></span>
  }</span></span>
}</span></span>
// result: [2, 4, 6, 8, 10]</span></span></code></pre>The Functional Way#</span></a>
</h3>
With filter</code>, we get rid of the "how" (the loop and the manual appending) and focus on the "what" (the logic).</p>
let</span> evenNumbers </span>=</span> numbers.</span>filter</span> {</span> $0</span> %</span> 2</span> ==</span> 0</span> }</span></span></code></pre>
Just as map</code> removes the logic, mutations, and iterations of how to create your new container, filter</code> does the same thing, removing the logic of how to filter and instead focusing on what to filter.</p>
Reduce: The Assembler#</span></a>
</h2>
reduce</code> is used to combine all the items in a collection into a single value. This could be a sum, a string concatenation, or even a new dictionary.</p>
The Imperative Way#</span></a>
</h3>
To sum an array, we usually create a variable at zero and add to it piece by piece.</p>
let</span> prices </span>=</span> [</span>10.0</span>, </span>20.0</span>, </span>30.0</span>]</span></span>
var</span> total:</span> Double</span> =</span> 0</span></span>
</span>
for</span> price </span>in</span> prices </span>{</span></span>
  total </span>+=</span> price</span></span>
}</span></span>
// total: 60.0</span></span></code></pre>The Functional Way#</span></a>
</h3>
reduce</code> takes two arguments: an initial value and a closure that defines how to combine the current running total with the next element.</p>
let</span> total </span>=</span> prices.</span>reduce</span>(</span>0</span>, </span>{</span> runningTotal, nextPrice </span>in</span></span>
  runningTotal </span>+</span> nextPrice</span></span>
})</span></span>
</span>
// Even shorter version using Swift's operator shorthand:</span></span>
let</span> total </span>=</span> prices.</span>reduce</span>(</span>0</span>, </span>+</span>)</span></span></code></pre>Composing the Trio: Map, Filter, and Reduce#</span></a>
</h2>
The real power of functional programming in Swift is composition. Because these functions return new collections, you can chain them together to perform complex data processing in a single, readable pipeline.</p>
The scenario: we have a list of orders. We want to find all orders over $50, apply a 10% tax to them, and then find the grand total.</p>
The All-in-One Pipeline#</span></a>
</h3>
struct</span> Order</span> {</span></span>
  let</span> id:</span> Int</span></span>
  let</span> amount:</span> Double</span></span>
}</span></span>
</span>
let</span> orders </span>=</span> [</span></span>
  Order</span>(</span>id</span>:</span> 1</span>, </span>amount</span>:</span> 20.0</span>)</span>,</span></span>
  Order</span>(</span>id</span>:</span> 2</span>, </span>amount</span>:</span> 60.0</span>)</span>,</span></span>
  Order</span>(</span>id</span>:</span> 3</span>, </span>amount</span>:</span> 100.0</span>)</span></span>
]</span></span>
</span>
let</span> grandTotal </span>=</span> orders</span></span>
  .</span>filter</span> {</span> $0.amount</span> ></span> 50</span> }</span> // Keep only expensive orders.</span></span>
  .</span>map</span> {</span> $0.amount</span> *</span> 1.10</span> }</span>  // Add 10% tax.</span></span>
  .</span>reduce</span>(</span>0</span>, </span>+</span>)</span>              // Sum them up.</span></span>
</span>
print</span>(</span>grandTotal</span>)</span> // 176.0</span></span></code></pre>
By chaining these functions together we have avoided creating multiple var</code>s along the way. For instance, there is no need for an ordersOver50</code> array. Or even an ordersWithTax</code> array. Or a totalValue</code> var to hold the accumulative total.</p>
At each point we just describe what it is we want from the data.</p>
Wait... Can this be a Filter or Reduce?#</span></a>
</h2>
We've all been there typing out yet another for</code> loop. But before you hit enter, take a second to look at the "shape" of the code you're about to write. Just like we learned to spot a map</code> by seeing a transformation, filter</code> and reduce</code> have their own distinct scents.</p>
The Filter Smell: The Selective Picker#</span></a>
</h3>
If you find yourself writing a loop that contains a single if</code> statement just to decide whether or not to append an item to a new array, you're writing a filter</code>.</p>
The sign: You have a bucket array, var results = []</code>, and a loop that says: "If this specific thing is true, put it in the bucket."</p>
The fix: Stop managing the bucket. Use .filter { ... }</code> and just provide the truth logic.</p>
The Reduce Smell: The Master Assembler#</span></a>
</h3>
If you see a standalone variable sitting right above a loop, like var total = 0</code> or var combinedString = ""</code>, and that variable gets updated every single time the loop ticks, you're looking at a reduce</code>.</p>
The sign: You are folding a whole list of items down into one single result. Whether you're summing prices, building a sentence, or even flattening nested data, if the list goes in and one single thing comes out, it's a reduce</code>.</p>
The fix: Ditch the mutable variable. Use .reduce(initialValue) { ... }</code> to assemble your result in one clean shot.</p>
Recognizing these patterns is like developing a superpower. Instead of reading how the computer is moving bits around, you start reading what your data is actually doing.</p>
Coming Up in Part 3: The Power of Reduce#</span></a>
</h2>
While we used reduce</code> here to sum numbers, it is secretly the most powerful function in the functional toolkit. In the next part, we will explore how reduce</code> can actually build other functions like map</code> and filter</code>, and how to use it for complex tasks like partitioning data into groups, such as grouping objects by month.</p>


Functional Thinking in Swift: Part 1 - Map
2025-12-16T00:00:00+00:00
Often, when people talk about Functional Programming (FP), it can become very abstract or academic, and the practical essence gets lost. This is especially true if it's not a paradigm you are used to; it requires a different way of thinking compared to the standard imperative approaches usually taught to beginners.</p>
Swift gives us small functional tools that we often use without realizing they are "functional." As Swift isn't a pure FP language, we aren't trying to rewrite our entire app using strict FP. We simply want to use the tools we are given to simplify our code.</p>
I'd like to build up a toolkit of these functional Swift tools so we can leverage some powerful, compositional thinking without getting lost in abstract definitions.</p>
Why functional thinking?#</span></a>
</h2>
Functional thinking isn't about writing "clever" code. It's about changing the way you think about code. Instead of focusing on steps and mutable state, you focus on data flowing through small, predictable transformations.</p>
This shift makes your intentions clearer, reduces hidden complexity, and leads to code that behaves the same way every time you run it. In other words: fewer surprises, fewer accidental edge cases, and a more deterministic system overall. Even the simplest functional tools, like map</code>, start training your brain to express what should happen rather than how to make it happen, and that mindset scales beautifully as your codebase grows.</p>
The Map function#</span></a>
</h2>
At its core, map</code> just means:</p>
Take a container of items. Transform the items. Return a new container of the transformed items.</p>
That's it.</p>
Let's look at a super small example first.</p>
The imperative version:</p>
let</span> numbers </span>=</span> [</span>1</span>, </span>2</span>, </span>3</span>]</span></span>
var</span> doubled:</span> [</span>Int</span>]</span> =</span> []</span></span>
</span>
for</span> i </span>in</span> numbers </span>{</span></span>
  doubled.</span>append</span>(</span>i </span>*</span> 2</span>)</span></span>
}</span></span>
// doubled = [2, 4, 6]</span></span></code></pre>
The functional equivalent using map</code>:</p>
let</span> doubled </span>=</span> [</span>1</span>, </span>2</span>, </span>3</span>].</span>map</span> {</span> $0</span> *</span> 2</span> }</span></span>
// doubled = [2, 4, 6]</span></span></code></pre>
Here, we have taken a container, Array</code>, of items, Int</code>, and transformed them by doubling their value into a new container, Array</code>, of items, Int</code>.</p>
Rather than describing the steps to get there, we have described what we want the output to be: "An array where each value is double the value of the source array."</p>
Why does this matter?#</span></a>
</h2>
map</code> has done a few really nice things for us here:</p>

Declarative Style: We describe what we want rather than how to create it. No counters, no appending, and no manual iteration.</li>
Immutability: There is no mutation of values. Since many Swift containers are value types (copy-on-write), avoiding mutation gives us better clarity, thread safety, and predictability.</li>
Clearer Intent: "Transform these values" is much easier to read at a glance than "iterate over these values and accumulate them into a new variable."</li>
Safety: We don't have to worry about what to do if the container is empty. map</code> handles empty containers gracefully.</li>
</ul>
It works across many types#</span></a>
</h2>
The definition of map</code> doesn't talk about Array</code>; it talks about "containers," and there are many different types of containers in Swift. All of them are mappable.</p>
In every case, the function does the same thing: transform the contents of the container and return a new container with the new contents.</p>
Optional#</span></a>
</h3>
Because Optional</code> is a container, it contains either some value or none, we can map it. We get back another Optional</code> of the transformed type.</p>
let</span> title:</span> String</span>? =</span> "Hello, World!"</span></span>
let</span> titleLength </span>=</span> title.</span>map</span> {</span> $0.count</span> }</span></span>
// titleLength is Int? (13)</span></span>
</span>
let</span> name:</span> String</span>? =</span> nil</span></span>
let</span> nameLength </span>=</span> name.</span>map</span>(</span>\.count</span>)</span></span>
// nameLength is nil</span></span></code></pre>
Here, map</code> transforms the contents without changing the type of the container. If the value is nil</code>, we simply get nil</code> back. This saves a lot of if let</code> unwrapping and safety checking.</p>
Result#</span></a>
</h3>
Result</code> is also a container. It contains either a .success</code> value or a .failure</code> error. map</code> will transform the Success</code> value if it exists, leaving the Failure</code> case untouched.</p>
let</span> result: Result</span><</span>User, </span>any</span> Error</span>></span> =</span> .</span>success</span>(</span>userData</span>)</span></span>
let</span> userName </span>=</span> result.</span>map</span> {</span> $0.name</span> }</span></span>
// userName is Result<String, any Error> with the .success case.</span></span>
</span>
let</span> result: Result</span><</span>User, </span>any</span> Error</span>></span> =</span> .</span>failure</span>(</span>error</span>)</span></span>
let</span> userAge </span>=</span> result.</span>map</span>(</span>\.age</span>)</span></span>
// userAge is Result<Int, any Error> with the .failure(error) case.</span></span></code></pre>A real-world example#</span></a>
</h2>
As a more "real" example, let's imagine a network call to a weather API that we want to call and then map into our view models.</p>
struct</span> WeatherCityDTO</span>:</span> Decodable</span> {</span></span>
  let</span> id: UUID</span></span>
  let</span> city:</span> String</span></span>
  let</span> humidity:</span> Double</span>?</span></span>
  let</span> temperatureCelsius:</span> Double</span></span>
}</span></span>
</span>
struct</span> CityViewModel</span> {</span></span>
  let</span> name:</span> String</span></span>
  let</span> humidityTitle:</span> String</span>?</span></span>
  let</span> tempTitle:</span> String</span></span>
}</span></span>
</span>
func</span> fetchCityWeather</span>()</span> async throws</span> -></span> [</span>CityViewModel</span>] {</span></span>
  try await</span> networkClient.</span>fetchCities</span>()</span></span>
    .</span>map</span> {</span> cityDTO </span>in</span></span>
      CityViewModel</span>(</span></span>
        name</span>:</span> cityDTO.city,</span></span>
        // Using map on the Optional property inside the Array map.</span></span>
        humidityTitle</span>:</span> cityDTO.humidity.</span>map</span> {</span> humidityDescription</span>(</span>from</span>:</span> $0</span>) }</span>,</span></span>
        tempTitle</span>:</span> "</span>\(</span>cityDTO.temperatureCelsius.</span>rounded</span>())</span>°C"</span></span>
      )</span></span>
    }</span></span>
}</span></span></code></pre>
We've used map</code> to take an array of WeatherCityDTO</code> from a network call and transformed it into an array of our own view models. We also used map</code> to optionally create a humidityTitle</code> if the humidity exists in the DTO.</p>
All without mutating an array or creating a single for</code> loop.</p>
The Trap: When Map Isn't Enough#</span></a>
</h2>
map</code> is fantastic when you have a 1-to-1 transformation. You put one thing in, you get one transformed thing out.</p>
But what happens if your transformation also returns a container?</p>
Imagine you have an array of String</code> identifiers, and you want to turn them into URLs:</p>
let</span> strings </span>=</span> [</span>"https://www.apple.com"</span>, </span>"broken-link"</span>]</span></span>
let</span> urls </span>=</span> strings.</span>map</span> {</span> URL</span>(</span>string</span>:</span> $0</span>) }</span></span>
// Result: [Optional<URL>, Optional<URL>]</span></span></code></pre>
Because URL(string:)</code> returns an optional, map</code> wraps that optional inside the array. You end up with an array of optionals, [URL?]</code>, which is usually annoying to work with. You technically have a container inside a container.</p>
Or, what if you want to map over a list of user IDs and fetch their recent posts?</p>
let</span> userIDs </span>=</span> [</span>1</span>, </span>2</span>, </span>3</span>]</span></span>
let</span> posts </span>=</span> userIDs.</span>map</span> {</span> fetchPosts</span>(</span>for</span>:</span> $0</span>) }</span></span>
// Result: [[Post], [Post], [Post]]</span></span></code></pre>
You end up with an array of arrays.</p>
This is where map</code> hits its limit. When the shape of your data starts getting nested, optionals inside arrays, or arrays inside arrays, map</code> can't flatten that structure for you.</p>
Next time#</span></a>
</h2>
This limitation is exactly where our next set of tools comes in. In the next part, we will look at compactMap</code> and flatMap</code> to see how we can handle these nested containers gracefully.</p>
We will also look at filter</code> and reduce</code>, and eventually, how to compose all these simple tools together to perform powerful data transformations with readable, declarative code.</p>


Using custom reducers to make shared data even easier with TCA
2024-01-02T00:00:00+00:00
You can jump straight into the code here: swift-composable-subscriber</a>.</p>
In my recent article, Shared data in a TCA app</a>, I detailed how to use dependencies to store shared data that can be subscribed to from anywhere in your app.</p>
This means that anywhere in your app a reducer can return a run</code> effect from its body, loop on the values from an AsyncStream</code>, and return some other action to deal with the updated values.</p>
case</span> .task</span>:</span></span>
  return</span> .</span>run</span> {</span> send </span>in</span></span>
    for await</span> value </span>in await</span> someDependency.</span>valueStream</span>() {</span></span>
      await</span> send</span>(</span>.</span>newValueReceived</span>(</span>value</span>))</span></span>
    }</span></span>
  }</span></span></code></pre>
This makes it really easy to subscribe to any stream of data in your app and even keeps your reducers in sync when the data is updated.</p>
I then received a question on Mastodon from Ben Lings:</p>

Great stuff! This pattern has been very useful in the app we are building. I've been considering how to encapsulate accessing this sort of dependency in a higher order reducer, to reduce the task-foreach-send boilerplate. Any thoughts on that?</p>
</blockquote>
View the original Mastodon post</a>.</p>
And I was thinking about this in the app I'm working on currently. There are a few reducers that rely on multiple streams of data. This very quickly started to flood the reducer body with these same lines over and over again. We needed a way to refactor this out to make it easier to maintain whilst still giving us the control that we have here.</p>
This is where a custom reducer can come in to help us.</p>
The problem we are trying to solve can be described as:</p>

When an Action</code> occurs</li>
We should subscribe to some AsyncStream</code></li>
And when it receives a new value we should run some other Action</code></li>
</ul>
We can create this by creating our own custom reducer.</p>
I created a SubscriberReducer</code> that is generic over:</p>

Parent: Reducer</code>, because it needs to know about the Action</code> and State</code> of the parent.</li>
TriggerAction</code>, a specific action that will be used to trigger the subscription.</li>
StreamElement</code>, the type of element that the AsyncStream</code> will yield.</li>
Value</code>, the type of the value that we want to handle. This allows us to provide a transform if necessary.</li>
</ul>
By doing this we can create several helper functions like:</p>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.valueStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newValueReceived</span>)</span></span></code></pre>
This takes the five lines above and reduces it to a single line. And it allows us to add multiple subscriptions very easily.</p>
If the AsyncStream</code> type matches the action then we can just do this:</p>
Reduce</span> {</span> state, action </span>in</span></span>
  // This is the regular reducer.</span></span>
}</span></span>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.valueStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newValueReceived</span>)</span></span></code></pre>
If the type of the AsyncStream</code> doesn't match the action then you can provide a simple transform:</p>
Reduce</span> {</span> state, action </span>in</span></span>
  // This is the regular reducer.</span></span>
}</span></span>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.intStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newStringReceived</span>) {</span> intValue </span>in</span></span>
  "</span>\(</span>intValue</span>)</span>"</span></span>
}</span></span></code></pre>
And even if we have more complex logic that we need to run, we can do that also:</p>
Reduce</span> {</span></span>
  // This is the regular reducer.</span></span>
}</span></span>
.</span>subscribe</span>(</span></span>
  to</span>:</span> myDependency.stream,</span></span>
  on</span>:</span> \.some.trigger.action</span></span>
) {</span> send, streamElement </span>in</span></span>
  await</span> send</span>(</span>.responseAction</span>)</span></span>
  await</span> otherDependency.</span>doSomethingElse</span>(</span>with</span>:</span> streamElement</span>)</span></span>
}</span></span></code></pre>
This has been great for us as it has allowed us to greatly simplify the code involved when we have multiple subscriptions firing off. And it makes it much easier to read also:</p>
Reduce</span> {</span> state, action </span>in</span></span>
  // This is the regular reducer.</span></span>
}</span></span>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.userStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newUserDataReceived</span>)</span></span>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.chatStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newChatMessageReceived</span>)</span></span>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.reactionStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newReactionReceived</span>) {</span></span>
  Reaction</span>(</span>payload</span>:</span> $0</span>)</span></span>
}</span></span></code></pre>
Custom reducers can really help shift a lot of the cognitive load of your app so that you don't have to worry about it at code time and it makes for easier reading and understanding too.</p>
What custom reducers have you been able to create to help you offload repetitive work and reduce cognitive load?</p>
I hope this has helped you. You can find my code and SPM package on GitHub: swift-composable-subscriber</a>.</p>


Leveraging custom Reducers to manage actions in your TCA app
2023-12-19T00:00:00+00:00
As your TCA app grows, each feature accumulates more and more actions that it has to manage.</p>
This could be UI actions, internal actions, child feature actions, delegate actions, etc.</p>
enum</span> Action</span> {</span></span>
  case</span> onAppear</span></span>
  case</span> task</span></span>
  case</span> buttonTapped</span></span>
  case</span> closeButtonTapped</span></span>
  case</span> downloadResponse</span>(</span>Result</span><</span>UserInfo</span>>)</span></span>
  case</span> userProfile</span>(</span>UserProfile.State</span>)</span></span>
  case</span> favourites</span>(</span>Favourites.State</span>)</span></span>
  case</span> dismissFeature</span></span>
}</span></span></code></pre>
After a while it becomes difficult to know which actions are which and we need a way to separate them. A widely used pattern is to create nested actions that hold onto only the actions relevant to it.</p>
enum</span> Action</span> {</span></span>
  case</span> view</span>(</span>ViewAction</span>)</span></span>
  case</span> internal</span>(</span>InternalAction</span>)</span></span>
  case</span> destination</span>(</span>PresentationAction</span><</span>Destination</span>>)</span></span>
  case</span> delegate</span>(</span>DelegateAction</span>)</span></span>
</span>
  enum</span> ViewAction</span> {</span></span>
    case</span> onAppear</span></span>
    case</span> task</span></span>
    case</span> buttonTapped</span></span>
    case</span> closeButtonTapped</span></span>
  }</span></span>
</span>
  enum</span> InternalAction</span> {</span></span>
    case</span> downloadResponse</span>(</span>Result</span><</span>UserInfo</span>>)</span></span>
  }</span></span>
</span>
  enum</span> Destination</span> {</span></span>
    case</span> userProfile</span>(</span>UserProfile.State</span>)</span></span>
    case</span> favourites</span>(</span>Favourites.State</span>)</span></span>
  }</span></span>
</span>
  enum</span> DelegateAction</span> {</span></span>
    case</span> dismissFeature</span></span>
  }</span></span>
}</span></span></code></pre>
This gives us nice separation of the actions, but it makes it more difficult to organise the reducer body.</p>
Reduce</span> {</span> state, action </span>in</span></span>
  switch</span> action </span>{</span></span>
  case</span> .view</span>(</span>.onAppear</span>)</span>: ...</span></span>
  case</span> .view</span>(</span>.task</span>)</span>: ...</span></span>
  case</span> .</span>internal</span>(</span>.downloadResponse</span>)</span>: ...</span></span>
  case</span> .</span>destination</span>(</span>.</span>presented</span>(</span>.userProfile</span>))</span>: ...</span></span>
  case</span> .delegate</span>: ...</span></span>
  case</span> .view</span>: ...</span></span>
  }</span></span>
}</span></span></code></pre>
It's very easy to get these in a muddle, lose exhaustivity, or duplicate logic unnecessarily.</p>
But there is a way to make this much easier for yourself.</p>
The Reducer</code> type can be a bit daunting when you begin looking into how it works, but a lot of the custom reducers provided by the TCA package use a similar pattern. By looking at that and duplicating what we see, we can begin to put together an idea of how we might improve the situation here.</p>
Wouldn't it be nice to create something that allowed us to spawn off a separate Reducer</code> just for a particular sub-action?</p>
Something like NestedAction(\.view)</code> that would give us a body in which we just have to deal with the ViewAction</code> actions without worrying about the others.</p>
At first this seems similar to what Scope</code> does, but in our case the problem is a bit more subtle. We're processing the ViewAction</code>, but then we want to return an Effect</code> that deals with the top-level Action</code> enum. If we don't do this then we wouldn't be able to do something like this from the view action reducer:</p>
return</span> .</span>send</span>(</span>.</span>delegate</span>(</span>.dismissFeature</span>))</span></span></code></pre>
Which is essential if we want our app to continue working. And also, we still want to be able to mutate the regular State</code> without having to scope it.</p>
So, we'll need something that is generic over State</code>, Action</code>, and ChildAction</code>, and provides a way to scope into the child action.</p>
This is what I came up with:</p>
// 1.</span></span>
@</span>Reducer</span></span>
public struct</span> NestedAction</span><</span>State</span>,</span> Action</span>,</span> ChildAction</span>> {</span></span>
  // 2.</span></span>
  @</span>usableFromInline</span></span>
  let</span> toChildAction: AnyCasePath</span><</span>Action, ChildAction</span>></span></span>
</span>
  // 3.</span></span>
  @</span>usableFromInline</span></span>
  let</span> toEffect:</span> (</span>inout</span> State, ChildAction</span>)</span> -></span> Effect</span><</span>Action</span>></span></span>
</span>
  @</span>inlinable</span></span>
  public init</span>(</span></span>
    _</span> toChildAction</span>: CaseKeyPath</span><</span>Action, ChildAction</span>></span>,</span></span>
    toEffect</span>: </span>@</span>escaping</span> (</span>inout</span> State, ChildAction</span>)</span> -></span> Effect</span><</span>Action</span>></span></span>
  ) {</span></span>
    self.toChildAction</span> =</span> AnyCasePath</span>(</span>toChildAction</span>)</span></span>
    self.toEffect</span> =</span> toEffect</span></span>
  }</span></span>
</span>
  public func</span> reduce</span>(</span>into</span> state</span>: </span>inout</span> State, </span>action</span>: Action</span>)</span> -></span> Effect</span><</span>Action</span>> {</span></span>
    // 4.</span></span>
    guard let</span> childAction </span>=</span> self.toChildAction.</span>extract</span>(</span>from</span>:</span> action</span>)</span> else</span> {</span></span>
      return</span> .none</span></span>
    }</span></span>
</span>
    // 5.</span></span>
    return</span> toEffect</span>(</span>&</span>state, childAction</span>)</span></span>
  }</span></span>
}</span></span></code></pre>
Let's unwrap what it's doing:</p>

We define our NestedAction</code> reducer and make it generic over State</code>, Action</code>, and ChildAction</code>.</li>
We have a property of a case path which tells us how to get from an Action</code> to the relevant ChildAction</code>.</li>
Finally, we have a closure which takes in State</code> and ChildAction</code> and returns an Effect<Action></code>. This is the subtle difference between this and the Reduce</code> reducer, as that will have a function from State</code>, Action</code> to Effect<Action></code>.</li>
In the body of our NestedAction</code> reducer we first check to see if the action coming in is one that we're interested in. We do this by trying to extract the ChildAction</code> from the Action</code> using the case path. If that doesn't work then we're not interested, so we just return a .none</code> effect.</li>
If the child action can be extracted then we pass it and the state into the closure and return any Effect</code> that comes from that.</li>
</ol>
Now that we've created our new reducer, let's put it into use.</p>
Let's deal with the view actions:</p>
// We create a new NestedAction reducer just for the view action.</span></span>
NestedAction</span>(</span>\.view</span>) {</span> state, action </span>in</span></span>
  switch</span> action </span>{</span></span>
  case</span> .onAppear</span>:</span></span>
    state.text</span> =</span> "Hello, user!"</span></span>
    return</span> .none</span></span>
</span>
  case</span> .task</span>:</span></span>
    return</span> .none</span></span>
</span>
  case</span> .buttonTapped</span>:</span></span>
    return</span> .</span>run</span> {</span> send </span>in</span></span>
      let</span> userInfoResult </span>=</span> await</span> clientDependency.</span>downloadUserInfo</span>()</span></span>
      await</span> send</span>(</span>.</span>internal</span>(</span>.</span>downloadResponse</span>(</span>userInfoResult</span>)))</span></span>
    }</span></span>
</span>
  case</span> .closeButtonTapped</span>:</span></span>
    return</span> .</span>send</span>(</span>.</span>delegate</span>(</span>.dismissFeature</span>))</span></span>
  }</span></span>
}</span></span></code></pre>
For the other actions you can create separate NestedAction</code> reducers to deal with them. The body of the reducer will look something like this. And using Xcode's folding ribbon it literally looks just like this:</p>
var</span> body:</span> some</span> ReducerOf</span><</span>Self</span>> {</span></span>
  NestedAction</span>(</span>\.view</span>) {</span> ...</span> }</span></span>
</span>
  NestedAction</span>(</span>\.internal</span>) {</span> ...</span> }</span></span>
</span>
  NestedAction</span>(</span>\.delegate</span>) {</span> ...</span> }</span></span>
</span>
  NestedAction</span>(</span>\.destination</span>) {</span> ...</span> }</span></span>
}</span></span></code></pre>
Using this we could potentially mutate state in any of these reducers, but we still might want to use ifLet</code> reducers or onChange</code> reducers to add onto these. Especially with the onChange</code> reducer, we don't know where a particular property might change, so which reducer do we add it to?</p>
Thankfully TCA provides us with CombineReducers</code> for free, which we can make use of here. So, adding an onChange</code> reducer to the above might look like this:</p>
var</span> body:</span> some</span> ReducerOf</span><</span>Self</span>> {</span></span>
  CombineReducers</span> {</span></span>
    NestedAction</span>(</span>\.view</span>) {</span> ...</span> }</span></span>
</span>
    NestedAction</span>(</span>\.internal</span>) {</span> ...</span> }</span></span>
</span>
    NestedAction</span>(</span>\.delegate</span>) {</span> ...</span> }</span></span>
</span>
    NestedAction</span>(</span>\.destination</span>) {</span> ...</span> }</span></span>
  }</span></span>
  .</span>onChange</span>(</span>of</span>:</span> \.text</span>) {</span> oldValue, newValue </span>in</span> ...</span> }</span></span>
  .</span>ifLet</span>(</span>...</span>) {</span> ...</span> }</span></span>
}</span></span></code></pre>
This makes sure that wherever state is changed it will be caught in the onChange</code> reducer. Similarly, it makes sure that the ifLet</code> reducer is run before any of ours so that we can't invalidate the state in a way that breaks the app.</p>
Reducers are really powerful in TCA, and by taking common problems and wrapping the logic into a new Reducer</code>, we can really improve the look of our code and make it much more pleasurable to work with and maintain.</p>
What new reducers have you created in your own TCA projects? I'd love to hear about them.</p>


Managing Analytics in a TCA app
2023-12-14T00:00:00+00:00
One of the core requirements of any enterprise app is analytics. It's essential if the company wants to know how their app is used, how they can improve it, and ultimately how they can maximise its profitability.</p>
Integrating analytics into an app can be fairly easy using one of the many services that provide a way to log analytics with nice dashboards. Adding events to button presses, download results, or screen views can be very easy to do, but it can also take over the app and become invasive.</p>
You can very quickly get into a state where the analytics in the app start to crowd the actual features of the app. Consistency doesn't exist as there are no real rules as to where the analytics should be done. And testing analytics becomes difficult when they are reported from button presses or scroll events in the view.</p>
With TCA we have a well defined place to put all the logic of our apps: in the Action</code> of the Reducer</code>s.</p>
Can we exploit this to make analytics just as well defined without also flooding the feature code?</p>
My initial thought for analytics with TCA was to create a dependency that we can use to push our analytics through. In the reducer it looked something like this:</p>
var</span> body: ReducerOf</span><</span>Self</span>> {</span></span>
  Reduce</span> {</span> state, action </span>in</span></span>
    switch</span> action </span>{</span></span>
    case</span> .buttonTapped</span>:</span></span>
      state.message</span> =</span> "Button tapped!"</span></span>
      return</span> .</span>merge</span>(</span></span>
        .</span>run</span> {</span> _</span> in</span></span>
          await</span> analyticsClient.</span>send</span>(</span>"ButtonTapped"</span>)</span></span>
        }</span>,</span></span>
        downloadEffect</span></span>
      )</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
This works, but it doesn't solve the problems. The feature code of the app quickly gets overrun with analytics. In the example above the buttonTapped</code> action is really there to start a downloadEffect</code>, but it has to be merged with the analytics, making it harder to see what the app is actually doing.</p>
It gets messy.</p>
By leveraging the composability of TCA reducers, and creating our own reducer, we can create a much more elegant way of sending analytics that is just as powerful, but confined to its own dedicated space away from the feature code.</p>
If you want to jump ahead and just get the code, I have created an SPM package that you can use: swift-composable-analytics</a>.</p>
The core idea of this method is to still use a dependency to send analytics through, but to create a way to access that dependency through a dedicated reducer that does nothing other than send analytics. It means that the analytics code still remains close to the feature code, but just far enough away to not flood the feature code.</p>
The end goal looks like this:</p>
var</span> body:</span> some</span> ReducerOf</span><</span>Self</span>> {</span></span>
  // 1.</span></span>
  AnalyticsReducer</span> {</span> state, action </span>in</span></span>
    // 2.</span></span>
    switch</span> action </span>{</span></span>
    case</span> .buttonTapped</span>:</span></span>
      // 3.</span></span>
      return</span> .</span>event</span>(</span>name</span>:</span> "ButtonTapped"</span>)</span></span>
    }</span></span>
  }</span></span>
</span>
  Reduce</span> {</span> state, action </span>in</span></span>
    switch</span> action </span>{</span></span>
    case</span> .buttonTapped</span>:</span></span>
      state.message</span> =</span> "Button tapped!"</span></span>
      // 4.</span></span>
      return</span> downloadEffect</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>

We have a new AnalyticsReducer</code> that gives us state and action just like any other reducer. But this time state is immutable. This means that our analytics code cannot affect the state of the app.</li>
We have access to all the actions defined in the reducer, so we can send analytics for any event that can happen in the app. Whether it is the user tapping a button, the results of a successful download, or an error received from a service we interact with.</li>
The AnalyticsReducer</code> function just returns AnalyticsData</code>, so it can't run any custom effects. It is completely isolated from the feature code.</li>
The feature code of the app is unaffected. We just treat the feature code as the standard feature code. In this case, the button just returns the downloadEffect</code> without needing to worry about analytics at all.</li>
</ol>
That's the plan, and all of this is done with a surprisingly small custom reducer:</p>
import</span> Foundation</span></span>
import</span> ComposableArchitecture</span></span>
</span>
public struct</span> AnalyticsReducer</span><</span>State</span>,</span> Action</span>>:</span> Reducer</span> {</span></span>
  @</span>usableFromInline</span></span>
  let</span> toAnalyticsData:</span> (</span>State, Action</span>)</span> -></span> AnalyticsData</span>?</span></span>
</span>
  @</span>usableFromInline</span></span>
  @</span>Dependency</span>(</span>\.analyticsClient</span>)</span> var</span> analyticsClient</span></span>
</span>
  @</span>inlinable</span></span>
  public init</span>(</span>_</span> toAnalyticsData</span>: </span>@</span>escaping</span> (</span>State, Action</span>)</span> -></span> AnalyticsData</span>?</span>) {</span></span>
    self.</span>init</span>(</span>toAnalyticsData</span>:</span> toAnalyticsData, </span>internal</span>: ())</span></span>
  }</span></span>
</span>
  @</span>usableFromInline</span></span>
  init</span>(</span>toAnalyticsData</span>: </span>@</span>escaping</span> (</span>State, Action</span>)</span> -></span> AnalyticsData</span>?</span>, </span>internal</span>: </span>Void</span>) {</span></span>
    self.toAnalyticsData</span> =</span> toAnalyticsData</span></span>
  }</span></span>
</span>
  @</span>inlinable</span></span>
  public func</span> reduce</span>(</span>into</span> state</span>: </span>inout</span> State, </span>action</span>: Action</span>)</span> -></span> Effect</span><</span>Action</span>> {</span></span>
    guard let</span> analyticsData </span>=</span> toAnalyticsData</span>(</span>state, action</span>)</span> else</span> {</span></span>
      return</span> .none</span></span>
    }</span></span>
</span>
    return</span> .</span>run</span> {</span> _</span> in</span></span>
      analyticsClient.</span>sendAnalytics</span>(</span>analyticsData</span>)</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
This AnalyticsReducer</code> requires a function from (state, action) -> AnalyticsData?</code>, and everything else is done for you. If you return nil</code> from the function then nothing happens. Only when you return the AnalyticsData</code> does this access the analyticsClient</code> and send the data to our analytics services.</p>
Now we just need to create an AnalyticsClient</code> to use to send events for us. By default in my package I have created a .consoleLogger</code> analytics client that logs events out to the console. It looks like this:</p>
extension</span> AnalyticsClient</span> {</span></span>
  public static var</span> consoleLogger: Self</span> =</span> .</span>init</span>(</span></span>
    sendAnalytics</span>: {</span> analytics </span>in</span></span>
      print</span>(</span>"[Analytics] ✅ </span>\(</span>analytics</span>)</span>"</span>)</span></span>
    }</span></span>
  )</span></span>
}</span></span></code></pre>
It has a single function, sendAnalytics</code>, that takes the data and logs it to the console.</p>
To create our own AnalyticsClient</code> that sends events to our own service we just need to implement this sendAnalytics</code> function. Here is an example of a client that is written to send analytics to Firebase and Crashlytics:</p>
import</span> Firebase</span></span>
import</span> FirebaseCrashlytics</span></span>
</span>
public extension</span> AnalyticsClient</span> {</span></span>
  static var</span> firebaseClient: Self</span> {</span></span>
    return</span> .</span>init</span>(</span></span>
      sendAnalytics</span>: {</span> analyticsData </span>in</span></span>
        switch</span> analyticsData </span>{</span></span>
        case let</span> .</span>event</span>(</span>name</span>:</span> name, </span>properties</span>:</span> properties</span>)</span>:</span></span>
          Firebase.Analytics.</span>logEvent</span>(</span>name, </span>parameters</span>:</span> properties</span>)</span></span>
</span>
        case</span> .</span>userId</span>(</span>let</span> id</span>)</span>:</span></span>
          Firebase.Analytics.</span>setUserID</span>(</span>id</span>)</span></span>
          Crashlytics.</span>crashlytics</span>()</span>.</span>setUserID</span>(</span>id</span>)</span></span>
</span>
        case let</span> .</span>userProperty</span>(</span>name</span>:</span> name, </span>value</span>:</span> value</span>)</span>:</span></span>
          Firebase.Analytics.</span>setUserProperty</span>(</span>value, </span>forName</span>:</span> name</span>)</span></span>
</span>
        case</span> .</span>screen</span>(</span>name</span>:</span> let</span> name</span>)</span>:</span></span>
          Firebase.Analytics.</span>logEvent</span>(</span>AnalyticsEventScreenView, </span>parameters</span>:</span> [</span></span>
            AnalyticsParameterScreenName</span>:</span> name</span></span>
          ]</span>)</span></span>
</span>
        case</span> .error</span>(</span>let</span> error</span>)</span>:</span></span>
          Crashlytics.</span>crashlytics</span>()</span>.</span>record</span>(</span>error</span>:</span> error</span>)</span></span>
        }</span></span>
      }</span></span>
    )</span></span>
  }</span></span>
}</span></span></code></pre>
We extend AnalyticsClient</code> to provide a .firebaseClient</code>, and in the sendAnalytics</code> function we just inspect the data that comes in and send it to the relevant Firebase or Crashlytics service.</p>
To start using this we just need to inject the dependency when we create the root Store</code> of the app:</p>
let</span> rootStore </span>=</span> Store</span>(</span>RootReducer.</span>State</span>()) {</span></span>
  RootReducer</span>()</span></span>
}</span> withDependencies</span>: {</span></span>
  $0.analyticsClient</span> =</span> .</span>merge</span>(</span>.consoleLogger, .firebaseClient</span>)</span></span>
}</span></span></code></pre>
This is all we need now to start sending analytics from anywhere in the app, and we can use merge</code> to add multiple analytics services to our app.</p>
Finally we come to testing. Because all of the analytics of our app are sent via actions in a reducer it means that our tests have access to all of them.</p>
And we can provide a function to expect analytics data that is really powerful for testing. In our test we can tell the TestStore</code> that we expect to receive certain analytics data, and if we don't receive that the test will fail.</p>
func</span> testButtonTapped</span>()</span> async throws</span> {</span></span>
  let</span> store </span>=</span> TestStore</span>(</span>RootReducer.</span>State</span>()) {</span></span>
    RootReducer</span>()</span></span>
  }</span> withDependencies</span>: {</span></span>
    $0.analyticsClient.</span>expect</span>(</span>.</span>event</span>(</span>"ButtonTapped"</span>))</span></span>
  }</span></span>
</span>
  store.</span>send</span>(</span>.buttonTapped</span>)</span></span>
}</span></span></code></pre>
This test is exhaustive too.</p>
If you don't expect an event and then an event is sent, it will fail. If you expect an event and it doesn't get sent, it will fail. If the expected event is different from the sent event, it will fail.</p>
So the test really does cover every eventuality.</p>
I have found this to be a really effective way to manage and send analytics throughout the apps I've worked on. Adding a new analytics service is just a case of creating a new client and injecting it at the root. All of the analytics throughout the app then start getting sent to the new service.</p>
I hope this has given you a brief insight into how to leverage reducers and actions. This is only one use case I have created, but there are a lot more ways of extending TCA to provide benefits like this.</p>
You can get my SPM package swift-composable-analytics</a> on GitHub.</p>


Shared data in a TCA app
2023-12-13T00:00:00+00:00
A question that I come across a lot from people using TCA to help structure their apps is:</p>

How do you manage shared data in a large TCA app?</p>
</blockquote>
The initial thought process for many, myself included, is to somehow store shared data in the state of the root reducer and synchronise changes up and down the stack when it changes. So that children can make changes and it's updated back to the root. And then the root propagates these changes to all the children.</p>
This very quickly becomes hugely complicated and there is a much more elegant way using dependencies.</p>
Instead of using the root reducer to store our shared data we will create a dependency to store it for us. This dependency will expose an AsyncStream</code> of the type that we want to store. For a very basic example let's create a shared number that all parts of our app can access and update.</p>
Let's create our dependency:</p>
@</span>DependencyClient</span></span>
struct</span> NumberStore</span> {</span></span>
  var</span> value:</span> @</span>Sendable</span> ()</span> async</span> -></span> AsyncStream</span><</span>Int</span>></span></span>
  var</span> updateValue:</span> @</span>Sendable</span> (</span>Int</span>)</span> async</span> -></span> Void</span></span>
}</span></span></code></pre>
This is the signature of our dependency. It provides a way to get a stream of values that we should be able to subscribe to, and a way for us to update the current value.</p>
With this we can begin to imagine what our reducer will look like. It will need:</p>

State to hold onto the number</li>
The NumberStore</code> dependency</li>
An action to subscribe to the dependency</li>
An action to update the state</li>
</ul>
@</span>Reducer</span></span>
struct</span> SomeFeature</span> {</span></span>
  struct</span> State</span> {</span></span>
    var</span> number:</span> Int</span> =</span> 0</span></span>
  }</span></span>
</span>
  enum</span> Action</span> {</span></span>
    case</span> task</span> // the convention is to use the task name to mirror the view task</span></span>
    case</span> newNumberReceived</span>(</span>Int</span>)</span></span>
  }</span></span>
</span>
  @</span>Dependency</span>(</span>\.numberStore</span>)</span> var</span> numberStore</span></span>
</span>
  var</span> body:</span> some</span> ReducerOf</span><</span>Self</span>> {</span></span>
    Reduce</span> {</span> state, action </span>in</span></span>
      switch</span> action </span>{</span></span>
      case</span> .task</span>:</span></span>
        return</span> .</span>run</span> {</span> send </span>in</span></span>
          for await</span> value </span>in await</span> numberStore.value</span>() {</span></span>
            await</span> send</span>(</span>.</span>newNumberReceived</span>(</span>value</span>))</span></span>
          }</span></span>
        }</span></span>
</span>
      case</span> .</span>newNumberReceived</span>(</span>let</span> value</span>)</span>:</span></span>
        state.number</span> =</span> value</span></span>
        return</span> .none</span></span>
      }</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
That's our basic reducer that subscribes to the updates. Now we need to implement the dependency.</p>
We'll first create a class to hold onto the value for us.</p>
class</span> NumberStorage</span> {</span></span>
  @</span>Published var</span> value:</span> Int</span> =</span> 0</span></span>
}</span></span></code></pre>
Then our dependency becomes very simple:</p>
extension</span> NumberStore</span> {</span></span>
  static var</span> liveValue: Self</span> {</span></span>
    let</span> storage </span>=</span> NumberStorage</span>()</span></span>
</span>
    return</span> .</span>init</span>(</span></span>
      value</span>: {</span></span>
        storage.$value</span></span>
          .streamValues</span></span>
      }</span>,</span></span>
      updateValue</span>: {</span></span>
        storage.value</span> =</span> $0</span></span>
      }</span></span>
    )</span></span>
  }</span></span>
}</span></span></code></pre>
Where we have defined streamValues</code> as an extension on Publisher</code>:</p>
public extension</span> Publisher</span> where</span> Self.Failure </span>==</span> Never</span> {</span></span>
  var</span> streamValues: AsyncStream</span><</span>Output</span>> {</span></span>
    AsyncStream</span>(</span>bufferingPolicy</span>:</span> .</span>bufferingNewest</span>(</span>5</span>)) {</span> continuation </span>in</span></span>
      let</span> cancellable </span>=</span> self.</span>sink</span> {</span> continuation.</span>yield</span>(</span>$0</span>) }</span></span>
      continuation.onTermination</span> =</span> {</span> _</span> in</span></span>
        cancellable.</span>cancel</span>()</span></span>
      }</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
With all this in place any reducer in the app can now subscribe to a stream of values held by the NumberStore</code> dependency.</p>
Now that we've done that we could also create an action to update the value:</p>
case</span> updateValueButtonTapped</span>(</span>Int</span>)</span></span></code></pre>
And then handle it in the reducer:</p>
case</span> .</span>updateValueButtonTapped</span>(</span>let</span> value</span>)</span>:</span></span>
  return</span> .</span>run</span> {</span> _</span> in</span></span>
    await</span> numberStore.</span>updateValue</span>(</span>value</span>)</span></span>
  }</span></span></code></pre>
That's it for updating the value. This will trigger the update in the dependency which will then push the new value out to any reducers that are listening out for it.</p>
Finally we need to write the view to display the count.</p>
struct</span> NumberView</span>:</span> View</span> {</span></span>
  let</span> store: StoreOf</span><</span>SomeFeature</span>></span></span>
</span>
  var</span> body:</span> some</span> View </span>{</span></span>
    WithViewStore</span>(</span>store, </span>observe</span>: {</span> $0</span> }) {</span> viewStore </span>in</span></span>
      Text</span>(</span>"</span>\(</span>viewStore.number</span>)</span>"</span>)</span></span>
        .</span>task</span> {</span> await</span> store.</span>send</span>(</span>.task</span>)</span>.</span>finish</span>() }</span></span>
</span>
      Button</span> {</span></span>
        store.</span>send</span>(</span>.</span>updateValueButtonTapped</span>(</span>viewStore.number</span> +</span> 1</span>))</span></span>
      }</span> label</span>: {</span></span>
        Text</span>(</span>"Add one"</span>)</span></span>
      }</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
The use of task</code> in the view will keep the subscription alive when the view is on screen and cancel it when the view disappears.</p>
So this is all that we need. This view will update the value displayed when any part of the app updates the value.</p>
Of course, this is only a very basic version and you may want to build in some security around race conditions, but this makes a lot of shared data very simple within a TCA app.</p>


SwiftUI: Formatting text, images, and links together
2023-08-03T00:00:00+00:00
Introduction#</span></a>
</h2>
I was given a task recently to create some text with links in it in our SwiftUI app. With one difference, the text had images in it and the images also took on the tint colour of the links. If you're looking for something similar you can find all the code at the bottom of this article.</p>
First attempt#</span></a>
</h2>
My first start was to just use the markdown formatting of SwiftUI...</p>
Text</span>(</span>"Accept **[Terms and Conditions](https://oliverfoggin.com)** and **[Privacy Policy](https://oliverfoggin.com)**"</span>)</span></span>
  .</span>tint</span>(</span>.green</span>)</span></span></code></pre>
</p>
A promising start. And then I added the images...</p>
Text</span>(</span>"Accept **[Terms and Conditions </span>\(</span>Image</span>(</span>systemName</span>:</span> "square.and.arrow.up"</span>))</span>](https://oliverfoggin.com)** and **[Privacy Policy </span>\(</span>Image</span>(</span>systemName</span>:</span> "square.and.arrow.up"</span>))</span>](https://oliverfoggin.com)**"</span>)</span></span>
  .</span>tint</span>(</span>.green</span>)</span></span></code></pre>
</p>
This is where it got tricky as the images were not picking up the tint colour. And adding the .foregroundColor</code> modifier to the Image</code> gave an error.</p>
The solution#</span></a>
</h2>
By wrapping the Image</code> in Text</code> we can finally append the color to make it look right...</p>
Text</span>(</span>"Accept **[Terms and Conditions </span>\(</span>Text</span>(</span>Image</span>(</span>systemName</span>:</span> "square.and.arrow.up"</span>))</span>.</span>foregroundColor</span>(</span>.green</span>))</span>](https://oliverfoggin.com)** and **[Privacy Policy </span>\(</span>Text</span>(</span>Image</span>(</span>systemName</span>:</span> "square.and.arrow.up"</span>))</span>.</span>foregroundColor</span>(</span>.green</span>))</span>](https://oliverfoggin.com)**"</span>)</span></span>
  .</span>tint</span>(</span>.green</span>)</span></span></code></pre>
</p>
Except now the line of text is getting a bit out of hand. So extracting a couple of helpers made it much nicer to read.</p>
Text</span>(</span>"Accept </span>\(</span>terms</span>)</span> and </span>\(</span>privacy</span>)</span>"</span>)</span></span>
  .</span>tint</span>(</span>.green</span>)</span></span>
</span>
@</span>ViewBuilder</span></span>
private var</span> linkIcon: Text </span>{</span></span>
  Text</span>(</span>Image</span>(</span>systemName</span>:</span> "square.and.arrow.up"</span>))</span></span>
    .</span>foregroundColor</span>(</span>.green</span>)</span></span>
}</span></span>
</span>
@</span>ViewBuilder</span></span>
private var</span> privacy: Text </span>{</span></span>
  Text</span>(</span>"**[Privacy Policy </span>\(</span>linkIcon</span>)</span>](https://oliverfoggin.com)**"</span>)</span></span>
}</span></span>
</span>
@</span>ViewBuilder</span></span>
private var</span> terms: Text </span>{</span></span>
  Text</span>(</span>"**[Terms and Conditions </span>\(</span>linkIcon</span>)</span>](https://oliverfoggin.com)**"</span>)</span></span>
}</span></span></code></pre>
I was surprised at how straight forward it was to get this working as there seemed to be a million different ways recommended online.</p>


We need to talk about The Coordinator Pattern
2023-08-03T00:00:00+00:00
What is The Coordinator Pattern?#</span></a>
</h2>
The Coordinator Pattern is a design pattern used in software engineering and has been around a long time and was made popular by a blog post by Soroush Khanlou back in 2015</a>. Right about the time when the MVC pattern became a meme in itself and was given the name "Massive View Controller".</p>
It is a design pattern used to decouple UIViewControllers from the navigation flows that they are a part of. And, at first glance, I can see how this might be useful.</p>
Why is it used?#</span></a>
</h2>
The reasons for using this pattern that I have heard many times is that it means we no longer have to test navigation flow as part of the UIViewController. Which is true. Or that view controllers can be reused as part of different flows within an app. Which is also true. But with many of these I'm not sure that The Coordinator Pattern is any better a solution than the numerous other ways that these can be achieved.</p>
Along with these reasons are the projects themselves that use the coordinator pattern. And in almost all of the cases where The Coordinator Pattern is used the flows within the app are fairly static. There are not many reused view controllers. The flows of the app are known at the time of development. And, when there is testing, the navigation flow is still tested statically. Only it is tested through the coordinators rather than through the view controllers.</p>
Even worse, I often see The Coordinator Pattern being used where the view controllers are telling the coordinators specifically which view controllers to push onto the navigation stack. Which negates the point of using the pattern in the first place.</p>
This leads me to ask the question, why is The Coordinator Pattern being used here? It seems like a lot of the benefits that are being described are not actually being put into use here. Or, if they are, the complexity that has come with adding coordinators has not removed complexity from elsewhere but only shifted that complexity to somewhere else. It seems to be used in a lot of places without really asking why it is used or what it's true benefit is.</p>
Where is it that The Coordinator Pattern really shines?</p>
What is The Coordinator Pattern really good for?#</span></a>
</h2>
Back in 2012, reasonably early in my career, before I really appreciated design patterns and really, before I was involved much in the iOS community, I was working on an app in an agency. This app was intended for people to go out into the field and use it as a sort of clipboard.</p>
They would be able to search for existing clients, add new clients, enter their address, email, telephone number, search for products they were interested in, etc, etc... This seems like a fairly simple app to put together on the surface. I had a view controller for entering a phone number, one for searching for a postcode, one for searching for products, etc...</p>
The problem I had with this app is that I did not know which flow the user would be starting and also the various flows that the user could pick from were all maintained online on a central server and so could change at any time. So, I had been backed into a corner where, not only could the view controllers not know what came before them or what came next but I, as the developer, also did not know what came before or after each view controller.</p>
And so there was no where in the app that I could move this complexity to. The answer I came up with was to use a "Flow Controller" as I called it at the time.</a> It wasn't perfect and, as with every project I have worked on, there are things I would do differently looking back at it. But, I would argue that this is the one use case that The Coordinator Pattern is good for.</p>
In this particular case I did not arbitrarily choose to decouple the navigation flow from the view controllers. I did not arbitrarily decide that I wanted to be able to reuse my view controllers. The problem space I was given had forced me into a position where that was my only choice. I could not have baked the navigation flow into the view controllers even if I had wanted to.</p>
The architecture I used was not chosen out of a list of different architectural patterns, it was discovered by exploring the problem space and finding the best way of solving the problem that existed within the app I was writing.</p>
Why design patterns exist?#</span></a>
</h2>
Design patterns are not prescribed ways of writing software, nor are they tools that can be used, they exist purely to describe commonly repeated solutions to various different problems. We don't use design patterns, we discover them through investigating the problem space that we are working in. And of course, those problem spaces are somewhat constrained by the platform we are working with too. Which is why MVC was the pattern of choice for many iOS apps in the early days.</p>
Design patterns are also not a guarantee that your project will be good or well written. It is vital to constantly ask "Why?". Why are we writing the code this way? Is there a better way to write it? I see a lot of projects where it has been started out by stating "We are going to write this project using ." Almost like that means that all the problems have been solved and then very little thought is put into that architectural discussion after that.</p>
An analogy I keep coming back to would be like a builder saying, "I'm going to build a new house and the tool I am going to use is a hammer." And then when they start having to cut down some trees for timber they take the hammer and start smashing through the tree with all their might because they said they were going to use a hammer and that's what they're going to use.</p>
Conclusion#</span></a>
</h2>
So, I guess, this isn't really about just The Coordinator Pattern. As a pattern it has it's uses and in those cases (of which I argue there are very few) it really does work well. This post is more about why we have design patterns and what they mean to us as developers.</p>
Don't start your next project with a view to using a certain architecture. Just, start the project and write your app, only by doing that will you start to discover sections of the app where repeated patterns exist that could possibly be extracted. You may even extract those patterns into something that looks a bit like a design pattern. That pattern might be The Coordinator Pattern, or it might be MVVM, or MVC, or MVP, or TEA, or POP, or any of a host of other ensign patterns that exist.</p>
But don't stop there as you might find that the pattern you stumbled across is only suited for a particular part of your app. And that's fine too. There's no rule that states you must decide on a single pattern for your entire app. In my example there were other parts of the app that were well defined at the time of writing the app. The login screen for instance was well defined and didn't need to change and so I used plain old MVC for that part of the app.</p>
Design Patterns are nice to read about and understand but don't let them be an alternative to thinking about how and why you are writing what you are writing. Only you know the problem space of the project that you're working in. And only you can understand whether a particular solution (or number of solutions) is right for it. Don't get stuck by thinking you have to stick with what has gone before just because it is written down in a blog or a book.</p>
Anyway... have fun in writing your project. If you go wrong, learn from it. All that matters is that you keep thinking and keep having fun while doing it.</p>