This post was originally published on 02/24/18 and updated on 02/12/23.

Let’s start with a simple case:

enum TestEnum {
    case testA
    case testB
}

let testEnum1 = TestEnum.testA
let testEnum2 = TestEnum.testB
let testEnum3 = TestEnum.testA

print(testEnum1 == testEnum2) //false
print(testEnum1 == testEnum3) //true

So in this example, we are defining an enum called TestEnum, which has two cases. Then we are declaring two variables of this type and we compare them – they behave as expected and everything is working fine.

Enums With Associated Values

Now let’s look into the hard stuff. First, we add an associated value to one of the cases:

enum TestEnum {
    case testA(Int)
    case testB
}

let testEnum1 = TestEnum.testA(5)

As already explained in this post, you can use an enum with associated values to add some additional information. It can only be accessed within a switch statement though:

enum TestEnum {
    case testA(Int)
    case testB
}

let testEnum1 = TestEnum.testA(5)


switch testEnum1 {
case .testA(let a):
    print("Case testA with associated value \(a)")
case .testB:
    print("Case testB")
}

As expected, the output is

Case testA with associated value 5

Comparing Enums With Associated Values

So, now let’s try to compare two of them:

enum TestEnum {
    case testA(Int)
    case testB
}

let testEnum1 = TestEnum.testA(5)
let testEnum2 = TestEnum.testB

if testEnum1 == testEnum2 {   //COMPILER ERROR!!!
    print("equal")
}

In this case, we get a compiler error:

Binary operator '==' cannot be applied to two 'TestEnum' operands

And this makes sense because it’s not clear when they are equal. For example, are two testA values equal if their associated values are equal? Or are two testA values always equal? It depends on the circumstances and the meaning of the enum.

Equatable protocol

But we can implemente our definition of ==. For that, we implement the Equatable protocol:

enum TestEnum {
    case testA(Int)
    case testB
}

extension TestEnum: Equatable {
    
    public static func ==(lhs: TestEnum, rhs:TestEnum) -> Bool {
        switch lhs {
        case .testA(let a):
            switch rhs {
            case .testA(let b):
                return a == b
            case .testB:
                return false
            }
        case .testB:
            switch rhs {
            case .testB:
                return true
            case .testA:
                return false
            }
        }
        
    }
}

That’s a lot of code for a little bit of work, but it does the job! Now, two TestEnum are equal, if one of the following two conditions is true:

• Both are testB cases.
• Both are testA cases AND their associated values are equal.

Of course, it’s possible to write that code a little bit more elegant:

enum TestEnum {
    case testA(Int)
    case testB
}

extension TestEnum: Equatable {
    
    public static func ==(lhs: TestEnum, rhs:TestEnum) -> Bool {
        
        switch (lhs,rhs) {
        case (.testB, .testB):
            return true
        case (.testA(let a), .testA(let b)):
            return a == b
        default:
            return false
        }
        
    }
}

And now let’s test whether it’s working as expected:

let testEnum1 = TestEnum.testA(5)
let testEnum2 = TestEnum.testA(10)
let testEnum3 = TestEnum.testA(5)
let testEnum4 = TestEnum.testB
let testEnum5 = TestEnum.testB

print(testEnum1 == testEnum2) //false
print(testEnum1 == testEnum3) //true
print(testEnum1 == testEnum4) //false
print(testEnum4 == testEnum5) //true

It can also be implemented in another way, like this:

• Both are testB cases.
• Both are testA cases

Then, the associated values don’t influence the equality:

extension TestEnum: Equatable {
    
    public static func ==(lhs: TestEnum, rhs:TestEnum) -> Bool {
        
        switch (lhs,rhs) {
        case (.testB, .testB):
            return true
        case (.testA,.testA):
            return true
        default:
            return false
        }
    }
}

let testEnum1 = TestEnum.testA(5)
let testEnum2 = TestEnum.testA(10)
let testEnum3 = TestEnum.testA(5)
let testEnum4 = TestEnum.testB
let testEnum5 = TestEnum.testB

print(testEnum1 == testEnum2)
print(testEnum1 == testEnum3)
print(testEnum1 == testEnum4)
print(testEnum4 == testEnum5)

As said before, it depends on the context.

This post was originally published on 02/09/17 and updated on 02/05/23.

Let's start by looking at the mechanics of merge sort:

Understanding the Mechanics of Merge Sort

The divide-and-conquer approach is a technique used by merge sort to sort an array of elements. It starts by dividing the input array into two halves and continues to divide each half until each subarray contains only one element. This approach allows the algorithm to break down a complex problem into smaller, more manageable subproblems that can be solved more easily.

Once the input array has been divided into subarrays containing only one element, the algorithm begins the merging process. The merging process involves comparing and merging adjacent subarrays into larger sorted subarrays. This process is repeated until the entire input array is sorted and merged into a single sorted array. The merging process ensures that the elements in the final sorted array are in the correct order.

Time and space complexity

Merge sort has a time complexity of O(n log n), where n is the number of elements in the array. This is because the algorithm divides the array into two halves in each recursive step, and each step requires O(n) time to merge the two sorted halves. The log n term comes from the number of recursive steps required to divide the array into single elements.

The space complexity of merge sort is O(n), as the algorithm requires an auxiliary array to store the sorted elements while merging the two halves. This is because the algorithm sorts the elements in-place, meaning that it operates on the original array rather than creating a new one.

It's important to note that the time and space complexities of merge sort are the same regardless of the order of the elements in the original array. This makes it a stable sorting algorithm, meaning that elements that have the same value maintain their relative order in the final sorted array.

Example

We want to sort the array [98,1,45,13,6]. First, the array will be divided into subarrays [98,1,45] and [13,6]. Then, the divided lists will be divided again. This process will be continued until  every array has exactly one item. In the picture, this is accomplished in line four.

Then the merging process starts: Always two lists will be merged. So the two arrays [98] and [1] will be merged into [1,98]. Additionally, the arrays [45] and [13] will be merged into [13,45]. It's important to note that in this merging process, the elements get sorted: We look at the first elements and take the smaller element. Then we continue until both arrays are merged.

The process will be repeated until only one list is left – the sorted list.

Merge Sort in Swift

Now let’s implement the algorithm in Swift. There are different approaches for solving that problem, we will take a recursive one:

import Foundation

func merge(left:[Int],right:[Int]) -> [Int] {
    var mergedList = [Int]()
    var left = left
    var right = right
    
    while left.count > 0 && right.count > 0 {
        if left.first! < right.first! {
            mergedList.append(left.removeFirst())
        } else {
            mergedList.append(right.removeFirst())
        }
    }

    return mergedList + left + right
}

func mergeSort(list:[Int]) -> [Int] {
    guard list.count > 1 else {
        return list
    }
    
    let leftList = Array(list[0..<list.count/2])
    let rightList = Array(list[list.count/2..<list.count])
    
    return merge(left: mergeSort(list:leftList), right: mergeSort(list:rightList))
}

The function mergeSort divides the list into two lists and returns the merged and sorted list by using the function merge. Within the function call, the function calls itself recursively for both lists. When mergeSort gets a list, that has just one element, it returns the whole list.

The function merge always compares the first items of the two lists and appends the smaller item to the new sorted list.

Testing the algorithm

Now we can test the algorithm:

var list = [Int]()

for _ in 0..<100 {
    list.append(Int(arc4random_uniform(UInt32(1000))))
}

print(list)

print()

print(mergeSort(list: list))

The generated output is:

[723, 647, 801, 378, 630, 789, 654, 1, 66, 848, 178, 837, 79, 921, 880, 663, 835, 497, 459, 59, 940, 380, 37, 897, 29, 346, 11, 192, 955, 652, 276, 205, 903, 935, 762, 681, 211, 218, 586, 393, 372, 708, 202, 660, 35, 654, 392, 839, 710, 948, 50, 726, 999, 79, 881, 324, 22, 49, 564, 639, 117, 256, 978, 179, 942, 710, 7, 389, 701, 128, 239, 548, 848, 771, 538, 548, 359, 50, 752, 892, 87, 107, 959, 717, 846, 546, 417, 350, 212, 239, 938, 788, 75, 16, 664, 897, 588, 368, 199, 350]

[1, 7, 11, 16, 22, 29, 35, 37, 49, 50, 50, 59, 66, 75, 79, 79, 87, 107, 117, 128, 178, 179, 192, 199, 202, 205, 211, 212, 218, 239, 239, 256, 276, 324, 346, 350, 350, 359, 368, 372, 378, 380, 389, 392, 393, 417, 459, 497, 538, 546, 548, 548, 564, 586, 588, 630, 639, 647, 652, 654, 654, 660, 663, 664, 681, 701, 708, 710, 710, 717, 723, 726, 752, 762, 771, 788, 789, 801, 835, 837, 839, 846, 848, 848, 880, 881, 892, 897, 897, 903, 921, 935, 938, 940, 942, 948, 955, 959, 978, 999]

As we can see, we get the expected results.

iOS Development

Code styling is both a subjective and important topic. In this post, Daniel James makes many good proposals.

How Senior iOS Engineers Style Code: Performance And Clarity

This article is the result of studying Swift Style from The Pragmatic Bookshelf and lived experience. Any level iOS engineer can use this…

MediumDaniel James

Watch this video if you want to know how to create the sliders of the iOS control center:

This is a short but good post about the options for adding animations to SwiftUI views:

Understanding basic animations in SwiftUI

Learn different options to animate SwiftUI views in your iOS applications. Understand the two animation options animation(_:value:) view modifier and the withAnimation(_:_:) global function.

Async/await is great, but it's even greater if you know how to combine it with the good old completion handlers:

How to use async/await with completion handlers | Danijela’s blog

When the new Swift concurrency model was announced at WWDC 2021 we all wanted to jump on that wagon. However, rewriting your entire codebase might not be the best solution. Instead, you have the option to slowly start adapting the new model by bridging the old code with the new.

Danijela's blog

Performance is an important topic and understanding big O notation helps you to write efficient algorithms. Additionally, it's also important to know about this topic in coding interviews.

Big O notation in Swift

This article will help novice iOS developers understand the performance of algorithms in Swift.

MediumVladimir Buikliskii

Back in the day, there was no automatic reference counting. Today you have ARC and it's great. However, that doesn't mean you cannot make mistakes. For example, it's still possible to create a so-called retain cycle. So it's good to understand how memory management works in Swift:

Dive into Swift’s Memory Management

Swift uses ARC to track and deallocate unused objects. Learn about the three types of reference counts and how ARC works — in this post

Level Up CodingAlex Dremov

We all know it - we start a shiny new project, but after a few weeks we don't work on it anymore. If you want to change that, read this post:

Say Goodbye to Unfinished Pet Projects — Here’s How to Effectively Plan

Stop watching your pet projects collect dust

Better ProgrammingIvan Reznikov

Everybody likes the idea of becoming an entrepreneur, but how about becoming an intrapreneur?

Achieving Success in the Corporate World: The First Principal Agent Mindset

Entrepreneurship may sound appealing, but it is not easy. Working for a company can be great if you find the right fit. Act as the first principal agent to climb the corporate ladder. Think independently, take ownership, build a strong reputation and advance together with your employer.

Deliberate Diligence - Become the Master of your AgendaMartin

if let shorthand syntax in Swift

Using optional binding is very common in Swift. With the if let shorthand syntax it is easier to write and read. It has been introduced with Swift 5.7 and Xcode 14. if let for optional binding Optional binding is used to access optional in a safe way. For example,

ThomasHanning.comThomas Hanning

SwiftUI: Alert

Alert is equivalent to UIKit’s UIAlertView in SwiftUI. This post is about creating and presenting an alert in SwiftUI. Hint: This post has been updated to Swift 5.7 and Xcode 14.2 Creating an alert in SwiftUI Creating an alert in SwiftUI is very straightforward: Alert(…

ThomasHanning.comThomas Hanning

Should You Still Learn UIKit?

SwiftUI is becoming better and better. So the question arises for new iOS developers whether UIKit is still relevant enough to learn it.

ThomasHanning.comThomas Hanning

Xcode for Windows?

Xcode for Windows doesn’t exist. Let’s look at the alternatives.

ThomasHanning.comThomas Hanning

This post was originally published on 01/30/18 and updated on 01/29/23.

What is Xcode?

Xcode is an IDE (integrated development environment) for iOS app development. That means you can create applications for macOS, iOS, watchOS, and tvOS. Xcode is a macOS application so it is not possible to install Xcode on a Windows system. Xcode is available for download on both the Apple Developer Portal and the macOS App Store.creating iphone apps on windows

Should you install macOS on a Windows PC?

In theory, it’s possible to install macOS on a non-Apple machine, both natively and virtually. Then, Xcode could be installed. However, you shouldn’t do that! It’s not working very well and it’s deemed illegal by Apple’s licensing terms, so you must not go this route. And don’t be fooled: Many sources on the internet promises you that this was a good idea - it is not.

Renting a Mac in the cloud

A Mac is a great computer but it’s also quite expensive – that’s probably the main reason many developers wish that there were Xcode for Windows. An alternative for buying a Mac is renting a Mac in the cloud. Several providers offer that service, for example, this one. In this particular case, Xcode is already installed, so you can start immediately. That’s a good way at the beginning. But you cannot  deploy the app directly to iOS devices, so in the end, it’s still advisable to buy a Mac someday though.

Non-native ways for developing iOS apps

Many people who wish to install Xcode on a Windows machine want to develop iOS applications. There are options to develop iOS apps without using Xcode directly, like Microsoft MAUI and Flutter. You can develop the app once and use the code for both Android and iOS. Depending on the use case, that can be a good way. However, without a Mac, you can't build and test the app on an iOS device.

Alternatives for learning Swift

If you just want to learn iOS development, but you don't have a Mac yet, then there are good alternatives. In this case, you can start by learning Swift. This is the programming language to choose for developing iOS, macOS, tvOS, and watchOS applications.

Swift is open source and there are several ways for writing Swift code on a non-Mac machine. First, there is the Swift Playgrounds app for the iPad. You can use it to write Swift code and also learn how to do it. Additionally, it's even possible to create apps with it. However, you don't have as many possibilities as with Xcode. So it's good for learning but in most cases, not enough for building a real-world application.

Since Swift is open source, it's possible to run Swift on Windows. For example, you can use Visual Studio Code. It's not possible to write an iOS app this way though. There are also options on Linux. As with Swift playgrounds, that’s a good way for starting.

If you want to learn more about Swift, take a look at the Swift category on my blog. There are also a lot of other good tutorials out there. For example, you can take a look here. Swift is a very good programming language and when you are new to programming, it’s a good choice for starting.

Buying a cheaper Mac

If you decide to buy a Mac, you don’t have to buy the newest machine. At the time of this writing, the newest Xcode version 14.2 runs on all Macs with at least macOS 12.5. There are nice refurbished devices in the Apple Store, but used devices are also a good alternative. This is a good way to build iOS apps.

Conclusion

Unfortunately, there is no Xcode for Windows. And there are no ways to install macOS on a Windows machine. Renting a macOS machine in the cloud is an alternative, but you cannot deploy apps to a device. If it’s just about learning Swift, there are alternatives like the Swift Playgrounds Apps for the iPad or running Swift code on Windows or Linux. But if you want to build iOS apps, you should buy a Mac. And on Mac you can build iOS and Android apps.

SwiftUI is becoming better and better. So the question arises for new iOS developers whether UIKit is still relevant enough to learn it.

I started learning iOS development back in 2011. At that time, iOS apps were still developed with Objective-C — no automatic reference counting and no auto layout were available at that time. So a lot has changed over the years. Then came Swift and it was a big change. But now there is SwiftUI and it’s an even bigger step. But does that mean that you shouldn’t learn UIKit?

Let’s start by looking at a poll I recently made on LinkedIn:

So more developers would use SwiftUI in a new app project. But the difference is not big — at least 41 percent voted for UIKit. There seem to be still good reasons for using UIKit — even in a new app project.

Of course, the topic is also a little bit subjective. Here are the reasons that I believe are the advantages of UIKit and SwiftUI respectively:

UIKit

• Most existing apps use UIKit. So if you start working as an iOS developer, it’s very likely that you will work on projects that use UIKit.
• Over the years many resources like blog posts, open-source libraries, and tutorials have been created. And they use UIKit. Sure, there are more and more resources that use SwiftUI, but it will take some time until the older resources are not relevant anymore.
• For complex layouts, UIKit is still the better choice. SwiftUI is much younger than UIKit and the API coverage is still better in UIKit. Especially when the UI requirements are very strict, you have more options with UIKit.
• For SwiftUI you have to choose a high deployment target. The minimum is iOS 13, but higher is even better. One could argue that this is not a big deal for an iOS app because most users are on the latest iOS version. However, if you have an app that has a big audience you want to have a low deployment target.

SwiftUI

• Development is less error-prone: SwiftUI is a declarative UI framework. That means you don’t have to handle all possible UI states on your own. As a result, complexity decreases and you will have fewer bugs.
• Development with SwiftUI is faster: Because of its declarative nature, it’s also quicker to develop with SwiftUI. Additionally, you have the preview feature in Xcode which saves a lot of compile time.
• SwiftUI is easier to learn than UIKit because you have much less boilerplate code. Just compare the implementation of an UITableView with a List in SwiftUI. It’s a huge difference in complexity.

The Transition

We see that both frameworks have their place, but obviously, SwiftUI is the future. Therefore, we are in a transition phase. Many people compare this with the transition from Swift to Objective-C because there are a lot of similarities: Both languages can be used in the same project, one is the future and the new one has a lot of advantages. Also worth noting is the fact that Swift was at the beginning difficult to use because of the bad Xcode integration. For example, code completion crashed all the time so it was quite difficult to develop with Swift at the beginning.

But in the end, the transition from Objective-C to Swift was fast. I believe that the transition from UIKit to Swift will take much more time because the transition is more complex. Probably UIKit will never become as irrelevant as Objective-C is today.

The Biggest Similarity

Before we conclude let us acknowledge one important fact: Both SwiftUI and UIKit are great frameworks and you can create outstanding and meaningful iOS apps with both of them. So in the end it’s not even possible to make a completely wrong decision.

Conclusion

SwiftUI is the future of iOS development but UIKit is still very relevant today and will be for some time. So if you want to become an iOS developer you have to learn both. On the other hand, SwiftUI and UIKit are very complex. Therefore, it’s tricky to learn both at the same time.

My advice is to focus on SwiftUI in the beginning because it’s easier to learn. After you’ve learned the basics and can write simple apps, it’s a good time to learn UIKit.

Creating an alert in SwiftUI is very straightforward:

Alert(title: Text("Hello World!"))

But how do you present it? Since SwiftUI is a declarative UI framework, you don’t present it by reacting to a user action in a callback. Instead, you declare under which state it should be presented. Remember: A SwiftUI view is a function of its state.

You define the conditions for presenting the alert by using the alert function. It takes two arguments:

1. A bool binding (the state) specifies whether the alert should be displayed.
2. A closure that returns the actual alert.

SwiftUI refreshes the view whenever the bool value changes since it is a state. As a consequence, the alert gets displayed if it’s set to true. After the alert gets dismissed, the bool value is set automatically to false.

Take a look at the following example:

struct ContentView: View {
    
    @State var showAlert = false
    
    var body: some View {
        VStack {
            Button(action: {
                self.showAlert.toggle()
            }) {
                Text("Show alert!")
            }
        }.alert(isPresented: $showAlert) { () -> Alert in
            Alert(title: Text("Hello World!"))
        }
    }
    
}

The alert has by default an “OK” button.

Of course, it’s also possible to add a message by using the message parameter:

Alert(title: Text("Hello World!"), message: Text("An important message"))

Adding buttons and actions

So the alert from the last example is quite appropriate for displaying a message. But in many cases you also want the user to take a decision and you want to define an action. For that, you can add one or two buttons that have completion blocks. An alert with one button can be created as follows:

.alert(isPresented: $showAlert) { () -> Alert in
            let button = Alert.Button.default(Text("OK")) {
                print("OK Button Pressed")
            }
            return Alert(title: Text("Hello World!"), message: Text("An important message"), dismissButton: button)
 }

Besides default there are another two button types: destructive and cancel. You should pick the one that fits best to your action.

Now let’s add two buttons:

.alert(isPresented: $showAlert) { () -> Alert in
            let primaryButton = Alert.Button.default(Text("Primary")) {
                print("primary button pressed")
            }
            let secondaryButton = Alert.Button.cancel(Text("Secondary")) {
                print("secondary button pressed")
            }
            return Alert(title: Text("Hello World!"), message: Text("An important message"), primaryButton: primaryButton, secondaryButton: secondaryButton)
        }

It’s not possible to add more than two buttons though. Although that’s possible in UIKit, that’s not a restriction in SwiftUI: Alerts with more than two buttons could be confusing. Instead, you can use an action sheet.

Creating multiple alerts in SwiftUI

So far so good. But for a view, it’s not so uncommon to have more than one scenario for displaying an alert. So do you just chain the .alert functions? Let’s try it out:

// DOESN'T WORK:
struct ContentView: View {
    
    @State var showAlert1 = false
    @State var showAlert2 = false
    
    var body: some View {
        VStack {
            Button(action: {
                self.showAlert1.toggle()
            }) {
                Text("Show alert!")
            }
            Button(action: {
                self.showAlert2.toggle()
            }) {
                Text("Show alert!")
            }
        }.alert(isPresented: $showAlert1) { () -> Alert in
            Alert(title: Text("Hello World!"))
        }.alert(isPresented: $showAlert2) { () -> Alert in
            Alert(title: Text("Hello World2!"))
        }
    }
}

Unfortunately, this doesn’t work. The reason is that every view can only have one alert. So one possibility is to call the alert function on the two button views:

struct ContentView: View {
    
    @State var showAlert1 = false
    @State var showAlert2 = false
    
    var body: some View {
        VStack {
            Button(action: {
                self.showAlert1.toggle()
            }) {
                Text("Show alert!")
            }.alert(isPresented: $showAlert1) { () -> Alert in
                Alert(title: Text("Hello World!"))
            }
            
            Button(action: {
                self.showAlert2.toggle()
            }) {
                Text("Show alert!")
            }.alert(isPresented: $showAlert2) { () -> Alert in
                Alert(title: Text("Hello World2!"))
            }
        }
    }
}

This works. However, if you have several alerts, this can become quite confusing. Alternatively, you can use an overloaded method of .alert. Instead of a boolean, it takes a binding that confirms to the Identifiable protocol. A type confirms to this protocol if it implements an id so that an instance can be identified uniquely. We create a struct that confirms to this protocol. Furthermore, this struct has an enum that represents all possible alert types:

struct AlertId: Identifiable {
    
    var id: AlertType
    
    enum AlertType {
        case type1
        case type2
    }
}

struct ContentView: View {

    @State var alertId: AlertId?
    
    var body: some View {
        VStack {
            Button(action: {
                self.alertId = AlertId(id: .type1)
            }) {
                Text("Show alert!")
            }
            
            Button(action: {
                self.alertId = AlertId(id: .type2)
            }) {
                Text("Show alert!")
            }
        }.alert(item: $alertId) { (alertId) -> Alert in
            return createAlert(alertId: alertId)
        }
    }
    
    private func createAlert(alertId: AlertId) -> Alert {
        switch alertId.id {
        case .type1:
            return Alert(title: Text("Hello World!"))
        case .type2:
            return Alert(title: Text("Hello World2!"))
        }
    }
}

Now, whenever the value of alertId changes, the view gets refreshed (a SwiftUI view is a function of its state!) and displays the alert. To make the code a little bit more clear, we create the alert inside a helper function.

iOS 15 And Above

In iOS 15 and above there is a new syntax available. You can display the alert directly with the alert modifier:

struct ContentView: View {
    
    @State var showAlert = false
    
    var body: some View {
        VStack {
            Button(action: {
                self.showAlert.toggle()
            }) {
                Text("Show alert!")
            }
        }.alert(Text("Hello World!"), isPresented: $showAlert, actions: {} )
    }
    
}

It’s still possible to use the old syntax though.

if let for optional binding

Optional binding is used to access optional in a safe way. For example, take a look at the following example:

var a: Int? = 5

if let a = a {
    print(a)
}

Here a is an optional and gets shadowed inside the if let code block. In that block, a is no longer an optional. If a is nil, the code block wouldn’t be executed.

However, it is a little bit strange to write and read.

if let shorthand syntax

With the if let shorthand syntax, it becomes easier:

var a: Int? = 5

if let a {
    print(a)
}

It’s not only more clear, but it’s also less error-prone: It’s common practice to use the same variable for the shadowing variable. However, if the name of the variable is long and difficult, a typo can easily happen. Then, you have two similar named variables accessible inside the code block. With the if let shorthand syntax, this cannot happen.

guard

Not only if let is often used for handling optionals, but guard as well. Here you have a similar shorthand syntax:

func doSomething(a:Int?) {
     guard let a else {
          return
     }

     print(a)
}

If you want to learn more about optionals, take a look at my blog post about optionals.

References

if let shorthand for shadowing an existing optional variable

Do you want to learn more about iOS development?

Take a look at the following book (affiliate link):

Property wrappers enable you to reuse code that specifies the access pattern of a property.

Often you add behaviour to a property through its observers. For example, you can use the didSet observer to trim a string:

class TestClass {

    var trimmedString: String = "" {
        didSet {
            trimmedString = trimmedString.trimmingCharacters(in: .whitespaces)
        }
    }
    
}

var test = TestClass()
test.trimmedString = "    test"
print(test.trimmedString) //"test"

This is very useful. However, if you want to add this behaviour to several properties, you have to implement this behaviour separately for each property. Instead, you can define a so called property wrapper.

You create a property wrapper by creating a struct, class or enum that uses the @propertyWrapper annotation. Inside the property wrapper you have to implement the wrappedValue property. By implementing property observers of wrappedValue you can add custom behaviour.

Note that observers of stored properties (didSet, willSet) get not called at initialisation time. Hence, you also have to implement the init method.

Let’s create a property wrapper for the use case of trimming a string:

@propertyWrapper struct WhiteSpacesTrimmed {
        
    var wrappedValue: String {
        didSet {
            print("propertyWrapper didSet")
            wrappedValue = wrappedValue.trimmingCharacters(in: .whitespaces)
        }
    }
    
    init(wrappedValue:String) {
        self.wrappedValue = wrappedValue.trimmingCharacters(in: .whitespaces)
    }
    
}

A property wrapper can then be applied to every property that has the corresponding type:

class TestClass {
    @WhiteSpacesTrimmed var test = ""
    @WhiteSpacesTrimmed var test2 = ""
}

let testClass = TestClass()
testClass.test = "    test"
print(testClass.test) //"test"

As you can see, you just have to add the annotation @WhiteSpacesTrimmed.

wrappedValue as a computed property

In the last example, the wrapped value was a stored property. It’s also possible to use a computed value:

@propertyWrapper struct Max100 {
    
    private var value: Int = 0
    
    var wrappedValue: Int {
        get {
            return value
        }
        set {
            value = min(100, newValue)
        }
    }
    
    init(wrappedValue: Int) {
        self.wrappedValue = wrappedValue
    }
    
}

class TestClass2 {
    @Max100 var test = 0 
}

let testClass2 = TestClass2()
testClass2.test = 300
print(testClass2.test)

In this example we created a property wrapper that limits an integer property to the maximum value of 100.

Customizing a property wrapper

As you have seen in the last example, a property wrapper can have properties of its own. But it’s also possible to initialise these properties with custom values every time you use the property wrapper.

In the following example we create a property wrapper that writes and saves a string value to the user defaults. The name of the user defaults key is customizable:

@propertyWrapper
struct UserDefaultsWrapper {
    
    var key: String
    
    var wrappedValue: String? {
        set {
            UserDefaults.standard.set(newValue, forKey: key)
        }
        get {
            UserDefaults.standard.string(forKey: key)
        }
    }
    
}

class TestClass3 {
    @UserDefaultsWrapper(key: "testKey") var test: String?
}

If your property wrapper has properties, they can be initialised. If they have an initial value, they’re are optional. If they lack an initial value, they are mandatory.

Projected values

Besides wrappedValue there is another special property inside a property wrapper: projectedValue. This value is accessible from the outside by using the symbol $. Hence, you can use it to provide additional functionality.

In the following example we again create a property wrapper that trims a string. But in this case we save the initial value inside the projectedValue property:

@propertyWrapper struct WhiteSpacesTrimmed {
        
    var projectedValue: String
    
    var wrappedValue: String {
        didSet {
            self.projectedValue = wrappedValue
            wrappedValue = wrappedValue.trimmingCharacters(in: .whitespaces)
        }
    }
    
    init(wrappedValue:String) {
        self.projectedValue = wrappedValue
        self.wrappedValue = wrappedValue.trimmingCharacters(in: .whitespaces)
    }
    
}

class TestClass5 {
    @WhiteSpacesTrimmed var test = "       test"
}

print("projected Values")
var testClass5 = TestClass5()
print(testClass5.test) //"test"
print(testClass5.$test) //"       test"

References

Title image: @ Foxys Forest Manufacture / shutterstock.com

Almost a year ago Apple introduced SwiftUI at WWDC 2019. It’s still a very young technology but it’s quite clear that it’s the future not only of iOS development, but of macOS, watchOS, and tvOS development as well. What are the advantages of using SwiftUI?

Development is faster

Let’s face it: time matters. We love our craft but we also want to be fast in order to satisfy customer demands and to be more productive. One essential part of SwiftUI is preview. It enables you to see the graphical result of your UI code at development time.

To a certain degree that holds true for developing with UIKit by using the interface builder as well. However, with SwiftUI you can define test data for preview. Consider a tableview: you don’t see just a single prototype cell, but the whole table view with realistic data. Additionally, you can see different screen sizes at the same time. Also other states as localisation and dark mode can be observed.

You can also use live preview. After starting it, you can interact with your UI. It’s like using the simulator with the big difference that you don’t have to recompile after applying changes.

This safes a lot of build time. When projects becomes huge, long build times can decrease productivity massively.

Development is less error prone

There is one thing though, that’s even more important than time: quality. The complexity of building an UI with a lot of interaction possibilities is huge. Handling all these different states (i.e. logged in / not logged in) is very difficult and can be compared to handling multithreading code.

With SwiftUI, this complexity decreases dramatically. UIKit is imperative programming, whereas SwiftUI is declarative programming. So what’s the difference? As the names imply, by using an imperative approach, you tell the framework what should happen and also how. On the other hand, by using a declarative approach, you just describe the desired result.

An example: Imagine a screen with a login form. When the users has successfully logged in, you update the UI in the network callback according to the ‘logged in’  state. For example, you change the text of the button (‘log in’ -> ‘log out’), display the user’s name and show other menu options. When the user ever gets logged out, it’s your responsibility to react and change the UI state. On the other hand, if you are using a declarative approach, you just describe the whole UI dependent on the login state. If the variable with the login state ever changes, the UI will be updated automatically without any manual action.

And that’s just one state. The screen can have many others states and depending on the order of the user actions there can be unpredictable outcomes. Of course there are also good practices to handle this with an imperative approach. However, SwiftUI makes it automatically and easy.

Swift UI is exciting

For me as a long term iOS developer, it’s very exciting to use a completely new technolgy for developing apps. And it’s not like using a different framework. It’s a different approach of programming. As explained in the last paragraph, switching from imperative to declarative programming is a huge deal. 

For us developers technology is not just a tool for creating an app. Instead, the technology as such matters. And learning a new technology is like unboxing the shiny new iPhone. 

SwiftUI is the future anyway

In my opinion, the previous reasons are sufficient to justify the switch to SwiftUI. But even if you are not convinced yet that developing with SwiftUI is faster and less error prone, it’s still necessary for every iOS developer to learn SwiftUI.

Apple is pushing SwiftUI heavily and the developer community is also impressed by SwiftUI. So SwiftUI will go the same way as Swift did: Yes, Objective-C is still a great programming language and alive, but Swift is THE language for iOS development. And the same will happen to SwiftUI as well. 

The doesn’t mean that you don’t need UIKit anymore! There are millions of apps in the App Store using UIKit and it doesn’t make sense to migrate existing code to SwiftUI. And sometimes it’s not even possible because the deployment target is lower than iOS 13.

Also, there are UIKit features, that are not yet available for SwiftUI, like collection views.

So if you wanna be a serious iOS developer, you have to be both an UIKit and SwiftUI expert.

References 

Title image: @  Vadym Sh / Shutterstock.com

Compared to many other programming languages, structs are very powerful in Swift. Hence, they should be used more often.

Hint: This post is using Swift 5

Similarities

First, let’s start by talking about the similarities between structs and classes. They actually have a lot in common:

• they have methods and initializers
• they have stored and computed properties
• they can be extended 
• they can implement protocols 

There are some differences how you use these features, but those are minor and are not the main part of this post. For example, initializers for structs are created automatically, whereas for classes you have to do that manually.

Differences

There are three main differences between structs and classes:

• Structs are value types, whereas classes are reference types. 
• Classes can be inherited. This is not possible for structs. 
• Objective-C interoperability for structs is very bad, whereas it’s very good for classes.

Let’s look at these differences in detail.

Value types vs reference types

So what is the difference between a value type and a reference type? An instance of a reference type cannot be accessed directly, but only by using a so-called reference. Therefore, multiply references can point to the same instance. Take a look at the following example:

class TestClassA {
    
    var a: Int
    
    init(a: Int) {
        self.a = a
    }
    
}

let testA = TestClassA(a: 5)
let testB = testA

print(testA.a) //5
print(testB.a) //5

testA.a = 10

print(testA.a) //10
print(testB.a) //10

As you can see, just one instance of TestClassA has been created, but two references are pointing to it. If you change the property a of testA, the same happens for testB because it’s the same instance.

Now let us look at a struct:

struct TestStruct {
    var a: Int
}

var testC = TestStruct(a: 5)
var testD = testC

print(testC.a) //5
print(testD.a) //5

testC.a = 10

print(testC.a) //10
print(testD.a) //5

Again, we have two values (testC and testD). If a property of one value gets changed, this doesn’t happen for the other one because it’s not the same instance.

Note also that testC and testD has to be declared as variable by using the keyword var. It is not possible to change a property of a struct, if the struct itself is a constant.

It’s exactly the same as with some Swift types, like Int, String and Array – they are also value types. But not only that, they are also structs!

The corresponding example to the one above with Int values:

var testE = 5
var testF = testE

print(testE) //5
print(testF) //5

testE = 10

print(testE) //10
print(testF) //5

If you haven’t worked with structs yet, the last example is probably much more natural for you. Just remind yourself that a struct works just as an Int value because an Int is a struct.

Reference types and value types behave quite differently. Imagine you have an instance of a reference type and you have multiple references pointing to it within your app. If you change the value by using one of these references, all of these references point to the same new value. This can be a wanted behavior. But if that’s not the case, this can be the source of major bugs. 

Because of the differences between value and reference types, memory management is quite different as well. The most important point is that so-called retain cycles can occur for reference types. That is not possible for value types. Take a look at this post for more details about this topic.

Objective-C interoperability 

Structs in Swift don’t have a good Objective-C interoperability. If you define a struct in Swift, you can’t expose it to Objective-C source code. That means for example that a delegate or datasource of UITableView must not be a struct but a class because UIKit is still written in Objective-C. This sounds like a major obstacle, but in reality these cases are rarer than you might think. 

Inheritance 

To make it short: There is no inheritance for structs. However, there are other ways to implement similar behaviour for structs. The most common way is using protocols. 

Use structs by default 

So the general guideline is that you should structs by default. The reason is that they are easier and safer to use: Retain cycles cannot occur and you cannot change the value for another part of the app by accident. 

Only if you need class specific features like inheritance, Objective-C interoperability, or you want the specific behaviour of a reference type, you should use classes. 

References 

Title image: @  Stepan Kapl / Shutterstock.com

There are two ways for testing the equality of class instances: reference equality and value equality. In this post we will discuss both of them.

Hint: This post is using Swift 4

The Identity Operator ===

By using the identity operator ===  you can compare the references pointing to the instances of a class. If these references are pointing to the same instance, the operator returns true. Take a look at the following example:

Class TestClassA { }

let test1 = TestClassA()
let test2 = TestClassA()
let test3 = test1

print("test1 and test2 pointing to the same instance: \(test1===test2)") //false
print("test1 and test3 pointing to the same instance: \(test1===test3)") //true

As you can see, test1 and test3 are pointing to the same instance, whereas test1 and test2 are not pointing to the same instance.

You can also check for inequality by using the !== operator:

print("test1 and test3 are not pointing to the same instances: \(test1!==test3)" //true

Note that the identity operator is not available for enums, structs and primitive data types. This makes sense because in these cases it’s not possible that two values are pointing to the same instance.

The equality operator ==

The equality operator on the other hand works differently. It compares whether two instances are equal. This doesn’t sound very concrete and in fact it’s not defined what that means. Instead, each class has to define what equality means for it. If the class doesn’t do this, it’s not possible to use the equality operator:

Class TestClassA { }

let test1 = TestClassA()
let test2 = TestClassA()

print("test1 is equal to test2 \(test1==test2)") //Compiler error

The last line produces a compiler error. Instead, you have to implement the Equatable protocol:

class TestClassA: Equatable {

     let a: Int

     init(a:Int) {
          self.a = a
     }

     public static func == (lhs: TestClassA, rhs: TestClassA) -> Bool {
          return lhs.a == rhs.a
     }

}

let test1 = TestClassA(a:5)
let test2 = TestClassA(a:6)
let test3 = TestClassA(a:5)

print("test1 is equal to test2 \(test1==test2)") //false
print("test1 is equal to test3 \(test1==test3)") //true

As you can see, in this example two instances of TestClass are equal if the properties a  are equal.

The comparable protocol

It’s not only possible to define the value equality for two instances of a class but an order as well. For that, you have to implement the Comparable protocol. It extends the Equatable protocol, so that the == function has to be implemented as explained in the last section. In addition, the < function also has to be implemented:

class TestClassA: Equatable, Comparable {

     let a: Int

     init(a:Int) {
          self.a = a
     }

     public static func < (lhs: TestClassA, rhs: TestClassA) -> Bool {
          return lhs.a < rhs.a
     }

     public static func == (lhs: TestClassA, rhs: TestClassA) -> Bool {
          return lhs.a == rhs.a
     }

}

let test1 = TestClassA(a:5)
let test2 = TestClassA(a:6)
let test3 = TestClassA(a:5)

print("test1 < test2 \(test1<test2)") //true
print("test1 < test3 \(test1<test3)") //false
print("test1 <= test3 \(test1<=test3)") //true
print("test1 > test3 \(test1>test2)") //false

As you can see, it’s very straight forward.

Title image: @ MShipphoto / shutterstock.com

I’ve been a full-time iOS developer for over 6 years now and I started learning iOS development 8 years ago. A lot has changed over the years. In this post I want to talk about the biggest changes I’ve experienced.

Swift

Obviously one of the biggest changes in iOS development over the last 8 years is the introduction of Swift at WWDC 2014. And for me it was the biggest surprises I’ve ever experienced watching an Apple event because there are was absolutely no leak beforehand. So Swift was a real surprise and for a developer it was just huge. Don’t get me wrong: Objective-C is a great language and there is still a lot of value in learning Objective-C, but in my opinion Swift is just better and now it’s the primary programming language for developing iOS apps.

Wherever there is light, there is shadow. So at the beginning there was also a lot of criticism about Swift. Compile times were very slow, the Xcode integration was not very good and there were a lot of code breaking changes with every new Swift version. And not all of these problems are solved yet. For example, there’s still no ABI stability (but it will come with Swift 5 hopefully) and I still have the impression that compile times are far away from being optimal.

But let’s face it: All the obstacles are worth it. Compared to the Objective-C times, iOS development has been become both easier and more powerful. And the most important part: It has become more fun.

Memory Management

When I began developing iOS apps, you still had to count references manually. If you haven’t witnessed that time, here’s a small overview:

By default, each reference, that points to an instance of a class, is a so-called strong reference. As long as there is at least one strong reference pointing to an instance, this instance will not be deallocated. When there’s no strong reference pointing to that instance left, the instance will be deallocated. These references have to be counted.

So far so easy. But before the introduction of ARC (Automatic Reference Counting), you had to do the counting manually by using code. Although it sounds simple, it was the root cause of many bugs. And debugging these bugs was even more difficult. But then ARC  has been introduced with Xcode 4.2 in October 2011. ARC is a compile time feature: It inserts the reference counting code automatically, so that you don’t have to deal with it anymore in most cases.

However, there are still situations, that ARC cannot handle correctly. In these situations a so-called retain cycles can occur. And here it’s an advantage if you have witnessed the manual reference counting time.  This is a very important topic and if you want to learn more about it, take a look at this blog post about retain cycles.

Auto Layout

Implementing a layout used to be very easy in the early days of iOS development because there was just one screen size (the iPhone). So you could just work pixel perfect. Over time though, there were more and more screen sizes like the iPhone 5, 6 and 6 plus and even different iPad sizes.  It was very clear that it was not possible to handle this with the with the original layout system.

So Apple introduced Auto Layout, which was already in use for Mac OS development. It’s very powerful but also a little bit complicated. With the introduction of the StackView and the possibility to mix Auto Layout and Autoresizing Masks, Apple took account of this. I used to assume that there will be another new layout system at some point, but meanwhile I do believe that Auto Layout is the best solution, especially if there are classes like StackView, that makes life much easier. By the way: In Android development there has been a constraint layout introduced as well.

Community

At the time of writing, there are 586,576 questions tagged with ‘iOS’ on Stack Overflow. In the list of the most used tags, this is place ten. There are also a lot of blogs, YouTube channels and Twitter accounts, that focus on iOS development. Also on GitHub there a lot of repositories concerning iOS development. So if you have a question or a problem, it’s very likely that you will find the answer very quickly. And even if that is not the case, you will probably find someone, who can help you. That is a very important aspect for choosing a platform you want to develop for because it makes your life much easier and you become much more productive as well.

When I started iOS development, there was of course already a community. However, it has grown massively since then, which makes a big difference.

Ecosystem

The iOS ecosystem has grown massively as well over the years: There are more than 1.3 billion active iOS devices out there, so that you as an iOS developer have access to one of the biggest and most important software markets in the world. iOS development used to be called a gimmick, but now it’s a serious business. And that holds not only true for the consumer market, but for the business market as well. Many companies have their own In-House iOS apps to support their business processes. 8 years ago the story was completely different. Sure, the iPhone was already a big success, but how big the ecosystem eventually would become was not predictable.

And now there is not only the iPhone, but the iPad and the Apple Watch as well. It’s quite interesting that the Apple Watch is not viewed as such a big success, but in fact it really is. And it’s still growing. Although the iPhone sales are stagnant at the moment, Apple’s service area (which includes for example the App Store, iTunes and iCloud) has been growing massively over the last years. This shows that the platform is very vibrant. And in my opinion this trend will not stop in the next years. iOS has come to stay.

Resources

Title Image: @ Sergey Tinjakov / shutterstock.com

Sets are one of Swift’s collection types. A set stores an amount of unique values, that have no particular order. You can imagine a set to be like a box of billiard balls: They are all unique in terms of color and number, but they don’t have a certain order inside the box.

Hint: This post is using Swift 4 and Xcode 10

[toc]

Creating sets

Creating a set is very straightforward:

let setA: Set<String> = ["a","b","c"]

In this example, a set called setA  of strings has been created. It stores the values a, b  and c. In contrast to an array, the elements are not ordered. By using type interference, the set can also be created like this:

let setB: Set = ["a","b","c"]

It’s also possible to use the initialiser of the set type:

let setC = Set(["a","b","c"])

Like an array, a set is not mutable, if it’s declared as a constant by using let. For mutable sets, you can use the keyword var:

var setD = Set(["a","b"])

We will learn more about mutable sets later on.

Accessing the values of a set

You can access the values of a set by using a loop:

for value in setA {
     print(value)
}

Note that the order of the values in the loop can be different every time you run the code. From the outside it looks like they the values are picked randomly.

Analysing sets

First of all, you can check whether a set is empty:

print(setA.isEmpty)

Also the number of elements of a set can be checked:

print(setA.count)

Both of these operations are also available for arrays. More typical for a set is the question, whether a certain element is a member of a set. For that, you can use the method contains:

print(setA.contains("a"))

Adding and removing values from a set

Mutable sets can be changed. You can add and remove values:

setD.insert("c")
setD.remove("a")

Since the values of a set are unique, a value can only be added once to the same set. The insert method can be called with the same values multiple times, but the set won’t change:

var setE: Set = [1,2,3,4]

setE.insert(5)
setE.insert(5)
setE.insert(5)

print(setE) //[4,5,1,2,3]

As before, the order of the output can be different every time you run the code since sets are not ordered.

Comparing sets

Sets can be compared. Obviously, comparing the equality of two sets is possible:

let setA: = [“a”, “b”, “c”]
let setB: = [“a”, “b”, “c”]

if setA == setB {
     print(“the sets are equal”)
}

In this case, the sets are equal.

There is no useful definition for a smaller and bigger comparison of two sets, but you can check whether a set is a subset of another set:

let intSetA: Set = [1,2,3,4,5,6,7,8,9,0]
let intSetB: Set = [1,2,3]
intSetB.isSubset(of: intSetA) //true

It’s also possible to check whether it’s a strict subset. In that case, it has to be a subset but must not be equal:

let intSetA: Set = [1,2,3,4,5,6,7,8,9,0]
let intSetB: Set = [1,2,3,4,5,6,7,8,9,0]
let intSetC: Set = [3,4,5]

intSetB.isSubset(of: intSetA) //true
intSetB.isStrictSubset(of: intSetA) //false
intSetC.isSubset(of: intSetA) // true
intSetC.isStrictSubset(of: intSetA) //true

The opposite principle is a superset:

let intSetA: Set = [1,2,3,4,5,6,7,8,9,0]
let intSetC: Set = [3,4,5]
intSetA.isSuperset(of: intSetC) //true
intSetA.isStrictSuperset(of: intSetC) //true

Two sets are disjoint, if they don’t have any element in common:

let intSetA: Set = [1,2,3,4,5,6,7,8,9,0]
let intSetC: Set = [3,4,5]
let intSetD: Set = [13,14,15]

intSetA.isDisjoint(with: intSetC) //false
intSetA.isDisjoint(with: intSetD) //true

Combining sets

You can combine two sets to create a new one. A union of two sets contains all elements from both sets:

let stringSetA: Set = ["a","b","c"]
let stringSetB: Set = ["c","d","e"]

let unionSetAB = stringSetA.union(stringSetB)
print(unionSetAB) //["d", "b", "c", "a", "e"]

An intersection on the other hand contains only the elements, that are in both sets:

let stringSetA: Set = ["a","b","c"]
let stringSetB: Set = ["c","d","e"]

let intersectionAB = stringSetA.intersection(stringSetB)
print(intersectionAB) //[“c”]

Using sets with custom types

Of course you can also store values of your own type in a set. This type could be for example a struct or a class. However, in order for the set to work properly, this type has to conform to the hashable protocol.

class Movie: Hashable {

     var title: String
     var year: Int

     init(title: String, year: Int) {
          self.title = title
          self.year = year
     }

     static func == (lhs: Movie, rhs: Movie) -> Bool {
          return lhs.title == rhs.title &&
          lhs.year == rhs.year
     }

     var hashValue: Int {
          return title.hashValue ^ year.hashValue
     }

}

let terminator = Movie(title: "Terminator", year: 1980)
let backToTheFuture = Movie(title: "Back to the Future", year: 1985)

let movieSetA: Set = [terminator,backToTheFuture]

References:

Title image: @ LaineN / shutterstock.com

MFMailComposeViewController provides an easy way to present a view controller, that allows to write, edit and send an email. It’s presented modally, so the context of the app won’t be left.

Hint: This post is using Swift 4 and iOS 9

Creating and presenting MFMailComposeViewController

It’s very easy. First, you have to import the MessageUI framework:

import MessageUI

Then, you just have to create an instance of MFMailComposeViewController, set some parameters and present it. The rest is taken care of by that controller.

if MFMailComposeViewController.canSendMail() {

     let mailComposeViewController = MFMailComposeViewController()
     mailComposeViewController.mailComposeDelegate = self
     mailComposeViewController.setToRecipients(["abc@abc.abc"])
     mailComposeViewController.setSubject("Subject")
     mailComposeViewController.setMessageBody("Hello!!!", isHTML: false)

     present(mailComposeViewController, animated: true, completion: nil)

}

The static canSendMail() method of MFMailComposeViewController is called to check if an email account is set up on the device. Note that this doesn’t include email accounts of third party apps like Gmail or Outlook.

It’s important to set the MFMailComposeViewControllerDelegate as well to handle the dismissal of the controller. There’s just one method to implement:

func mailComposeController(_ controller: MFMailComposeViewController, didFinishWith result: MFMailComposeResult, error: Error?) {

     controller.dismiss(animated: true, completion: nil)

}

It’s called when the user dismisses the controller, either by sending the email or canceling the action. Either way, you have to dismiss the controller manually.

Setting the recipients, subject and message body are the most obvious parameters you can set. However, it’s also possible to set CC and BCC recipients:

mailComposeViewController.setCcRecipients(["cc@cc.cc"])
mailComposeViewController.setBccRecipients(["bcc@bcc.bcc"])

It’s also possible to set an attachment:

if let image = UIImage(named: "Test"), let imageData = UIImageJPEGRepresentation(image, 1.0) {

     mailComposeViewController.addAttachmentData(imageData, mimeType: "image/jpeg", fileName: "Image.jpeg")

}

In this example, an image called Test.jpeg from the asset bundle gets attached to the email.

Open Mail app

There’s also another way to sent emails from an iOS app. Instead of presenting the MFMailComposeViewController, you can open the mail app:

if let url = URL(string: "mailto:abc@abc.abc") {

     UIApplication.shared.open(url, options: [:], completionHandler: nil)

}

There is also the possibility to use the UIActivityViewController. However, then the user can choose from different types of channels, not only email.

References

Title image: @ Andrey Bayda / shutterstock.com

There are two types of properties in Swift: stored properties and computed properties. Stored properties store values (constant or variable) as part of an instance or type, whereas computed properties don’t have a stored value.

Hint: This post has been updated to Swift 4 

[toc]

Video

Stored properties

Let’s start by looking at stored properties. Imagine you have a class named circle:

class Circle {
    
    var radius: Double = 0
    
}

let circle = Circle()
circle.radius = 10

print("radius: \(circle.radius)") //radius: 10.0

Circle has an instance variable called radius  with a default value of 0. In Swift, every instance variable is automatically a property. So now you have the possibility to add so called property observers. In Swift there a two types of property observers: One is called before the new value is assigned and the other one afterwards.

The property observer, which is called after the assignment, is marked with the keyword didSet. In our example, you can use it for example to check the new assigned value:

class Circle {
    
    var radius: Double = 0 {
        didSet {
            if radius < 0 {
                radius = oldValue
            }
        }
    }
    
}

let circle = Circle()

circle.radius = -10
print("radius: \(circle.radius)") //radius: 0.0

circle.radius = 10
print("radius: \(circle.radius)") //radius: 10.0

In the property observer you can access the old value of the property through the variable oldValue.

You can also use the property observer willSet, which is called before the new value is assigned:

class Circle {
    
    var radius: Double = 0 {
        willSet {
            print("About to assign the new value \(newValue)")
        }
        didSet {
            if radius < 0 {
                radius = oldValue
            }
        }
    }
    
}

let circle = Circle()

circle.radius = 10 //About to assign the new value 10.0

In willSet  you have access to the new value of the property through the variable newValue.

Computed Properties

Contrary to stored properties, computed properties don’t have a stored value. So each time you call a computed property, the value needs to be calculated. In the class Circle  you can define the property area as a computed property:

class Circle {
    
    var radius: Double = 0 {
        didSet {
            if radius < 0 {
                radius = oldValue
            }
        }
    }
    
    var area: Double {
        get {
            return radius * radius * Double.pi
        }
    }

}

let circle = Circle()
circle.radius = 5

print("area: \(circle.area)") //area: 78.5398163397448

A computed property always needs a getter. If it lacks a setter, the property is called a read-only property. In our example, there is a good application for a setter though:

import Foundation

class Circle {
    
    var radius: Double = 0 {
        didSet {
            if radius < 0 {
                radius = oldValue
            }
        }
    }
    
    var area: Double {
        get {
            return radius * radius * Double.pi
        }
        set(newArea) {
            radius = sqrt(newArea / Double.pi)
        }
    }
    
}

let circle = Circle()

circle.area = 25

print("radius: \(circle.radius)") //radius: 2.82094791773878

Now, after assigning a new value to area , radius  will be calculated.

Initilization of stored properties

Every stored property has to have a value after its instance has been created. There are two ways:

• initialize the value inside the init method
• set a default value for the property

The following example covers both cases:

class Circle {
    
    var radius: Double
    var identifier: Int = 0
    
    init(radius: Double) {
        self.radius = radius
    }
    
}

var circle = Circle(radius: 5)

If a stored property doesn’t have a value after its instance has been created, the code will not compile.

Lazy Properties

If a stored property with a default value is marked with the keyword lazy, its default value will not be initialized immediately, but when the property is called for the very first time.

So if the property gets never called, it will never be initialized. You could use this feature for example, if the initialization is expensive in terms of memory or CPU usage.

Let’s take a look at the following (very simple) example:

class TestClass {
    
    lazy var testString: String = "TestString"
    
}

let testClass = TestClass()
print(testClass.testString) //TestString

The property will not initalized until it gets accessed. In this example this is not very obivious though. But since the initialization can also happen inside a block, we can make it a little bit more obvious:

class TestClass {
    
    lazy var testString: String = {
        print("about to initialize the property")
        return "TestString"
    }()
    
}

let testClass = TestClass()
print("before first call")
print(testClass.testString)
print(testClass.testString)

The output of this example is:

before first call
about to initialize the property
TestString
TestString

So that means that the block is only called once – when the property is accessed for the very first time. Since this is stored property is variable, the initial value can be changed afterwards.

Type Properties

Type properties are part of an type but not of an instance – also know as static properties. Both stored and computed properties can be type properties. For that, you use the keyword static:

class TestClass {
    
    static var testString: String = "TestString"
    
}

print("\(TestClass.testString)") //TestString

As you can see, they are accessed by using the type name but not an instance. Furthermore, type properties always need a default value because there is not initialization.

Public Properties With Private Setters

As I’ve pointed out in more details in this post, it’s a common scenario that you don’t want to provide a public getter, but a private setter. This is a basic principle of encapsulation. By doing this, only the class itself can manipulate that property, but can still be accessed and read from outside of the class.

Take a look at the following example:

public class Circle {
    
    public private(set) var area: Double = 0
    public private(set) var diameter: Double = 0
    
    public var radius: Double {
        didSet {
            calculateFigures()
        }
    }
    
    public init(radius:Double) {
        self.radius = radius
        calculateFigures()
    }
    
    private func calculateFigures() {
        area = Double.pi * radius * radius
        diameter = 2 * Double.pi * radius
    }
}

let circle = Circle(radius: 5)

print("area: \(circle.area)") //area: 78.5398163397448
print("diameter: \(circle.diameter)") //diameter: 31.4159265358979

circle.area = 10 //Compiler Error: cannot assign to property: 'area' setter is inaccessible

Here the properties area and diameter can be read from outside of the class, but only be set inside the class. For that you have to use the combination public private(set). In my experience this feature is very rarely used in iOS development, but it’s very useful to create code, that has fewer bugs.

References

Title Image: @ Fabrik Bilder / shutterstock.com