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!
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…
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:
Form
wrapped in a NavigationView
TextField
with a custom keyboard type.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.
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")
}
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…
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?
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!
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
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Getting ready for a job interview is tough work, so I’ve prepared a whole bunch of common questions and answers to help give you a jump start. But before you get into them, let me explain the plan in more detail…
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.
In this article we’re going to build an app to track how much water the user has consumed today, then tie it into a widget so they place a gentle reminder right on their Home Screen.
In part one of this tutorial we looked at how to customize string interpolations on a type-by-type basis, giving you more control over how your code works. In this second part we’ll look at a second powerful use for interpolation: building whole types from scratch.
Checkpoint 3 of Swift for Complete Beginners asks you to tackle the classic FizzBuzz problem, printing Fizz, Buzz, FizzBuzz, or a number depending on the input. Let’s solve that now…
For our last topic, we’re going to explore widgets. iOS has had widget-like behavior for some time through its Today extensions, but in iOS 14 they gained a lot more functionality.
Rather than calling update()
when our view disappears, what we really want to do is update the object before the disappear happens. In this article I’ll show you the SwiftUI native way of doing this, then walk you through an alternative that I prefer.
Link copied to your pasteboard.