Eman Harout | Programming Blog

Swift Property Wrappers Gist

Eman Harout — Tue, 01 Apr 2025 00:00:00 GMT

Swift property wrappers provide a way to encapsulate logic for getting an setting properties. Here’s a quick tour of their utility.

Creating a Property Wrapper

Here is an example of how to create and use a property wrapper:

// Create
@propertyWrapper
struct UpperCase {
    private var storedValue: String
    var wrappedValue: String {
        set { storedValue = newValue }
        get { storedValue.uppercased() }
    }
    init(wrappedValue: String) {
        self.wrappedValue = wrappedValue
    }
}

// Use
struct Address {
    @UpperCase public var state: String
}

let address = Address(state: "California")
address.state // CALIFORNIA

Annotate the struct with @propertyWrapper
Define a wrappedValue variable that applies formatting and/or logic.
Add an initializer
Annotate the property with @UpperCase to apply the property wrapper.

Optional: can also use didSet instead of get and set, but this requires repeating formatting/logic in the initializer, since didSet does not execute on the initial assignment.

Initializers and Default Values

There are a few ways to initialize types using property wrappers. For demonstration purposes, I have adjusted the property wrapper like so:

Added a new prefix property to limit the number of characters to uppercase
Declare three initializers

@propertyWrapper
struct UpperCase {
    private var storedValue: String
    private var prefixNumber: Int

    var wrappedValue: String {
        set { storedValue = newValue }
        get {
            let caps = storedValue.uppercased()
            let prefixed = caps.prefix(prefixNumber)
            return String(prefixed)
        }
    }

    // MARK: - Initializers
    init() {
        self.prefixNumber = 3
        self.wrappedValue = ""
    }

    init(wrappedValue: String) {
        self.prefixNumber = 3
        self.wrappedValue = wrappedValue
    }

    init(wrappedValue: String, prefix: Int) {
        self.prefixNumber = prefix
        self.wrappedValue = wrappedValue
    }
}

Using init()

struct Address {
    @UpperCase public var state: String
}
let address = Address() // Calls init()
address.state // ""

Using init(wrappedValue:)

let addressTwo = Address(state: UpperCase(wrappedValue: "Cali")) // Calls init(wrappedValue:)
addressTwo.state // CAL

Note we must pass in UpperCase instance to set state’s value.

Alternatively, we can directly inject a string by modifying Address:

struct AddressV2 {
    @UpperCase public var state: String = "New York" // Calls init(wrappedValue:)
}

let addressV2_default = AddressV2() // Calls init(wrappedValue:)
addressV2_default.state // NEW
let addressV2_california = AddressV2(state: "California") // Calls init(wrappedValue:)
addressV2_california.state // CAL

These examples use init(wrappedValue:).

Using init(wrappedValue: prefix:)

struct AddressV3 {
    @UpperCase(wrappedValue: "CityDefault", prefix: 5)
    public var city: String // Calls init(wrappedValue: prefix:)

    @UpperCase(prefix: 5)
    public var state: String = "StateDefault" // Calls init(wrappedValue: prefix:)
}
let cityStateAddress = AddressV3() // Calls init(wrappedValue: prefix:)
cityStateAddress.city // CITYD
cityStateAddress.state // STATE

Both properties use init(wrappedValue: prefix:) to initialize the property wrapper.

ProjectedValue

A projected value provides added utility to property wrappers.

In this example, we create a projectedValue that returns true if the original string exceeds the defined prefix length:

@propertyWrapper
struct UpperCase {
    private var storedValue: String
    private var prefixNumber: Int
    var projectedValue: Bool { storedValue.count > prefixNumber } 

    var wrappedValue: String {
        set { storedValue = newValue }
        get {
            let caps = storedValue.uppercased()
            let prefixed = caps.prefix(prefixNumber)
            return String(prefixed)
        }
    }

    init(wrappedValue: String, prefix: Int) {
        self.prefixNumber = prefix
        self.wrappedValue = wrappedValue
    }
}

To reference projectedValue, we use the $ symbol before the property name:

struct Address {
    @UpperCase public var state: String
}

var address = Address(state: UpperCase(wrappedValue: "Cali", prefix: 2))
address.$state // true
address.state = "C"
address.$state // false

Accessing the Property Wrapper

To access the backing storage/property wrapper itself, use underscore:

print(state) // prints the string
print(_state) // prints the property value

Function Parameters

Swift allows for the use of property wrappers in function parameters.

func toUpperCase(@UpperCase message: String) {
    print(message)
}

toUpperCase(message: "new york")
// prints "NEW"

You can configure the property wrapper with default arguments too:

func toUpperCase(@UpperCase(prefix: 9) message: String) {
    print(message)
}

toUpperCase(message: "california")
// prints "CALIFORNI"

Introduction to Swift Metatypes

Eman Harout — Wed, 14 Apr 2021 00:00:00 GMT

Metatypes can be difficult to grasp, both in concept and application. My hope is that after reading this, you’ll have mastered the basics of metatypes!

Instances & Types

To understand metatypes, it helps to start with the familiar. For example, just as String is the type of "Hello World", String.Type is the type of String.self. While String is the type of an instance, String.Type is the type of a type—hence the name “metatype”.

Here is an illustration in code:

let myString: String = "Hello World!"
let myStringType: String.Type = String.self

And since a metatype is a type, we can specify it as such in function signatures:

func doSomething(with type: String.T
ype) { ... } // Specify a metatype parameter

doSomething(with: String.self) // Pass in a metatype instance

This works if you know what metatype instance you want to pass in at compile time. But what if you have an object and need to get its metatype at runtime? Never fear! Simply use the type(of:) method, like so:

let myString = "Hello, world!"
let myStringType = type(of: myString) // converts an instance to its metatype value.
doSomething(with: myStringType)

This seems pointless with String, but if you have a class with many subclasses, you wouldn’t know which subclass-type you’re dealing with. Passing the object to type(of:) allows you to get the metatype instance.

Now that we know how to create instances of a metatype, let’s briefly discuss what we’re able to do with them.

Application

Metatypes are used to access properties and methods that belong to the type. This includes anything marked as static, class, and init.

class SomeClass {
  static let someKey = "0000"
  
  init() { ... }
  
  static func someMethod() { ... }
}

let key = SomeClass.someKey // Shorthand for SomeClass.self.someKey
let someClass = SomeClass() // Shorthand for SomeClass.self.init()
SomeClass.someMethod() // Shorthand for, you guessed it, SomeClass.self.someMethod()

While we don’t see a metatype instance, we are actually using metatypes to perform all these actions! For instance, SomeClass.someKey is the same as SomeClass.self.someKey, but Swift hides all the clutter from us. I typically add properties and methods to types when there’s a piece of functionality that isn’t dependent on an instance.

Fun fact, this is exactly what is being done when you pass a metatype to a JSONDecoder’s decode method:

// JSONDecoder's method
func decode<T>(T.Type, from: Data) -> T { ... }

let decoder = JSONDecoder()
decoder.decode(SomeClass.self, from: someData) // now JSON Decoder has access to SomeClass' init method.

Conclusion

To summarize:

A metatype is simply a type with .Type appended to it, e.g. String.Type
A metatype instance can be specified by appending .self to a type, e.g. String.self
To get a metatype instance at runtime, simply pass an instance to type(of:)
Metatypes allow access to properties, methods, and initializers belonging to the type.

I hope you found this explanation of metatypes useful! We have only scratched the surface, however. For a deeper dive with more examples, please see Bruno Rocha’s excellent post on Metatypes!

Swift’s Guard Statement: Purpose and Usage

Eman Harout — Wed, 14 Apr 2021 00:00:00 GMT

Swift’s guard statement is a powerful, well designed feature that promotes clean code when used properly. It is a specialized form of control flow with important advantages. Today we’ll cover the unique characteristics of guard and its proper usage.

To understand the benefits guard offers, we briefly compare it to its parent, the infamous if statement. guard is similar to an if statement with two important distinctions:

Forced Exits: guard requires exiting the current scope when the condition is not met.
Remaining in Current Scope: guard allows the happy path to proceed in the current scope. Let’s examine both and how they contribute to cleaner code.

Forced Exits

Here we have a function that allows customers over 21 entry to the bar.

func enterBar(age: Int) {
  guard age >= 21 else {
    // handle forced exit
    return
  }
  
  // open door
  // grant entry
  // close door
}

Our function is fairly simple. We check if the customer is over 21. If so, we open the door and let them through. If underage, we’re forced to return from the function. There is a good reason for this: guard is guiding us to fail early, preventing further execution of the function. Just as real guards block trespassers, Swift’s guard blocks unwarranted access deeper into the function!

But why is it good to fail early? It’s about logical conciseness. You wouldn’t open the door to grant entry, then check for ID; it doesn’t make sense to perform conditional actions without checking the condition first—you’re just delaying the potential failure! It’s far better to identify mandatory conditions, and guard against them early. So remember: fail early and often.

Remaining in Current Scope

So far we’ve discussed what happens when the condition fails, but there’s an advantage with guards upon passing too. Let’s examine:

// Scenario A: If
if age >= 21 {
  // new scope
} else if age >= 18 {
  // another new scope
}

// Scenario B: Guard
guard age >= 21 else {
  // new scope only upon failure
  return
}

// passing-flow remains in original scope

Since if can check countless conditionals via else if, each condition has its own nested scope. if does not understand if a particular condition is a happy path or failure, so it treats them all the same by scoping them all.

Not so with guard. Guard assumes there are two outcomes: failure or passing. It sensibly provides a nested scope only if you fail. When you pass, there’s no newly nested scope at all—you just proceed in the same scope as the guard.

This has important implications. First, this means guard should be used if you expect one of two outcomes. Second, it improves code clarity by eliminating the need for a nested scope. Since most our time spent as programmers is in code comprehension, this is a welcomed benefit. No one wants an entire function nested—potentially multiple times—just because a mandatory condition must be met.

When you see an entire function is nested because of a mandatory condition, just swap that if for a guard instead. Your colleagues (and future self) will thank you.

Conclusion

To summarize, guards are a specialized form of if. Guard comes with two important advantages: forced exits on failure, and remaining in current scope upon passing. Guards are to be used when a condition failing means the function can’t carry out its duties, so it’s sensible to identify mandatory conditions and guard against them as early as possible. Guards also help with code clarity by forgoing a nested scope when the condition is met. Hope you all found this helpful!

Swift Solutions: Adapter Pattern

Eman Harout — Sat, 24 Jun 2017 00:00:00 GMT

The Adapter Pattern is a design pattern that enables objects with similar functionality to work together despite having incompatible interfaces. It allows for integration that results in code that is cleaner and easier to use. Quite literally, it adapts an object so that it uses more familiar APIs.

Use Cases

The Adapter Pattern should be used when the following are true:

A component shares similar functionality with existing objects in your app.
Despite sharing similar functionality, the component has an interface that is incompatible with other objects in your app. The component is often from a third party framework.
The component’s source code cannot (or should not) be modified.
The component needs to integrate with your app.

The Adapter Pattern allows us to take this foreign object and make it play nice with our existing objects. There are two primary approaches to accomplishing this: Swift Extensions and the Dedicated Adapter Class.

Enough with theory! Let us see what the Adapter Pattern looks like in practice :)

Adapter Pattern: Swift Extension Approach

The Swift Extension is an elegant solution for most simple scenarios.

protocol Jumping {
    func jump()
}
	
class Dog: Jumping {
    func jump() {
        print("Jumps Excitedly")
	}
}
	
class Cat: Jumping {
    func jump() {
        print("Pounces")
    }
}
 
let dog = Dog()
let cat = Cat()

Here we have a dog and a cat. They are both able to perform jump(). Now let’s say we integrate a third party framework, and have a foreign animal.

The Adaptee

class Frog {
    func leap() {
        print("Leaps")
    }
}

let frog = Frog()

A few things to note:

Our leaping frog object has some similar functionality with our furry friends.
Though it jumps, its interface is different: we have to call leap() instead of jump() to get the desired functionality.

The Adapter

extension Frog: Jumping {
    func jump() {
        leap()
    }
}

Here we integrate our component by implementing the Adapter Pattern. We simply conform Frog to Jumping and create a wrapper function our other objects recognize. We are now able to get the same behavior out of our frog without modifying its existing implementation. We simply extend it with a new wrapper function to abstract away its differences! :)

“Objects should be open for extension, but closed for modification.”

Before and After

It is helpful to see how we would work with our objects before and after we adapted our frog’s interface.

Before:

var animals: [Jumping] = [dog, cat]

func jumpAll(animals: [Jumping], frog: Frog = nil) {
    for animal in animals {
        animal.jump()
    }
    if let frog = frog {
        frog.leap()
    }
}

Here we want to make all our animals jump. Without an implemented adapter, the caller has to have knowledge of the frog’s foreign interface. We cannot treat the component like the rest of our code.

After:

var animals: [Jumping] = [dog, cat, frog]

func jumpAll(animals: [Jumping]) {
    for animal in animals {
        animal.jump()
    }
}

With the adapter in place, we can treat the frog like the rest of our objects and include it in our animals array. We also get to simplify our function by removing the frog: parameter.

Moreover, we can treat the frog like any other native object by simply calling jump() on it. The frog is obviously still “leaping” under the hood, but we do not care. The caller no longer needs to have knowledge of how Frog jumps.

Adapter Pattern: The Dedicated Adapter Approach

For more complex scenarios, creating a dedicated adapter class can be helpful.

class FrogAdapter: Jumping {
    private let frog = Frog()

    func jump() {
        frog.leap()
    }
}

Here we create an adapter class that holds the foreign component in a private property.

Extending Frog may have exposed more than we would have liked. With a dedicated adapter, the caller is no longer able to manipulate the frog directly; it can only use whatever is exposed by FrogAdapter. This allows for better encapsulation of the frog, giving us complete control over what gets exposed to the caller.

And that is pretty much it for both approaches!

Conclusion

The Adapter Pattern freed us from having to accommodate objects with different interfaces through the unification of their APIs. This greatly increased the clarity and simplicity of our code, enabling us to integrate a foreign object with ease. It is a classic, simple pattern that is highly practical in its usage. Hope you enjoyed learning it!