Daniel Inoa

SwiftUI Stacks Insist Upon Themselves

Tue, 14 Apr 2026 00:00:00 GMT

import InlineQuiz from '../../components/InlineQuiz.astro';

As a UIKit-first iOS developer, I've been gradually adopting SwiftUI. Some friction is expected when moving from an imperative framework to a declarative one, and not every surprise is evidence of bad design. But "the SwiftUI way" is sometimes just a polite way of saying "the framework made a design choice for you." HStack and VStack are a good example.

A Stack Should Stack

Consider this code:

HStack {    Text("Hello")    Text("World")}

The obvious reading is simple: place these views next to each other horizontally. However, that is not quite what happens. SwiftUI slips a gap in there even though the call site never asked for one.

That gap often looks like 8 points, but the number is not really the issue. The issue is that the stack chooses one at all. Apple's own initializer makes the delegation explicit: spacing is optional, so leaving it out hands the distance back to SwiftUI. The code stops fully describing the layout and starts handing part of it back to the framework.

Too Helpful Is Still Wrong

A primitive should not smuggle presentation choices into an API that looks neutral at the call site.

For a layout primitive, the neutral default should be 0. A view without padding has no padding. A view without offset stays where it is. Those defaults make sense because they do not invent presentation. Stack spacing should work the same way. Any nonzero spacing is a design choice, and design choices should be explicit.

The obvious defense is that SwiftUI is trying to encode platform conventions. That is understandable. Apple wants common interfaces to breathe a little by default, and higher-level components can reasonably reflect those conventions. But HStack and VStack are not high-level components. They are primitives. A stack should stack, not quietly pick a visual rhythm for you.

That is why this matters beyond one initializer. SwiftUI often looks concise because behavior has been moved out of the call site and into framework interpretation. That can feel elegant, but it is often less honest. The code looks more concise while saying less.

The Practical Rule

My practical rule is simple: always set spacing, especially when you intend for it to be 0. Use a linter if you have to. If the framework wants breathing room, your code should say so.

HStack(spacing: .zero) {    Text("Hello")    Text("World")}

Ternary Unwrapping in Swift

Mon, 20 Nov 2017 00:00:00 GMT

The Issue

Often enough I find myself writing something like this:

let foo: Fooif let unwrappedDependency = optionalDependency {    foo = Foo(unwrappedDependency)} else {    foo = Foo(fallback)}

Here I have a foo that needs to be instantiated but its dependency is an optional that has to be dealt with first. This is easily solved by unwrapping said optional through an if-let or guard-let statement. Simple, but it takes just too many lines (depending how you count) to express such a simple flow of statements, which could potentially be repeated many times throughout a codebase. This calls for a more elegant solution.

Swift already comes with some great constructs like the ternary and nil-coalescing operators that help in writing more expressive code and reducing verbosity for code as the one described above.

// Nil Coalescing Operatorlet optionalNumber: Int? = ...let number: Int = optionalNumber ?? nonOptionalfallback

// Ternary Conditional Operatorlet condition: Bool = ...let number: Int = condition ? 1 : 0

However, neither of these operators would be helpful in satisfying the requirements for an inline statement that:

evaluates an optional
provides a path for a successful unwrapping
provides a path if the unwrapping fails

The Solution

Since there's no operator that meets those requirements, we can then leverage Swift's ability to define and implement a new operator that would allow us to do just that by combining the ternary conditional and nil-coalescing operators. I'm going to call it ternary unwrapping operator, and it looks like this:

let _ = optional ?? { unwrapped in ... } | ...

and it allows us to simplify the aforementioned flow like this:

let foo: Foo = optionalDependency ?? { Foo($0) } | Foo(fallback)

Let's dissect this:

Between = and ?? we have an optional that's to be evaluated.
If said optional can be safely unwrapped then the statement between ?? and | is executed. Here we have a closure that forwards the unwrapped optional and is used to create an instance of the expected return type (in this case Foo).
The statement after | serves as a fallback and must also resolve to an instance of the expected return type.

Use Case

Out of all the many scenarios where this operator could be useful, I've found that it is especially useful when doing string interpolation with an optional.

Instead of doing this:

// This approach is overwrought.let optionalNumber: Int? = 1let sentence: String?if let number = optionalNumber {    sentence = "My favorite number is \(number)"} else {    sentence = nil}

or this:

// This approach force unwraps which isn't ideal.let optionalNumber: Int? = 1let sentence: String? = optionalNumber != nil ? "My favorite number is \(optionalNumber!)" : nil

We could do this instead:

// This approach is concise and leverages the ternary unwrapping operator.let optionalNumber: Int? = 1let sentence = optionalNumber ?? { "My favorite number is \($0)" } | nil

Under The Hood

This ternary unwrapping operator is in fact 2 infix operators used in conjunction.

precedencegroup Group { associativity: right } infix operator ??: Groupfunc ?? <I, O>(_ input: I?,               _ handler: (lhs: (I) -> O, rhs: () -> O)) -> O {    guard let input = input else {        return handler.rhs()    }    return handler.lhs(input)} infix operator |: Groupfunc | <I, O>(_ lhs: @escaping (I) -> O,              _ rhs: @autoclosure @escaping () -> O) -> ((I) -> O, () -> O) {    return (lhs, rhs)}

This first operator, func ??, takes 2 parameters: an optional and a tuple. This function ?? by itself is in fact sufficient as an operator. However, func | is needed to improve the style that match that of a ternary operator.
The second operator, func |, acts as a façade by taking 2 closures and returning them in a tuple; later used by ??.

I (input) and O (output) describe the type of the optional argument and that of the returning value (used in the assignment), respectively.

Closing Thoughts

One of my main priorities as a developer is to improve the readability of the code I write, especially if it is to be reviewed by my peers. I'd like to believe that what the ternary conditional operator has done for if-else statement, this new operator could for the if-let-else unwrapping statement; helping developers write code that will be easy for others to understand.

This ternary unwrapping operator, however, is best suited for cases such as when the instantiation or assignment of an object/value depends on 1 optional dependency needing to be unwrapped. For more complex cases it might be wiser to stick with if-let and guard-let. As always, all the operators described here are best used sparingly when readability of code can truly be improved, and not just to write fancy or unreasonably terse code.

Did you find this interesting and would you like to experiment with it? Check out the sample playground.

Thanks for reading!

Function Composition in Swift

Tue, 31 Oct 2017 00:00:00 GMT

It's common to perform an operation on a value and use the resulting value of that operation as the argument for a subsequent operation, and so on.

// Definitions func square(_ x: Int) -> Int {    return x * x} func increment(_ x: Int) -> Int {    return x + 1} func half(_ x: Int) -> Int {    return x / 2} func describe(_ val: CustomStringConvertible) -> String {    return "The resulting value is: \(val)"} // Usage describe(increment(square(half(6)))) // "The resulting value is: 10"

This works fine but the code quickly starts looking like Racket, and becomes hard to unpack. Another way to do this same thing is by leveraging function composition, which entails chaining many functions together into one. This idea of concatenating functions can be accomplished in Swift by taking advantage of generics and the infix operator.

// Custom Operator Definition precedencegroup Group { associativity: left }infix operator >>>: Groupfunc >>> <A, B, C>(_ lhs: @escaping (A) -> B,                   _ rhs: @escaping (B) -> C) -> (A) -> C {    return { rhs(lhs($0)) }}

Here we have a function that takes 2 parameters and returns a closure.

The first parameter in >>> is a function that takes 1 parameter of type A and returns an instance of type B.
The second parameter in >>> is a function that takes 1 parameter of type B (this is where the concatenation occurs) and returns an instance of type C.
Lastly, >>> returns yet another function which takes 1 parameter of type A and returns an instance of type C. Type B, being both the output for the 1st parameter and input for the 2nd one, serves as the knot between A and C.
The body of the function runs the result of lhs on rhs and returns. These functions are nested internally so that the function parameters, lhs and rhs, can be described as a sequence externally.

We could then do the following:

// Usage With Custom Operator (half >>> square >>> increment >>> describe)(6) // "The resulting value is: 10"

This then becomes a better and more legible approach of describing a sequence of operations, where functions are chained instead of being nested.

Shout-out to Brandon Williams for showing me this stuff at Swift Summit 2017.
If you find this interesting, check out this Wikipedia article on Function Composition.

Rendering Markdown in Xcode 9

Tue, 19 Sep 2017 00:00:00 GMT

Recently while exploring Apple's new sample projects for iOS 11, I stumbled upon this sample ARKit project. Aside from the cool ARKit stuff going on, I saw how the README.md would actually get rendered.

This has been possible in Playgrounds for a while but never in an actual Xcode project, until now. This markdown rendition is different from the one advertised, where the Markdown is partially rendered and the syntax is included (see image below).

After some "extensive" research and excavation I found that .xcodesamplecode.plist is what triggers Xcode to render the Markdown as seen in their sample. This file can be found under the .xcodeproj (within Package Contents).

It seems Apple intended for Markdown files to be rendered only if they are under a sample project. Ideally there would be a way to toggle when it renders, similar to Playgrounds, but for now the simplest way is to drop the .xcodesamplecode.plist file under your .xcodeproj project.

After dropping .xcodesamplecode.plist under the TestProject.xcodeproject I created it now renders the Markdown as expected. Download .xcodesamplecode.plist here.

TADA!!! 🎉

I think having renderable README.md files within Xcode could go a long way in helping make large projects easier to document and unpack, without the need to have external Markdown renderers. In addition to code comments this could greatly improve discoverability for new people coming into your project, as long as your project is well structured.