@FocusState private var campaignTitleIsFocussed: Bool

TextField("New Campaign", text: $campaign.name, axis: .vertical)
    .focused($campaignTitleIsFocussed)
    .onChange(of: campaign.name) { newValue in
        guard let newValueLastChar = newValue.last else { return }
        if newValueLastChar == "\n" {
            campaign.name.removeLast()
            campaignTitleIsFocussed = false
        }
    }

How does it work?

Well, any time a new character is typed, we check to see if its a newline — user has tapped the "return" key. This appends a \n to the end of the string. We then remove this newline, and set the focus for that TextField to false.

Easy Peasy.

To do this, we'll need to do some stress testing, so let's meet our competitiors.

Atom

It calls itself "A hackable text editor for the 21st century". Up until recently, this was my text editor of choice. Free and open source. It's only downside? Electron. It's not as light weight as I like in a text editor. These things should be speedy, with just enough features to get the job done. If I wanted something bloated, I would just use Xcode.

Now I'm not saying Atom is bloated. Absolutely not. In fact most of the text editors on this list are perfectly fine. It's just that, because Electron, you've already used up about 300mb of ram for just launching the app in an empty state. With no files loaded.

BBEdit

This is a popular choice for a lot of people and has been around for a very long time (like since the early 90s?). It's THE standard for which all editors should be compared.

Written in C, so it's a native app, and super light weight.

It's not free though, but very well priced. I also don't own this app myself so I used the trial version for my tests.

Sublime Text

I have used this app for many years. This was my number 1 text editor for a long time, and I'm sure that's the same for many other developers out there.

Nova

This is a fairly new text editor released by the same people who created Coda. Coda has been around for a long time, and was a great little editor you could use on iOS, mostly focussing on web development.

I've been using nova for a little while now and not entirely sure how I feel about it. It has replaced Sublime Text and Atom for most tasks, but I'm still working things out, and settling into a workflow that works for me.

Plus, it just looks really cool, if not a little distracting.

MacVim

Honestly? I've never used it since before writing this article. Vim isn't something that is ever even mentioned in iOS development. All we really need a text editor for is opening a few config, script, or JSON files and that's about it.

Vim has been around for a very long time (similar age to BBEdit?). But, this app was very performant, and I can certainly see the appeal, but it's just not for me.

Xcode

We all know Xcode. I'm not even going to bother with a screenshot here. This thing is a bloated mess. If you already have it open, and the text file you're editing is part of your project, then go for it.

However, for any smaller quick tasks, you could probably finish the job in any other editor before Xcode even opens.

TextEdit

Built into macOS this editor is just plain fine. It works. No syntax highlighting, or code completion. No addons. Just plain and simple.

I've known a lot of web developers who use this, day to day, and nothing else. How? I have no idea.

Hex Fiend

This app will open anything. Instantly. Full stop. Is this the best for opening large files?

Maybe.

Results

I know you skipped past everything just to get to this point, and that's okay. I would have done that too, and honestly, you didn't miss much.

What you will need to know though is that I ran these tests on a 2018 Mac mini, 3.2 Intel Core i7, with 32GB of RAM and an external RX 580 GPU. So take the times and usability with a big grain of salt. This is by no means scientific, and you computer may have a better time with this than mine.

This is the script I used to generate the 10GB file I used for testing. (Thanks to Bare Bones Software for helping me out on this). It came out to around 11GB in total. Line breaks every 100 characters, and ASCII text only.

export LC_ALL=C; dd if=/dev/urandom bs=1000000000 count=30 | tr -dc 'A-Za-z0-9!"#$%&'\''()*+,-./:;<=>?@[\]^_`{|}~' | fold -s -w 100 > ~/Desktop/10GB_text.txt

| App | Can Open | Time | Usable |
|---|---|---|---|---|
| Atom | ❌ | failed at 2min 48sec | N/A |
| BBEdit | ✅ | 9min 52sec | ❌ |
| Sublime Text | ❌ | 1hr 13min 24sec | N/A |
| Nova | ✅ | 10min 18sec | ❌ |
| MacVim | ✅ | 33sec | ❌ |
| Xcode | ✅ | 17min 57sec | ❌ |
| TextEdit | ❌ | N/A | ❌ |
| Hex Fiend | ✅ | Too fast to count | ✅ |

I... don't really have anything else to say about it. The results speak for themselves.
Is this useful? Maybe to someone out there.

What do I think?

The need for opening large files like this is rare. It's more likely you'll want to open a 1GB log file than a 10GB one. In those cases, speed does matter, and what I'd love to see is a compatibility mode built in to most text editors that will open up these larger files in the same way as Hex Fiend, without syntax highlighting or parsing.

Keep using your favorite editor, but install Hex Fiend as a nice little backup for those tricky files, even corrupt ones!

True, SwiftUI is all done in code and includes a neat way to preview your layouts, but I feel that it's not quite ready for primetime just yet. So what can we do?

Unfortuneately Xcode no longer allows you to setup a project without either of these options. If we want to go full programatic, handle segues, animations and wrestle with autolayout manually, we'll have to choose an option and modify it to our use case.

I'll run through getting setup with a new project, modifying it for programatic UI development, show you how to arrange a few views and navigate to other controllers.

New Project

You can skip the next two sections by downloading this Xcode template that will handle all of this for you.

1. We'll get started by creating a new iOS project using the single view template.

2. In the next step create a name for your project and make sure that you have the Storyboard option selected in the dropdown. Don't worry, we'll be deleting it anyway.

3. On the final, choose a save location, and for this guide we won't worry about setting up git, so you can uncheck that box.

Your Project

1. Next you'll be presented with the main Xcode interface, with the project settings displayed in the center of the window. On the left of the screen you should see the project navigator:

2. Delete Main.storyboard from within the project navigator.

3. In the project settings, delete the text inside Main Interface

4. Click on the Info tab, open up Application Scene Manifest row and find the line with Storyboard Name. Delete this row, and change Enable Multiple Windows value from NO to YES.

5. Open up SceneDelegate.swift and replace the code inside the willConnectTo function with the following:

guard let windowScene = (scene as? UIWindowScene) else { return }

window = UIWindow(frame: UIScreen.main.bounds)
window?.windowScene = windowScene

let navC = UINavigationController(rootViewController: ViewController())
window?.rootViewController = navC
window?.makeKeyAndVisible()

If you run your app now, you should see a black screen.

Layout Out Views

1. Open up ViewController.swift and create a new UIButton at the top of the class.

let button = UIButton()

Notice how there's no @IBOutlet or a weak reference. @IBOutlet is what links the button to a storyboard or xib file. Usually with storyboards, it's the view that has a strong reference, which is why we give the view controller a weak one. Since this button has been created entirely within the view controller, we give it a strong reference. There's loads of articles out there explaining the differences between strong and weak references. Hit up google you'd like to know more.

2. Inside the viewDidLoad function we'll add the button as a subview and setup a few constraints.

override func viewDidLoad() {
    super.viewDidLoad()

    button.setTitle("Next View", for: .normal)
    view.addSubview(button)
    button.translatesAutoresizingMaskIntoConstraints = false

    button.centerYAnchor.constraint(equalTo: view.centerYAnchor).isActive = true
    button.centerXAnchor.constraint(equalTo: view.centerXAnchor).isActive = true
}

In my own personal projects I use a library called SnapKit for doing the contraints. It produces code that's easier to read and less verbose. Another reason is that it handles the isActive states and translatesAutoresizingMaskIntoConstraints flag for me. This is good, because I always forget to set them, and find myself wondering why my layouts aren't working.

When doing your layouts in code, be sure to always add your subview to it's superview before settings up constraints. Otherwise your app will crash at runtime because the view won't have anything to constrain itself to.

Run your app and you'll see your button in the middle of the screen.

Navigation

1. Next we'll setup an action on the button so that we can load another view controller when the user taps it. Place this code just after the last constraint.

button.addTarget(self, action: #selector(nextVC), for: .touchUpInside)

4. Now we have an error. Let's fix this by creating the nextVC function.

@objc func nextVC() {
    let nextVC = UIViewController()
    navigationController?.pushViewController(nextVC, animated: true)
}

This code creates a new view controller and pushes it onto the navigation controllers stack of view controllers. In this example we're just using a UIViewController() but you can replace that with any view controller subclass you like.

Notice how navigationController is an optional. This is a property on ViewController, if ViewController were to not be embedded withing a UINavigationController, this property would be nil and the push wouldn't work.

If you're not using navigation controllers, you can replace this line with the present(animated:completion:) which will popup the next view controller as a modal. The biggest benifit of using navigation controllers is that you don't have to worry about creating back buttons or title bars as this is all handled for you.

Launch your app and try it out!

Sharing Information

Great, we can now launch another controller, but let's customize before pushing it to the viewer.

1. We'll modify nextVC() to generate a random background color for our new view controllers view.

@objc func nextVC() {
    let colors: [UIColor] = [.red, .blue, .yellow, .green, .white, .cyan, .orange]
    let randomColor = colors.randomElement()

    let nextVC = UIViewController()
    nextVC.view.backgroundColor = randomColor
    navigationController?.pushViewController(nextVC, animated: true)
}

Launch the app again and tap on the Next View button...

Tap the back button and tap on the Next View button again... you should see a different color this time. Pretty cool huh?

That's it for this post. You can grab the code for this project from my github here.

Recently, I was having issues with performing tests over the closed network we have at work. While our development Macs have access to the internet, our CI box does not (don’t ask me why).

Turns out there’s a whole bunch of reasons for why you don’t actually wantyour CI boxes running tests over a network anyway.

For starters, you shouldn’t be testing someone else’s code. Servers can go down, and APIs can change. Your backend devs should already have this covered in their own tests, and if they don’t, then you have bigger problems.

What about when you want your network calls to fail? How do you do that reliably? If your request returns mangled data, you’ll need to make sure your app can handle it elegantly, rather than just straight up crashing.

NSURLSession

The obvious place to start would be having a way for us to fake our network calls. Overriding a few functions in NSURLSession and NSURLSessionDataTask should just about do it.

This is a great little snippet that you can just copy/paste into any project. Throw it in the test bundle so you’re not shipping it with the rest of your code.

class MockSession: URLSession {
    
    var completionHandler: ((Data, URLResponse, Error) -> Void)?
    static var mockResponse: (data: Data?, URLResponse: URLResponse?, error: Error?)

    override class var shared: URLSession {
        return MockSession()
    }
    
    override func dataTask(with request: URLRequest, completionHandler: @escaping (Data?, URLResponse?, Error?) -> Void) -> URLSessionDataTask {
        self.completionHandler = completionHandler
        return MockTask(response: MockSession.mockResponse, completionHandler: completionHandler)
    }
    
}

class MockTask: URLSessionDataTask {
    
    typealias Response = (data: Data?, URLResponse: URLResponse?, error: Error?)
    var mockResponse: Response
    let completionHandler: ((Data?, URLResponse?, Error?) -> Void)?
    
    init(response: Response, completionHandler: ((Data?, URLResponse?, Error?) -> Void)?) {
        self.mockResponse = response
        self.completionHandler = completionHandler
    }
    
    override func resume() {
        completionHandler!(mockResponse.data, mockResponse.URLResponse, mockResponse.error)
    }
}

Admittedly it looks a little weird, but what we’re essentially doing is overriding dataTaskWithRequest returning a fake task, where resume() is also overridden, which is what gives us back our fake response — that we will create in the next step — through the completion handler. Does that make sense?

Maybe an example of how to use it will help.

Unit Testing

So lets say we need to fetch a bunch of products, something we might want customers to buy through our app.

Products are added/removed all the time, so testing on real data would be an issue. Instead, we can create our own response and pass that into our mockResponse property on our MockSession — NSURLSession subclass. This way we have a consistent local datasource to test that our objects are being created correctly.

func testRetrieveProductsValidResponse() {
    // we have a locally stored product list in JSON format to test against.
    let testBundle = Bundle(forClass: type(of: self))
    let filepath = testBundle.pathForResource("products", ofType: "txt")
    let data = Data(contentsOfFile: filepath!)
    let urlResponse = HTTPURLResponse(url: URL(string: "https://anyurl.doesntmatter.com")!, statusCode: 200, httpVersion: nil, headerFields: nil)
    // setup our mock response with the above data and fake response.
    MockSession.mockResponse = (data, urlResponse: urlResponse, error: nil)
    let requestsClass = RequestManager()
    // All our network calls are in here.
    requestsClass.Session = MockSession.self
    // Replace NSURLSession with our own MockSession.
    // We still need to test as if it's asynchronous. Because well, it is.
    let expectation = XCTestExpectation(description: "ready")
    // For this test, no need to pass in anything useful since it doesn't affect our mocked response.
    // This particular function fetches JSON, converts it to custom objects, and returns them.
    requestsClass.retrieveProducts("N/A", products: { (products) -> () in
        XCTAssertTrue(products.count == 7)
        expectation.fulfill()
    }) { (error) -> () in
        XCTAssertFalse(error == Errors.NetworkError, "Its a network error")
        XCTAssertFalse(error == Errors.ParseError, "Its a parsing error")
        XCTFail("Error not covered by previous asserts.")
        expectation.fulfill()
    }
    waitForExpectations(timeout: 3.0, handler: nil)
}

Thats about it!

If you haven't already, you'll want to check out part 2 before continuing with this chapter.

Game Rules

We now have cells populating the world, but they’re currently frozen in time. They’re born, but then nothing happens. We’ll need a way to step the world forward and apply the game rules.

Go back to World.swift and create a new function called updateCells(). Inside this function, we’ll create a new temporary array that will hold our updated cells, along with an array of live cells.

var updatedCells = [Cell]()
let liveCells = cells.filter { $0.state == .alive }

for cell in cells {

}

cells = updatedCells

We’ll be using liveCells to find the living neighbors of each cell in the loop. Filtering out dead cells early on means that we don’t have to waste resources looping over them.

So inside the for loop, we’ll grab the living neighbors using the function on Cell that we wrote earlier.

let livingNeighbors = liveCells.filter { $0.isNeighbor(to: cell) }

Then we’re going to add a switch statement. This is where we’ll apply our rules. The simplest way is to break up them up into three steps, even though there are four rules. Here they are again.

1. Any live cell with fewer than two live neighbors will die.
2. Any live cell with two or three live neighbors will live on to the next generation.
3. Any live cell with more than three live neighbors will die.
4. Any dead cell with exactly three live neighbors will become a live cell.

So if the cell is alive, and its number of live neighbors is two or three, it lives on otherwise it dies. So let’s do that first, still inside the for loop.

switch livingNeighbors.count {
case 2...3 where cell.state == .alive:
    updatedCells.append(cell)
}

Here we’re switching on the number of live neighbors. We could also perform a switch on the state of the cell, but I wanted to show you another little trick that we can do with number ranges.

Since the cell is already alive, we’ll append it, as is, to the updatedCellsarray.

Next, we want to handle the fourth rule. If the cell is dead and has three live neighbors, it becomes alive.

case 3 where cell.state == .dead:
    let liveCell = Cell(x: cell.x, y: cell.y, state: .alive)
    updatedCells.append(liveCell)

We’ll use the same coordinates as the current cell and set its state to .alive.

For every other case that these two don’t cover, we want to append a dead cell to the updatedCells array. To do that, we add a default case.

default:
    let deadCell = Cell(x: cell.x, y: cell.y, state: .dead)
    updatedCells.append(deadCell)

The switch statement is now complete.

switch livingNeighbors.count {
case 2...3 where cell.state == .alive:
    updatedCells.append(cell)
case 3 where cell.state == .dead:
    let liveCell = Cell(x: cell.x, y: cell.y, state: .alive)
    updatedCells.append(liveCell)
default:
    let deadCell = Cell(x: cell.x, y: cell.y, state: .dead)
    updatedCells.append(deadCell)
}

I bet you didn’t think it was going to be this simple. Before we can test it though, we’ll need to make a slight change to the WorldView.swift file. We don’t have anything triggering the updateCells function yet, so we’ll need to fix that up first.

Touch Gestures

Since we’re using UIKit in our playgrounds, all interactions with the live view are touch-based — even if we’re using a mouse. At the bottom of the WorldView class, we need to override touchesBegan to capture a touch event sent to the live view so we can run our updateCells function.

public override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
    world.updateCells()
    setNeedsDisplay()
}

Calling updateCells() will apply all of our game rules. Following that with setNeedsDisplay() tells our view that it needs to redraw its contents, which in turn calls draw(rect:). Now its ready to test.

Game of Life

Go back to the main playground file, and make sure you have the live view open in the assistant editor.

Each time you click on the view, the game steps forward another generation. Over time, the simulation will eventually settle in. You’ll find that some common patterns will emerge over many games. There’s a great list of them on Wikipedia if you’re interested in learning more.

Bonus

Constantly clicking to see results gets boring after a while. So let’s get the game running on its own.

Navigate to your WorldView.swift file and add this function at the bottom of the class:

public func autoRun() {
    DispatchQueue.main.asyncAfter(deadline: .now() + 0.2) {
        self.world.updateCells()
        self.setNeedsDisplay()
        self.autoRun()
    }
}

.now() is the current time, but if we want the code to pause for a moment, we can add some extra time. In this case it’s 0.2 seconds.

Then, go back to your main swift file and call autoRun() on view.

let view = WorldView(worldSize: 100, cellSize: 5)
view.autoRun()
PlaygroundPage.current.liveView = view

The playground will now run forever, or until you end it manually.

You should now have a thorough understanding of how you can start to think about and create cell-based simulations of your own. You’ll find other projects like this, as well as how to use simulations to create procedural art in my book titled “Simulations in Swift”. I’ve also included a “getting started with swift playgrounds” section for people who might be new to the language.

If you haven't already, you'll want to check out part 1 before continuing with this chapter.

World

The World is where our cells will live out their entire lives. It’s also where we will set up most of the logic and rules for the game. So naturally, a few things might already be coming to mind with what properties we might need.

For starters, we’ll need somewhere to store our cells, and we’ll also need to know how many cells are required to fill the world.

public class World {
    public var cells = [Cell]()
    public let size: Int
}

size will be the number of cells that can fit across both axis of the world grid. So a world with the size of 10 would be able to support one hundred cells.

Let’s write an initializer for our world class.

public init(size: Int) {
    self.size = size
}

This initializer gives us an excellent entry point into this class. Being able to specify a size at initialization is important because the next step is to fill the cells array with cells.

Still, inside the World initializer, add the following code.

for x in 0..<size {
    for y in 0..<size {
        let randomState = arc4random_uniform(3)
        let cell = Cell(x: x, y: y, state: randomState == 0 ? .alive : .dead)
        cells.append(cell)
    }
}

Here we have a 2D array. 2D arrays are used almost exclusively for building out a grid. You’ll find them in nearly every grid type tile game. x loop for one axis y loop for another. However, we’re using the results a little different than what would be considered conventional. The cells are being inserted directly into a list — a single array. This is because we’ve opted to have the cells know their position in the world, rather than having their position determined by where they might be in a nested array. The benefit here is that this will be the only place in our program that you’ll see a nested for loop. This gives our game a slight performance increase. So when it comes time to check the neighbors of a cell, or draw it to a view, we’ll only need to iterate over a single array.

I’ve opted to go for a random distribution of alive and dead cells in my world as I find that random world generation is much more interesting. In many versions of the Game of Life, players can set which cells they’d like to be alive, and sometimes even make changes after the game has started running.

In our version, about a third of the cells will be alive when the game starts. You can adjust this to your taste by changing the input integer for arc4random_uniform(). The higher the number, the less live cells will be created.

To test this out, we’ll go back to the main playground file, remove the code we have in there for testing `Cell` and replace it with this:

let world = World(size: 2)
dump(world.cells)

When it comes to things like arrays or nested object types, they can be difficult to read when their contents are printed out all on a single line. dump will output the contents of an object to the console in an excellently structured and readable way.

A world with the size of 2 should print out four cells to the console.

World View

The WorldView.swift will be a class where we put our all of our drawing code. This will be a subclass of UIView and get passed into the liveViewproperty of our playground. Its also there look after our World object.

The first thing we need to do is import UIKit at the top of the file.

import UIKit

public class WorldView: UIView {
    var world: World = World(size: 100)
    var cellSize: Int = 10
}

The only two properties we’ll need is the world and cellSize. The cellSize is what we’ll use to draw each cell as well as calculate how big the view needs to be.

If each cell is 10x10 pixels, and the world is a size of 5, then the view would need to draw its cells on a square canvas of 50x50 pixels.

Notice that while the class has been made public, these two properties are private. We won’t need to access them outside of this class, but we will need a way to set them. Unfortunately, since we’re using a subclass of UIView, we must make use of its designated initializers. To do this, we’ll create our own convenience initializer to pass in a few parameters which will then call a designated one.

public convenience init(worldSize: Int, cellSize: Int) {
    let frame = CGRect(x: 0, y: 0, width: worldSize * cellSize, height: worldSize * cellSize)
    self.init(frame: frame)
    self.world = World(size: worldSize)
    self.cellSize = cellSize
}

Here we’re calculating the size of the canvas based on the worldSize and cellSize parameters, then creating a frame which gets passed into the views init function.

Since we also have world and cellSize initialized in their property declarations, we may as well use these as a default for setting up WorldView. So let’s create another convenience initializer for that too.

public convenience init() {
    let frame = CGRect(x: 0, y: 0, width: 1000, height: 1000)
    self.init(frame: frame)
}

Now we have a few errors. UIView has a required init function that we must implement whenever we subclass it. Even though we won’t be using it, we still need to have it in there.

You can get Xcode to stub this out for you, but if that doesn’t work, use the following code:

public required init?(coder aDecoder: NSCoder) {
    fatalError("Not implemented")
}

We want the program to crash if something tries to initialize WorldView with this function. Crashing is a great way to inform ourselves and future developers that nothing is supposed to call this function. The program will exit early, and we’ll get a little error message in the console.

To fix the last compilation error, we also need to add the init(frame:)function that one of our convenience initializers are calling.

public override init(frame: CGRect) {
    super.init(frame: frame)
}

Finally, let’s start drawing some cells.

We’re going to override UIViews draw function.

public override func draw(_ rect: CGRect) {
}

The default implementation of this method doesn’t do anything, so there’s no need to call super as we do with the init functions. We also never need to call this method directly. iOS will call draw(rect:) when the view is first displayed, or any time an event occurs that invalidates a visible part of the view. Later on, we’ll force a drawing update indirectly by calling setNeedsDisplay any time a touch is detected.

It’s important to remember that this function should only be responsible for rendering view content. Any other code you put in here that might take a significant amount of time to execute will impact the performance of your application. I highly encourage you to have a read through of Apple’s documentation on draw(rect:).

Inside the draw method, we’ll grab a reference to the CGContext provided by Core Graphics.

let context = UIGraphicsGetCurrentContext()
context?.saveGState()

We’ll be passing messages to this context; telling it what to draw for every cell that exists in the world.

for cell in world.cells {
  let rect = CGRect(x: cell.x * cellSize, y: cell.y * cellSize, width: cellSize, height: cellSize)
	let color = cell.state == .alive ? UIColor.green.cgColor : UIColor.white.cgColor
	context?.addRect(rect)
	context?.setFillColor(color)
	context?.fill(rect)
}

So the position of each cell is based on the product of its coordinates and cellSize. This places them at regular intervals within the view. I’ve also set the color of my live cells to green, but you’re free to set any color here.

Then, at the end of the draw method, we’ll set our changes so that they can appear in the view.

context?.restoreGState()

Let’s test this out and get some cells appearing in our playgrounds live view!

Go back to you main playgrounds file and replace the code from our previous test with these two lines:

let view = WorldView(worldSize: 10, cellSize: 10)
PlaygroundPage.current.liveView = view

Run the playground, and you should see live and dead cells randomly distributed in a 10x10 grid.

In part 3 we’ll go over creating the game rules.

Engineers writing code for an 8-bit system such as the NES, only had access to integers between -128 to 127 (signed). However with some tricks, such as breaking the numbers into smaller pieces, any cpu is capable of working with numbers of any size.

This method of breaking the numbers up can be performed at the hardware level, but there are some software tricks we can use too.

The following table describes some common available integer sizes.

╔═══════╦═════════════════════════════════════════════════════════╗
║ Type  ║                      Output Range                       ║
╠═══════╬═════════════════════════════════════════════════════════╣
║ int8  ║ -128 to 127                                             ║
║ int16 ║ -32,768 to 32,767                                       ║
║ int32 ║ -2,147,483,648 to 2,147,483,647                         ║
║ int64 ║ -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 ║
╚═══════╩═════════════════════════════════════════════════════════╝

Notice the int64 range. You may have seen these numbers somewhere before. 🌚 Back when Game Center was a thing...

Using strings to represent numbers

What we’re going to do is create our own number type. A type that can handle operations on obscenely large numbers, and we’re going to use Strings to do this.

Currently there’s no way to add, subtract, multiply or divide integers with strings directly in Swift. So we need to construct our own type to handle this.

We’ll start out with a new struct and call it BigInt.

struct BigInt {  
    var value: String
}

We’ll start out with a variable called value. There's also no need to create an initializer because Swift will provide this for us.

Calculations

Our BigInt is pretty useless without being able to perform a few calculations. So lets jump right into something a little tricky like multiplication.

We’ll use the same method you did when learning how to multiply larger numbers on paper in school.

We start by splitting both values into arrays, where a single character is mapped to each index. The arrays are then reversed to make things a little easier. Finally we loop over both arrays, and multiply the single digits found at each index with each other.

func multiply(left: String, right: String) -> String {
    var leftCharacterArray = left.characters.reversed().map { Int(String($0))! }
    var rightCharacterArray = right.characters.reversed().map { Int(String($0))! }
    var result = [Int](repeating: 0, count: leftCharacterArray.count+rightCharacterArray.count)
    
    for leftIndex in 0..<leftCharacterArray.count {
        for rightIndex in 0..<rightCharacterArray.count {
            
            let resultIndex = leftIndex + rightIndex
            
            result[resultIndex] = leftCharacterArray[leftIndex] * rightCharacterArray[rightIndex] + (resultIndex >= result.count ? 0 : result[resultIndex])
            if result[resultIndex] > 9 {
                result[resultIndex + 1] = (result[resultIndex] / 10) + (resultIndex+1 >= result.count ? 0 : result[resultIndex + 1])
                result[resultIndex] -= (result[resultIndex] / 10) * 10
            }
            
        }
        
    }
    
    result = Array(result.reversed())
    return result.map { String($0) }.joined(separator: "")
}

multiply(left: "2844858348834855723432430", right: "134534523453454540998798789")

There’s a lot going on here, you be fine to copy and paste it into a playground if you want a closer look at what’s going on.

This method isn’t the most performant or safest piece of code.

There’s also nothing stopping someone from entering a character that isn’t a number, which would of course result in a crash.

Now this is just a stand alone function. Which really could just be added anywhere within our project and do a good job as it is. However, we want something that will work with our BigInt type.

We want to be able to do something like this:

let int1 = BigInt("10")  
let int2 = BigInt("5")  
let product = int1 * int2  

BigInt

Alright so let’s add the function to our struct and alter it a bit to make it more to our liking.

struct BigInt {

    var value: String

    func multiply(right: String) -> String {
        // We'll change this line to use value
        var leftCharacterArray = value.characters.reversed().map { Int(String($0))! }
        var rightCharacterArray = right.characters.reversed().map { Int(String($0))! }
    ...


// Now we can do this
let int1 = BigInt(value: "34")  
let int2 = BigInt(value: "45")  
let product = int1.multiply(int2.value)

Close but still doesn’t give us what we’re after.

Let’s remove the String requirement and pass our BigInt right into our multiply function.

func multiply(right: BigInt) -> BigInt {

    var a1 = value.characters.reversed().map { Int(String($0))! }
    var a2 = right.value.characters.reversed().map { Int(String($0))! }
    ...
    ...

    // And change the last line
    return BigInt(value: result.map { String($0) }.joined(separator: ""))
}

// Our calculation now looks like this.
let int1 = BigInt(value: "34")  
let int2 = BigInt(value: "45")  
let product = int1.multiply(int2)  

A bit cleaner, but lets go all the way and define our own * operator.

Operator Overloading *

All you need to do is add this line somewhere outside our BigInt struct.

func * (left: BigInt, right: BigInt) -> BigInt { return left.multiply(right) }

Operator overloading allows you to change how existing operators behave with types that both already exist (Int, Float, String), and any custom types you have created. In this example, we’re letting our program know how to multiply two BigInt types the same way we would any other primitive number type.

Finally

This is what it should all look like once you’re done.

import UIKit
import Foundation

struct BigInt {
    
    var value: String
    
    func multiply(right: BigInt) -> BigInt {
        var leftCharacterArray = value.characters.reversed().map { Int(String($0))! }
        var rightCharacterArray = right.value.characters.reversed().map { Int(String($0))! }
        var result = [Int](repeating: 0, count: leftCharacterArray.count+rightCharacterArray.count)
        
        for leftIndex in 0..<leftCharacterArray.count {
            for rightIndex in 0..<rightCharacterArray.count {
                
                let resultIndex = leftIndex + rightIndex
                
                result[resultIndex] = leftCharacterArray[leftIndex] * rightCharacterArray[rightIndex] + (resultIndex >= result.count ? 0 : result[resultIndex])
                if result[resultIndex] > 9 {
                    result[resultIndex + 1] = (result[resultIndex] / 10) + (resultIndex+1 >= result.count ? 0 : result[resultIndex + 1])
                    result[resultIndex] -= (result[resultIndex] / 10) * 10
                }
                
            }
            
        }
        
        result = Array(result.reversed())

        while result.count > 0 && result.first == 0 {
            result.removeFirst(1)
        }
        
        return  BigInt(value: result.map { String($0) }.joined(separator: ""))
    }
    
}

func * (left: BigInt, right: BigInt) -> BigInt { return left.multiply(right: right) }

Multiplying two BigInts together should be as simple as:

let int1 = BigInt(value: "34757377374573285823949593499549646311234")  
let int2 = BigInt(value: "45123498348958923845838948528381283721377123454345")  
let product = int1 * int2  
// result: 1568374460575699918065222772187576926314538959488859994856690985365041943440429553059611730

There you have it. It’s not perfect, but it does give you an idea of how we can work around some of the hardware restrictions we face as developers.