NEW: Learn to build the incredible iOS 15 Weather app today! >>

< Back to Latest Articles

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

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!

Quick links

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:

  1. A Form wrapped in a NavigationView
  2. A TextField with a custom keyboard type.
  3. Pickers for converting from and to – I won’t use segmented controls here, because some of the conversion unit names are long.
  4. 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


Functional programming in Swift: Introduction

6:52

FUNCTIONAL PROGRAMMING

FREE: Functional programming in Swift: Introduction

Before you dive in to the first article in this course, I want to give you a brief overview of our goals, how the content is structured, as well as a rough idea of what you can expect to find.

Ultimate Portfolio App: Introduction

14:17

ULTIMATE PORTFOLIO APP

FREE: Ultimate Portfolio App: Introduction

While I’m sure you’re keen to get started programming immediately, please give me a few minutes to outline the goals of this course and explain why it’s different from other courses I’ve written.

Making your app accessible

33:12

ULTIMATE PORTFOLIO APP

FREE: Making your app accessible

It is my firm belief that every iOS app should be usable to everyone, and putting in the work to make your app function well no matter who is using it says a lot about the kind of developer you are.

How to use phantom types in Swift

24:11

ADVANCED SWIFT

FREE: How to use phantom types in Swift

Phantom types are a powerful way to give the Swift compiler extra information about our code so that it can stop us from making mistakes. In this article I’m going to explain how they work and why you’d want them, as well as providing lots of hands-on examples you can try.

Using memoization to speed up slow functions

36:18

HIGH-PERFORMANCE APPS

FREE: Using memoization to speed up slow functions

In this article you’ll learn how memoization can dramatically boost the performance of slow functions, and how easy Swift makes it thanks to its generics and closures.

Creating a WaveView to draw smooth waveforms

32:08

CUSTOM SWIFTUI COMPONENTS

FREE: Creating a WaveView to draw smooth waveforms

In this article I’m going to walk you through building a WaveView with SwiftUI, allowing us to create beautiful waveform-like effects to bring your user interface to life.

Understanding generics – part 1

20:01

INTERMEDIATE SWIFT

FREE: Understanding generics – part 1

Generics are one of the most powerful features of Swift, allowing us to write code once and reuse it in many ways. In this article we’ll explore how they work, why adding constraints actually helps us write more code, and how generics help solve one of the biggest problems in Swift.

User-friendly network access

14:26

NETWORKING

FREE: User-friendly network access

Anyone can write Swift code to fetch network data, but much harder is knowing how to write code to do it respectfully. In this article we’ll look at building a considerate network stack, taking into account the user’s connection, preferences, and more.

Transforming data with map()

42:32

FUNCTIONAL PROGRAMMING

FREE: Transforming data with map()

In this article we’re going to look at the map() function, which transforms one thing into another thing. Along the way we’ll also be exploring some core concepts of functional programming, so if you read no other articles in this course at least read this one!

Shadows and glows

19:50

SWIFTUI SPECIAL EFFECTS

FREE: Shadows and glows

SwiftUI gives us a modifier to make simple shadows, but if you want something more advanced such as inner shadows or glows, you need to do extra work. In this article I’ll show you how to get both those effects and more in a customizable, flexible way.

Understanding assertions

27:33

INTERMEDIATE SWIFT

FREE: Understanding assertions

Assertions allow us to have Swift silently check the state of our program at runtime, but if you want to get them right you need to understand some intricacies. In this article I’ll walk you through the five ways we can make assertions in Swift, and provide clear advice on which to use and when.

Trees

31:55

DATA STRUCTURES

FREE: Trees

Trees are an extraordinarily simple, extraordinarily useful data type, and in this article we’ll make a complete tree data type using Swift in just a few minutes. But rather than just stop there, we’re going to do something quite beautiful that I hope will blow your mind while teaching you something useful.

Creating a custom property wrapper using DynamicProperty

14:20

INTERMEDIATE SWIFTUI

FREE: Creating a custom property wrapper using DynamicProperty

It’s not hard to make a basic property wrapper, but if you want one that automatically updates the body property like @State you need to do some extra work. In this article I’ll show you exactly how it’s done, as we build a property wrapper capable of reading and writing documents from our app’s container.

Making the most of optionals

23:07

ADVANCED SWIFT

FREE: Making the most of optionals

Swift’s optionals are implemented as simple enums, with just a little compiler magic sprinkled around as syntactic sugar. However, they do much more than people realize, and in this article I’m going to demonstrate some of their power features that can really help you write better code – and blow your mind along the way.

Creating chained network requests with Combine

18:36

NETWORKING

Creating chained network requests with Combine

We already looked at how to fetch decodable data using Combine, and also how to fetch and merge multiple sources of data. In this article we’ll tackle something even more complex: creating chained network requests, where the information retrieved from one request must be used to create multiple other requests.

Creating a particle system in SwiftUI

56:53

SWIFTUI SPECIAL EFFECTS

Creating a particle system in SwiftUI

Particle systems let us create special effects such as confetti, fire, smoke, rain, and snow, all by adjusting a range of inputs. In this article we’re going to build our own particle system entirely driven by SwiftUI, so you can easily add some sparkle to your apps.

Flood fill path finding

30:31

ALGORITHMS

Flood fill path finding

The flood fill approach to path finding is one of the easiest to learn, works great in games with small maps, and is also commonly used in software – filling a picture with color, for example. In this article I’ll walk you through how the algorithm works, and help you build a visual representation of it in action.

Implementing App Clips in a real app

1:01:00

HACKING WITH SWIFT LIVE 2020

Implementing App Clips in a real app

Now that you understand how App Clips work, in this part we’ll apply them to our Barking Lot app so you can see them in action with real code.

Questions and answers, part 1

24:31

ULTIMATE PORTFOLIO APP

Questions and answers, part 1

As folks have worked their way through the series so far, they’ve sent in various questions about implementation choices and more. In this article I want to address the eight most common questions asked so far, so that everyone can benefit.

Creating a TabbedSidebar that handles both tab view and sidebar

14:39

INTERMEDIATE SWIFTUI

Creating a TabbedSidebar that handles both tab view and sidebar

If you want your app to work well on larger devices, you need to support both a sidebar and a tab bar for your primary navigation. In this video I’ll show you how to build one simple SwiftUI component that transitions between both smoothly.

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.