Swift is a great programming language

I really like Swift. When the initial versions of Swift became available, I remember still using Objective-C due to the language being in flux and requiring frequent migrations from a previous version to the current version.

At this point, this migration process has slowed down: the language feels mature to me; it has been around for six years by now.

Previously, apps that were built with Swift had to ship their own version of the libraries, since there was no ABI stability. Swift 5 introduced ABI stability and that was a big improvement:

The ABI is now declared stable for Swift 5 on Apple platforms. As a result, the Swift libraries are now incorporated into every macOS, iOS, tvOS, and watchOS release going forward. Your apps will be easier to build and smaller because they won’t have to include those libraries.

One of the major advantages of Swift is that is a very type-safe language: you must be very explicit about every type everywhere, and there is no such thing as implicit type conversion in this language.

I’ve recently been looking at techniques to improve the apps I work on and keep them clean. One of my favourites is to maintain a Constants.swift file that contains all major constants in your app. You can nest constants quite deep too, and just typealias if you need information that’s deep.

It’s not a bad idea to maintain multiple files if you’ve got a ton of different constants, but in most cases a single file is actually easier to maintain.

For example:

struct Constants
{
	struct Version {
		static let codename 			= "Apt App"
	}
	struct Segues {
		static let toHome 				= "segue_home"
		static let toMessages 			= "segue_messages"
		static let toNotifications 		= "segue_notifs"
	}
	struct NavigationCodes {
		struct Home {
			static let Messaging 		= "id_messages"
			static let Preferences 		= "id_prefs"
		}
		struct Preferences {
			static let Notifications 	= "id_notifs"
			static let Theme 			= "id_theme"
		}
	}
}

Let’s say you need to reference the navigation code for the preferences views. You could do:

// this is rather long
let codes = [
	Constants.NavigationCodes.Preferences.Theme, 
	Constants.NavigationCodes.Preferences.Notifications
]

Alternatively, you can typealias:

typealias NavCode = Constants.NavigationCodes.Preferences

// use the typealias
let codes = [
	NavCode.Theme, 
	NavCode.Notifications
]

I also really like how Swift Packages work, I’ve been using them heavily in some larger projects. They can easily be used in other projects, but you have to pay close attention to type visibility: by default, all classes and methods are marked as internal, unless specified otherwise.

I’ve also been trying out SwiftUI in my spare time — I think it’s interesting, but it’s harder to use in more complex systems (tons of data) or with tons of custom UI. I’m sure this system will mature over time, but we likely won’t be using it for enterprise apps we build at DIVE.

If I had a ton of spare time, I’d probably rewrite my personal blog so that it runs on Swift. To be honest, I don’t have the time or interest to do so right now, especially given that I have this really great system set up right now (that I only recently set up).

For me, it took some time to truly warm up to Swift, but I really prefer it over Objective-C at this point, which has always had an awful syntax (but then again, as a programming language it has shown its age). I mean, look at these square brackets:

[self.delegate showAlert:sender 
       withConfiguration:[@"Example Title", @"Example Desc"] 
        withNotification:NO
];

This (non-existent) method call can be expressed as such in Swift:

self.delegate.showAlert(sender, 
    configuration: ["Example Title", "Example Desc"], 
    notification: true
)