Obviously, Apple didn’t go to all that trouble only because they wanted us to use a different (and obviously better) API. The UserNotifications framework actually gives us access to many new, long-awaited features.
Update (2016-06-27): Nick Heer:
Unfortunately, these enhancements haven’t made their way into MacOS.
This morning we’re gonna talk about Objective-C and Swift interop. We’re gonna talk about it really from two perspectives. We’re gonna talk about it from a theoretical perspective, that of language design. […] And then we’re gonna talk about what it was like for us to take a […] 20,000 to 30,000 line Objective-C app, and start adding 20,000 to 30,000 lines of Swift to it, and to add those lines in a very Swifty style.
Interoperability makes it possible to integrate [Swift] features back into Objective-C code with no hassle […] without having to rewrite the entire app in Swift at once.
This is a quote from the Swift book, this is a lie from the Swift book. It’s a nice lie. I mean, it’s kind of true. It’s kind of true if you write bad Swift. But then, it’s basically just syntax sugar versus Objective-C, which is nice, but which is maybe not worth the complexity. […] Okay, so we had this plan, because the Swift book told us this thing, and we believed it. And we embarked about 13 months ago on a large project, we being Khan Academy, to write a large product in Swift, large existing code based, running a large new product.
It was not great, it was emphatically not great. So along the way, we were constantly forced to rewrite large swathes of our app in Swift as we went, or we were forced to decide not to use Swifty idioms and semantics, which is not a decision that we really enjoyed having to make. I think it’s fine. I’m not saying, “Oh, you shouldn’t use Swift in existing apps.” But what I am saying is, “You should add a lot of padding to your estimates.” ‘Cause it slowed everything down a lot, for months. Many, many, many months. And so there’s people out there who are just saying “Well, screw it. I’m just gonna rewrite the whole thing in Swift.” I don’t know, that might have been a better strategy. Transliterating Objective-C to Swift is pretty easy.
This is a conference talk from November 2015, before Swift 2.2 and Swift 3, but a lot of the issues still apply.
Andrew Tridgell (PDF, via @CompSciFact):
This thesis presents efficient algorithms for internal and external parallel sorting and remote data update. The sorting algorithms approach the problem by concentrating first on highly efficient but incorrect algorithms followed by a cleanup phase that completes the sort. The remote data update algorithm, rsync, operates by exchanging block signature information followed by a simple hash search algorithm for block matching at arbitrary byte boundaries. The last chapter of the thesis examines a number of related algorithms for text compression, differencing and incremental backup.
We have used protocol and protocol extensions to make our code more readable.
We have also used a few other tricks, but the main gist is that you can create small helpers in your code to make your life easier, and make life easier for other people that have to read your code. Using old APIs is great because they have been battle-tested; it is code that has been around for many years… and, for many years, bugs have been fixed. But we can make these APIs even better (and make our lives easier).
When we create these helpers, it is important to keep the spirit of the original implementation. We want to make it easy for other people who read the code, and that who may not know about these wrappers.
