I used to judge Swift collection code by line count. If a chain of map, filter, and reduce replaced a loop, I assumed the result was automatically better. A reporting feature changed that habit. The first functional version was short, but it performed unnecessary work and hid an important rule about refunded orders.
The useful lesson was not that higher-order functions beat for loops. It was that each function describes one specific data transformation. When those transformations match the business steps, the code becomes easier to verify. When they do not, a short chain can be harder to understand than a plain loop.
The Order Report I Needed to Trust
The feature started with a JSON export from a small shop. Each order had a status, an optional customer email, and a nested array of line items. The report needed to ignore refunded orders, show one summary row per paid order, calculate gross revenue, count purchased quantities by category, and collect available email domains.
Those requirements sound simple, but they operate at different shapes. Filtering keeps some orders. Mapping turns orders into rows. Flattening turns nested item arrays into one sequence. Compact mapping handles missing emails. Reducing combines many values into totals. Writing the shapes down first kept me from forcing every task into the same tool.
filter Expresses the Business Boundary
The first rule is that only paid orders belong in the report. I apply it once near the beginning:
let paidOrders = orders.filter { $0.status == "paid" }filter returns a new collection containing elements that satisfy the predicate. It does not change the original array. More importantly for this project, the name paidOrders creates a boundary: every later revenue calculation uses the already-validated set. That avoids repeating the status check in several places and accidentally forgetting it in one calculation.
I do not split a simple condition into several filters just to create more steps. A single predicate such as isPaid && !isTestOrder is often clearer and avoids producing an unnecessary intermediate array. If the conditions represent separate business concepts that deserve names, separate variables can still be worthwhile.
map Builds One Report Row per Order
The report screen does not need the complete decoded order. It needs an order ID, an item count, and a total. map fits because every paid order produces exactly one row:
let rows = paidOrders.map { order in
OrderRow(
id: order.id,
itemCount: order.items.reduce(0) { $0 + $1.quantity },
totalCents: order.items.reduce(0) {
$0 + ($1.unitPriceCents * $1.quantity)
}
)
}The output count is the same as the input count. That one-to-one relationship is a useful review signal. If the transformation can fail or intentionally omit elements, regular map is probably not the complete operation.
The demo stores money as integer cents. That is a deliberate project decision, not a higher-order-function trick. It keeps this example deterministic and avoids introducing binary floating-point rounding into the revenue checks.
flatMap Removes One Level of Nesting
Each order contains an array of items, so mapping the orders to their items would produce [[LineItem]]. The category and revenue calculations are easier with one item sequence. flatMap performs the transformation and removes that one collection level:
let paidItems = paidOrders.flatMap(\.items)The result contains four line-item records in the sample data. Quantities are still properties of those records, so flattening does not duplicate an item with quantity two. That distinction matters when counting products later.
I use flatMap when the closure produces a sequence for every element and the next stage needs one combined sequence. I do not use it as a vague nil-removal operation. Swift has a more precise function for that job.
compactMap Makes Missing Values Explicit
Customer email is optional. Even when an email exists, the code still checks for an @ before extracting the domain. The transformation therefore returns String?:
let emailDomains = paidOrders.compactMap { order -> String? in
guard let email = order.customerEmail,
let atIndex = email.lastIndex(of: "@") else { return nil }
return String(email[email.index(after: atIndex)...])
}compactMap unwraps the successful results and removes the nil results. In this report, missing or malformed emails are allowed to disappear from the domain list. If a missing email were a validation error that needed to be displayed, silently dropping it would be wrong. The function is only appropriate because omission matches the requirement.
reduce Calculates One Result
After flattening the paid items, gross revenue is a single integer:
let grossCents = paidItems.reduce(0) {
$0 + ($1.unitPriceCents * $1.quantity)
}The initial value is zero. For each item, the closure adds unit price multiplied by quantity. The sample’s expected result is 9,195 cents. Because the test checks that exact value, an accidental inclusion of the refunded order is immediately visible.
I reserve reduce for transformations whose destination is genuinely one accumulated value. If a reduce closure starts building several unrelated arrays, flags, and counters, it often becomes harder to follow than named variables in a loop.
reduce(into:) Is Better for a Mutable Accumulator
The category report needs a dictionary. With reduce(into:), the accumulator is mutated in place inside the closure:
let quantityByCategory = paidItems.reduce(into: [String: Int]()) {
totals, item in
totals[item.category, default: 0] += item.quantity
}This form clearly communicates that the dictionary is the result being assembled. It also avoids repeatedly returning a newly copied accumulator value. In the fixture, coffee has quantity two, accessories has quantity two, and equipment has quantity one.
When I Keep the for Loop
Higher-order functions work well here because the report is a sequence of recognizable transformations. I still choose a loop when processing needs an early break, several dependent pieces of state, detailed per-item error recovery, or step-by-step logging. A loop can also avoid multiple intermediate arrays in a hot path without making the intent mysterious.
Lazy sequences can postpone transformations and sometimes avoid work, but I add lazy only after measuring or when early consumption clearly benefits from it. It changes when work happens, which can make debugging less obvious. Calling a chain “one pass” without checking its types and consumption is not a performance argument.
My current rule is simple: choose the version whose business steps are easiest to name and test. Line count is not the score. A six-line expression with several hidden assumptions is not automatically safer than a twelve-line loop.
How the Runnable Project Checks the Pipeline
The project decodes three orders from a local JSON fixture, so it does not need network access or API keys. One order is refunded and two are paid. The executable verifies the decoded count, filtered IDs, row count, first row totals, flattened item count, cleaned email domains, gross revenue, and category quantities.
Eight checks print PASS. Any mismatch prints a failure message and exits with a nonzero status. This turns the article’s claims into behavior that can be reproduced instead of asking the reader to trust sample output.
Download and Run the Example
The example is a Swift Package for macOS and requires Swift 5.9 or later:
git clone https://github.com/2252408699/swift-order-report-pipeline.git
cd swift-order-report-pipeline
swift runA successful run prints eight PASS lines, the two paid-order rows, a gross revenue value of $91.95, and All order report checks passed.
Complete source code: swift-order-report-pipeline on GitHub
