Getting Swifty With It

Why Swift

After having spent a couple of years developing iOS applications with Objective C, I decided to get back into things. However, iOS development, unlike war, changes. Objective C, NIBs, and Storyboards don’t represent the current state of iOS development. So I decided it was time to finally to try and learn Swift.

So I did the first thing I do every time I want to learn something new, find out what animal O’Reilly slapped on the cover.

Maybe it’s the book

I hate to mention which book I started reading. Because I’m not quite sure I like it. It seems to go fast where I want to go slow and slow where I want fast. As of this time, I’ve finished the overview of the Swift language and have started the section on XCode.

So far, it’s probably worse. The book assumes you’ve never used XCode before. Which isn’t the worst assumption. This book is really soup to nuts. The last section is about Cocoa classes, which I’ll get to when I get to it.

Maybe it’s me

But I already know how to program. At times I’ve written software in C, C++, Basic, Visual Basic, Visual Basic for Applications, Python, Javascript, Typescript, Perl, PHP, C#, Objective C, and Pascal. So explaining why you’d want a constant instead of a mutable variable is probably information I don’t really need at this point. Same with the XCode portion. I’m casually familiar with XCode. And regardless, I’ve seen an IDE before, I can work out which window is the editor.

End of the day, I think I just purchased the wrong book. This book is likely more for someone with no prior experience than it is for someone looking to learn an additional language.

The actual language

Swift seems to be enough in that “C” wheelhouse that a lot of things are going to seem familiar. If you’re coming from [Java|Type]script, you’ll have to be mindful of the difference between let and var. In Javascript and Typescript, they’re used to declare variables with different scoping rules. In Swift, let declares a constant and var a mutable variable. That’s the most glaring gotcha I’ve spotted so far. I’m probably going to make more than a fair share of classes where I should be making structs. I blame C.

Swift also has something called a “trailing closure”, which is when the final argument to a function is also a function. Like most languages that support passing functions as arguments, you can pass a lambda or closure in place of a function. However, in Swift, if it is the last argument, you can define the closure outside of the call to the function. It would look something like this:

func closureFunction(withClosure:() -> Void) {
    print("Inside function");
}

callToFunction {
    print("Inside closure");
}

Which is neat. if a little weird when you first encounter it. But easy enough to grok once you understand what it is. And you better grok it because you’re going to be seeing it a lot.

SwiftUI

Instead of Storyboards or Nibs or Xibs, you define the UI through SwiftUI. Ingenuous name. And this is where you’ll be seeing a ton of trailing closures. Every View and derived class have an initializer whose final argument is a function that builds the View. And since it’s the final argument, these are typically built using trailing closures.

View {
    VStack {
        Text("I am in a vertical stack")
        HStack {
            Text("I am horizontal.")
            Text("Not a replacement for tabs")
        }
        Text("I am below")
    }
}

I think I like this. It’s a little like XAML, but it’s all code all the time. All of the constructors and methods return the object so you can chain calls. And any setting not set during initialization is set with a method call.

Now, it’s been a hot minute since I’ve opened up Xcode, but it does seem like the SwiftUI Canvas Editor is alright. A lot more direct than messing around with Nibs and connecting connectors.

Swift Playgrounds

It’s pretty much a stripped down Xcode. There are also several programming puzzles/games to go through as well to get a feel for Swift. There’s not a whole lot to say about it specifically, If you want to check out Swift without a whole lot of investment, it’s not a bad place to be. Especially if you have an iPad.

In the Future

Like I said at the top, I’m tinkering around with iOS development again. There are a couple of projects I’m tying to get done that have an iOS component. Nothing to really share about them yet, but new projects, might as well try new things.