I started doing iOS development at Facebook, which only used Objective-C for its iOS apps. But given Swift’s growing popularity (Apple’s own adoption has been growing quickly), we decided to offer and write our SDK natively in Swift. So I set off to learn Swift from scratch while working on the SDK, and I ended up loving it! Here are my five favorite things about Swift so far:
I started off reading some open source projects, and I was able to understand everything without any prior knowledge of the language. The syntax is much closer to a language like JavaScript or Java than it is to Objective-C, which is great news for new iOS developers. For example, instead of concatenating strings like this:
NSString *firstMsg = @”Concatenating strings in Objective-C “;
NSString *secondMsg = @”is hard”;
NSString *fullMsg = [NSString stringWithFormat:@”%@%@”, firstMsg, secondMsg];
we can now do this:
let firstMsg = “Concatenating strings in Swift “
let secondMsg = “is EAZY”
let fullMsg = firstMsg + secondMsg
There are many handy features that I wish existed in Objective-C. While writing the SDK, I found out that Swift supports many features that Objective-C did not. For example:
optional parameters and labels
(true) generics
optional chaining
These allowed me to not only write cleaner code myself, but also to pass the benefits onto our users because I am able to create more user-friendly function signatures in our SDK.
Needless to say, this is awesome! I’m also pleasantly surprised by how little I missed them — in fact, I didn’t even realize it until I was almost done with the core SDK features…
Swift introduced some nice quirks that I found strange at first but soon started using everywhere. Let’s say you are writing a function that does something with a vehicle’s model year (vehicle.model.year) while everything can be nil, you can use the new keyword and comma-separated if statements to get the edge cases out of the way first like this:
guard let vehicle = vehicle,
let model = vehicle.model,
let modelYear = model.year else {
// if vehicle, model, or modelYear is nil, we return nil here
return nil
}
// do something with modelYear now that it is not nil for sure
And I especially love this one line of code you can use to capture weak self in a closure:
guard let self = self else { return }
There are lots of applications written in Objective-C still, so we need to provide an SDK for Objective-C users as well. Fortunately, Swift provides an easy way for us to simply write a wrapper on top of the public classes and functions we need to expose to Objective-C code. For a class like this in Swift:
public class Statsig {
public static func start(sdkKey: String) {
...
}
}
You can just create a new class like this:
@objc
(Statsig)
public class ObjcStatsig: NSObject {
@objc public static func start(withSDKKey: String) {
Statsig.start(sdkKey: withSDKKey)
}
}
Once the framework is imported, your Objective-C code will be able to call [Statsig startWithSDKKey:@"my_sdk_key"];! Note that @objc implies which class, member, or function to be converted, and I'm renaming the class name from ObjcStatsig to Statsig when exposed to Objective-C with the (Statsig) after @objc. I also named the parameter "withSDKKey" to follow Objective-C naming convention, but if you don't, Xcode will automatically prepend a "with" prefix to your first parameters in the bridging headers. Pretty neat, isn't it?
Unfortunately, this took me quite a while to figure out: even though it’s painless to implement, the documentation online for this is pretty lacking. If you want to see more of how we pull this off, check out our GitHub repo. Or, if you’re looking for a feature flag/experimentation framework for your iOS App, then feel free to integrate Statsig in your Objective-C or Swift codebase!
What do YOU love (or hate) about Swift?
Find out how we scaled our data platform to handle hundreds of petabytes of data per day, and our specific solutions to the obstacles we've faced while scaling. Read More ⇾
Building a scalable experimentation platform means balancing cost, performance, and flexibility. Here’s how we designed an elastic, efficient, and powerful system. Read More ⇾
The debate between Bayesian and frequentist statistics sounds like a fundamental clash, but it's more about how we talk about uncertainty than the actual decisions we make. Read More ⇾
Here's how we optimized store cloning, cut processing time from 500ms to 2ms, and engineered FastCloneMap for blazing-fast entity updates. Read More ⇾
It's one thing to have a really great and functional product. It's another thing to have a product that feels good to use. Read More ⇾
Stratified sampling enhances A/B tests by reducing variance and improving group balance for more reliable results. Read More ⇾