NEW: Learn to build amazing SwiftUI apps for macOS with my new book! >>

Challenge 1: Converter

This early challenge day asks you to build a converter app that’s able to move between any two similar units, such as kilometers and miles. Let’s solve it now, then we’ll take it further, and then we’ll take it even further…

This is a free sample from Hacking with Swift+, a subscription that delivers high-quality tutorials as both articles and videos. Click here to find out more >

Watch the video here, or read the article below

There are three downloads for this project:

You do not need to go anywhere beyond the simple project in order to have successfully completed this challenge – the other two are just bonus learning material and fun exploration!

Remember: keep it simple

As this is the very first challenge project, I gave you some really important advice straight up: keep it simple! The goal of this early challenge is to get you writing your own code, because in doing so you’ll quickly realize which parts you weren’t sure about

So, if you worked through the challenge and thought “wow, my solution sucks” please stop – if you solved, I don’t care how messy your code is, how many weird workarounds you had to put in, or how many wrong turns you took along the way: if you hit Run in Xcode and your code works correctly, you did an amazing job and I hope you feel proud!

If you have yet to try the challenge I recommend you do so now, before continuing. I know it feel might intimidating facing an empty Xcode project, but you’ll learn by trying!

You can find the original challenge here. The abridged version is that you need to create an app where users can enter a number, then select units to convert from and to, and finally display the output.

Let’s tackle it now…

Starting with data

Start by creating a new App project targeting iOS 15 – I’m not going to be terribly original, so I’ll call mine “Converter”.

In ContentView.swift, we’re going to start by laying down the three core properties of this app: one to store the user’s input, one to store the input unit, and another to store the target unit that we’re converting to. Add these three to ContentView now:

@State private var input = 100.0
@State private var inputUnit = "Meters"
@State private var outputUnit = "Kilometers"

You’ll notice I’m using strings for the input and output units, which is perfectly fine to start with.

We need to match those units up with an array of possible options, which we can store as a fourth property. This doesn’t need to be mutable, so a simple constant is enough:

let units = ["Feet", "Kilometers", "Meters", "Miles", "Yards"]

Now we can write the first pass at our UI. We haven’t done the actual work of conversion yet, but we can still build the rest of the app because it’s so similar to the way WeSplit worked:

A Form wrapped in a NavigationView
A TextField with a custom keyboard type.
Pickers for converting from and to – I won’t use segmented controls here, because some of the conversion unit names are long.
A section at the end to show the final conversion value; this will just be a placeholder for now.

So, replace your existing body with this:

NavigationView {
    Form {
        Section {
            TextField("Amount", value: $input, format: .number)
                .keyboardType(.decimalPad)
        } header: {
            Text("Amount to convert")
        }

        Picker("Convert from", selection: $inputUnit) {
            ForEach(units, id: \.self) {
                Text($0)
            }
        }

        Picker("Convert to", selection: $outputUnit) {
            ForEach(units, id: \.self) {
                Text($0)
            }
        }

        Section {
            Text("???")
        } header: {
            Text("Result")
        }
    }
    .navigationTitle("Converter")
}

Hopefully there’s nothing in there that was too hard – it’s almost a carbon copy of WeSplit, after all. But that’s the point: it’s forcing you to remember the things you learned along the way, so if you do find yourself thinking “how do I make a picker again?” then it’s your chance to relearn it.

Simplifying conversions

The most important part of this app is the actual process of conversion, which means writing code to convert from any input unit to any output unit.

If you try and approach this as a many-to-many problem – converting every input to every output – you’ll just create a whole bunch of work for yourself. So, a better idea is to convert the input unit to a common reference point, such as meters, then convert from that to the output unit.

This takes a small amount of code, but really most of it is just inputting conversions from one value to another – I just looked these up on Google, so if you decided to do different conversions in your app you can just replace mine with your own values.

Just like with WeSplit, we can do the work of our conversion inside a computed property, so add this now:

var result: String {
    let inputToMetersMultiplier: Double
    let metersToOutputMultiplier: Double

    switch inputUnit {
    case "Feet":
        inputToMetersMultiplier = 0.3048
    case "Kilometers":
        inputToMetersMultiplier = 1000
    case "Miles":
        inputToMetersMultiplier = 1609.34
    case "Yards":
        inputToMetersMultiplier = 0.9144
    default:
        inputToMetersMultiplier = 1.0
    }

    switch outputUnit {
    case "Feet":
        metersToOutputMultiplier = 3.28084
    case "Kilometers":
        metersToOutputMultiplier = 0.001
    case "Miles":
        metersToOutputMultiplier = 0.000621371
    case "Yards":
        metersToOutputMultiplier = 1.09361
    default:
        metersToOutputMultiplier = 1.0
    }

    let inputInMeters = input * inputToMetersMultiplier
    let output = inputInMeters * metersToOutputMultiplier

    let outputString = output.formatted()
    return "\(outputString) \(outputUnit.lowercased())"
}

As you can see, I’m converting everything to meters first, then from meters back up to everything else.

I also snuck in a useful method right near the end: calling formatted() on a Double will make it human-readable by adding thousands separators and trimming off unnecessary numbers after the decimal point.

We can put that to use straight away by replacing our “???” placeholder text with the correct result:

Section {
    Text(result)
} header: {
    Text("Result")
}

Dismissing the keyboard

To finish up our simple implementation we need to make sure the keyboard can be dismissed, otherwise we’ll same the face annoyance that WeSplit originally had.

To do this, we need to add a new @FocusState property to track whether the input field is focused:

@FocusState private var inputIsFocused: Bool

We can then attach that to the text field with the focused() modifier:

.focused($inputIsFocused)

Last but not least, we need to add a keyboard toolbar to hide the keyboard as needed, so add this below the navigationTitle() modifier:

.toolbar {
    ToolbarItemGroup(placement: .keyboard) {
        Spacer()

        Button("Done") {
            inputIsFocused = false
        }
    }
}

And that’s our implementation complete! It definitely keeps things simple, which is the point at this early stage in your coding career.

Can we do better? We certainly can…

A bigger, better solution

This challenge was designed to be achievable given what you know after WeSplit, but what if we wanted to go further – what if we could push past the boundaries of WeSplit and bring in some new code to make this whole app better?

Well, with only a small amount more work we can adopt APIs built into iOS that handle conversion, so this is a great chance to learn something new. Plus, as you’ll see the end result is significantly less code because Apple is doing all the conversion for us.

First, we need to ditch our two string properties that store the input and output units, and replace them with specific unit values, like this:

@State private var inputUnit = UnitLength.meters
@State private var outputUnit = UnitLength.kilometers

We also want to replace the string array to use all the constants we care about, like this:

let units: [UnitLength] = [.feet, .kilometers, .meters, .miles, .yards]

Tip: These new unit lengths come in a huge range of values including .astronomicalUnits, .furlongs, and .parsecs – because we didn’t use a segmented control, it’s possible to add many more so that our app handles all meaningful lengths.

Each of those UnitLength values we’re using can print out its symbol on demand – that’s things like “m” for meters, or “yd” for yards. However, that’s not very user friendly, so we need to request that they be formatted using a long style so that words are spelled out in full.

This isn’t hard to do, because Apple gives us a MeasurementFormatter class specifically for this, and that can be configured to return measurements in whatever length we want.

However, Apple also does something really clever that actually kind of gets in the way here: it automatically adjusts measurements based on the user’s preferences. This is fantastic for situations where you want to say “walk 100 meters forward”, because if the user prefers imperial measurements then MeasurementFormatter will silently convert that to “walk 110 yards forward”. Here, though, we specifically don’t want that because it would rather defeat the purpose of our program if the output units were ignored!

The fix for this is simple, because MeasurementFormatter has a property to override that behavior. So, please add this property now:

let formatter: MeasurementFormatter

We need to create and configure inside our view, so add this new initializer for our struct:

init() {
    formatter = MeasurementFormatter()
    formatter.unitOptions = .providedUnit
    formatter.unitStyle = .long
}

So far this might seem like more work than it’s worth, but here’s the kicker: we can now remove almost all the code from our result property, and have iOS do all the conversion and formatting for us.

You see, if we combine our input unit with the user’s number, we get a Measurement, and measurements come with a convert(to:) method that does exactly what we want. We can then pass the result through our new formatter property to get it formatted exactly correctly for our purposes.

So, replace result with this:

var result: String {
    let inputMeasurement = Measurement(value: input, unit: inputUnit)
    let outputMeasurement = inputMeasurement.converted(to: outputUnit)
    return formatter.string(from: outputMeasurement)
}

Now let’s look at our SwiftUI code. We can still loop over units using id: \.self, but we need to make sure we pass each item through our formatter so we get nice text like “kilometers” and “meters” rather than “km” and “m”. To take it one step further, we can also use the capitalized property of the resulting string, so that we get “Kilometers” and “Miles”, which reads better here.

So, we can replace the two pickers with this:

Picker("Convert from", selection: $inputUnit) {
    ForEach(units, id: \.self) {
        Text(formatter.string(from: $0).capitalized)
    }
}

Picker("Convert to", selection: $outputUnit) {
    ForEach(units, id: \.self) {
        Text(formatter.string(from: $0).capitalized)
    }
}

And now our app is done – and it’s a huge improvement too.

Yes, we removed a lot of code. And yes, we can go ahead and add a whole bunch more unit lengths now, choosing from the full range supported by iOS. But there’s another hidden benefit: if you choose to have your app translated in the future, all those measurement strings like “kilometers” and such will get translated automatically.

So we’re done, right?

Well… what if we could do even better?

Convert everything!

We’ve built a pretty neat length converter app so far, but with another step forward we can upgrade this to convert everything – temperature, mass, volume, energy, and more. This will mean learning a few new things, but that’s what you’re here for, right?

We’re going to start by adding two new array properties to ContentView: one to store the list of conversion types – distance, mass, etc – and one to store all the possible conversions inside those types.

The first of those is nice and easy:

let conversions = ["Distance", "Mass", "Temperature", "Time"]

The second is a little more complex, because we need to store what’s called a two-dimensional array – an array of arrays. We want to work with several different conversion types, and each conversion type is an array of its conversion units – meters, kilometers, and so on.

So, our second property is a two-dimensional array, with the conversion types in the same order as the conversions array above. Add this now:

let unitTypes = [
    [UnitLength.meters, UnitLength.kilometers, UnitLength.feet, UnitLength.yards, UnitLength.miles],
    [UnitMass.grams, UnitMass.kilograms, UnitMass.ounces, UnitMass.pounds],
    [UnitTemperature.celsius, UnitTemperature.fahrenheit, UnitTemperature.kelvin],
    [UnitDuration.hours, UnitDuration.minutes, UnitDuration.seconds]
]

That replaces our old units array, so please delete that.

While we’re up here in the properties, there’s another change we need to make: inputUnit and outputUnit are both given default values of some UnitLength, and so Swift considers the type of those to be UnitLength. That worked great before when we only had lengths, but now we have mass, temperature, and duration any more, so what type should these properties be?

Well, Apple designed this system to be flexible: all our unit types – UnitLength, UnitDuration and so on – are actually subclasses of another class called Dimension. This means if we tell Swift that inputUnit and outputUnit are both dimensions rather than unit lengths, they can be changed over to be whatever we need in the future.

All this takes is adding a type annotation to both properties, like this:

@State private var inputUnit: Dimension = UnitLength.meters
@State private var outputUnit: Dimension = UnitLength.yards

Now we need to tackle selecting which units to use. We already have the array of arrays, so the easiest thing to do is store an integer index into that array of arrays that determines which conversion type we want – a value of 0 would mean we’re converting distances, a value of 1 would be mass, and so on.

Add this new property now:

@State var selectedUnits = 0

Last but not least, we need to update our pickers, partly to add a new one to control which conversion type we want to do, and partly also to make sure the From and To pickers both read into the unitTypes array.

Adding the new picker can be done using a ForEach that counts from 0 up to the number of conversions in our array – we need to use an integer here, because selectedUnits is an integer. As for the other two, this is almost the same except they need to use unitTypes and selectedUnits together to figure out which unit array to loop over.

Here are the new pickers:

Picker("Conversion", selection: $selectedUnits) {
    ForEach(0..<conversions.count) {
        Text(conversions[$0])
    }
}

Picker("Convert from", selection: $inputUnit) {
    ForEach(unitTypes[selectedUnits], id: \.self) {
        Text(formatter.string(from: $0).capitalized)
    }
}

Picker("Convert to", selection: $outputUnit) {
    ForEach(unitTypes[selectedUnits], id: \.self) {
        Text(formatter.string(from: $0).capitalized)
    }
}

I recommend you try running the app at this point, because it’s pretty good – not perfect, but pretty good. Yes, we can jump around between conversions now, which is a huge improvement, but we also get stuck in a rather odd state: if we select Meters and Kilometers for our conversion, then change to Temperature and select Celsius in place of miles, our effect is trying to convert Miles to Celsius.

Now, clearly such a conversion is nonsense, and our app just silently fails rather than throwing up some large error, but it’s still far from ideal.

To fix this, I want to introduce you to a new modifier called onChange(), which runs a closure of our choosing whenever a particular value changes. In our case that means we can watch selectedUnits for changes, and when it does change set both inputUnit and outputUnit to sensible defaults from whatever is the new conversion type.

This only takes a few lines of code – add this below the existing toolbar() modifier:

.onChange(of: selectedUnits) { newSelection in
    let units = unitTypes[newSelection]
    inputUnit = units[0]
    outputUnit = units[1]
}

And now I think the app is perfect: multiple conversion types, each of which have multiple conversion units, and we can add more of both in no time at all!

If you liked this, you'd love Hacking with Swift+…

Here's just a sample of the other tutorials, with each one coming as an article to read and as a 4K Ultra HD video.

Find out more and subscribe here