Test Swift Collection Chunking on a Cloud Mac

Swift projects often need a helper that takes a few elements at a time, whether to upload records in batches, split database query criteria, or refresh a list incrementally. A function that works on a full array may go out of bounds or drop the final elements when given a slice returned by dropFirst. Running these pure-logic checks on a cloud Mac before the build catches batch-processing regressions without launching a simulator.

Define the chunking contract first

These checks cover contiguous chunks only: each chunk contains at most the requested number of elements, input order is preserved, and the final chunk may be smaller. Nothing is padded or discarded. An empty collection returns an empty result, and a chunk size of zero or less throws an error.

For example, five elements split into groups of two should produce three chunks with lengths of two, two, and one—not just two full chunks. When the chunk size exceeds the input length, the entire nonempty input forms a single chunk.

The chunking function determines element boundaries. It does not limit upload concurrency or confirm that a remote API has received the data successfully. The calling code must track batch completion separately.

Tests should verify that flattening the result reproduces the input exactly. Checking only the chunk count cannot detect an element duplicated in the middle while another is omitted.

Advance boundaries using collection indices

ArraySlice retains the original array’s indices. Calling dropFirst(5) on ten elements produces a slice whose starting index is not zero. A generic Collection may not even use integer indices, so you cannot access its elements directly using 0..<count.

The following implementation advances indices one at a time. It neither calculates “start plus chunk size” nor depends on random access. Save it as ChunkChecks.swift:

enum ChunkError: Error {
    case invalidSize
}

func chunks<C: Collection>(
    _ input: C,
    size: Int
) throws -> [C.SubSequence] {
    guard size > 0 else {
        throw ChunkError.invalidSize
    }

    var result: [C.SubSequence] = []
    var start = input.startIndex

    while start != input.endIndex {
        var end = start
        var taken = 0

        while end != input.endIndex && taken < size {
            input.formIndex(after: &end)
            taken += 1
        }

        result.append(input[start..<end])
        start = end
    }

    return result
}

Before each index advance, the code checks that it has not reached endIndex, then uses a half-open range to extract the chunk. Even when the chunk size is Int.max, it walks only the elements that actually exist, without trying to generate an integer index beyond the collection’s bounds.

This implementation also avoids repeatedly calling distance on the remaining collection. For collections without random access, measuring the remaining length over and over can cause unnecessary repeated traversal. Here, the number of index advances equals the number of input elements.

Cover slices and partial final chunks

Append the tests to the same file. Start with an example that is easy to check by hand, then iterate over a range of input lengths and chunk sizes so the tests establish more than one special case.

let base = Array(0..<23)
let slice = base.dropFirst(5).prefix(5)

precondition(slice.startIndex == 5)
let example = try chunks(slice, size: 2)
precondition(example.map { Array($0) } == [
    [5, 6], [7, 8], [9]
])

for length in 0...17 {
    let input = base.dropFirst(5).prefix(length)

    for size in 1...8 {
        let output = try chunks(input, size: size)
        let expectedCount =
            length / size + (length % size == 0 ? 0 : 1)

        precondition(output.count == expectedCount)
        precondition(output.flatMap { Array($0) } == Array(input))

        for (position, block) in output.enumerated() {
            precondition(!block.isEmpty)
            precondition(block.count <= size)

            if position < output.count - 1 {
                precondition(block.count == size)
            }
        }
    }
}

let huge = try chunks(slice, size: Int.max)
precondition(huge.map { Array($0) } == [Array(slice)])

for size in [0, -1, Int.min] {
    do {
        _ = try chunks(slice, size: size)
        preconditionFailure("Expected invalidSize")
    } catch ChunkError.invalidSize {
    }
}

The expected chunk count uses the quotient and remainder rather than the common formula “length plus chunk size minus one, divided by chunk size.” With very large parameters, that formula can overflow during the addition before the division takes place.

The tests also require every nonfinal chunk to be full, the final chunk to be nonempty, and the flattened result to remain unchanged. Invalid parameters must produce the specified error. Any other unexpected error fails the script directly; a broad catch must not swallow the failure.

Add the check before builds on a cloud Mac

On a cloud Mac with the Swift toolchain configured, run the following from the repository root:

set -eu
xcrun swift --version
xcrun swift Scripts/ChunkChecks.swift

Place the file in the repository’s Scripts directory and run this step before the time-consuming application build. In the default execution mode, any failed precondition produces a nonzero exit status. No script output does not mean the script did not run; use the task status and exit code to determine success.

Do not run these assertions with -Ounchecked, which removes safety checks. If the team moves the logic into a test target, replace the preconditions with test assertions so failure messages can identify the specific input length, chunk size, and batch position.

A standalone script is useful for establishing a minimal reproduction. Once integrated into the project, the checks should call the implementation the project actually uses. Otherwise, the test file may contain a correct copy while the application code still uses the old algorithm.

Separate storage concerns from business logic

Returning slices can reduce immediate copying, but it does not necessarily release the original input. Even if only a small final chunk remains, its slice may retain the entire array’s underlying storage. When keeping a few batches for the long term, use blocks.map { Array($0) } to create independent arrays. If all batches are retained, however, this does not reduce the total number of elements.

Extremely large inputs are also a poor fit for collecting every slice at once. The same boundary-advancement logic can be adapted to a per-batch callback or lazy iteration, allowing the caller to finish processing one chunk before requesting the next. Backpressure and retry behavior must be defined explicitly.

Keep three final checks: input with a nonzero starting index passes, the final chunk is not omitted, and flattening the batches preserves the original order. First verify which elements belong to which batch, then test network retries and concurrency scheduling separately. This makes it possible to isolate failures to a specific layer.

Frequently asked questions