Swift at Scale

New Features in Realm Obj-C & Swift

We’re releasing version 2.4 of Realm Objective‑C and Realm Swift, and giving our live objects a whole lot more life by adding object-level notifications, so that your app can respond as individual objects update.

Introduction (00:00)

Apple released Swift on June 2014 at WWDC, we were shocked at first, then excited about the release and decided to write our app in Swift.

Why Swift? (00:45)

Swift is the future of iOS. With interoperability possible, we are able to use Objective-C with Swift. The syntax is clear, and newcomers from other platforms can learn faster and make less mistakes than in Objective-C.

More can be accomplished with less lines of code. For example, we can see the difference between Objective-C and Swift when calling an optional method, or when creating a simple type with read-only properties: Swift does this with only three lines, whereas Objective-C takes 14.

Another cool feature of Swift is functional programming. Swift naturally supports functional programming concepts - i.e. filter, reduce map, flat map. This makes the code cleaner, and we can use smart one-liners like map (you cannot use such one-liner in Objective-C).

Bumps Along the Way (04:28)

With Swift, there were long compilation times, issues with migration, and with Xcode.

Compilation time

Swift had long compilation times, and this made it more difficult to fix bugs, as it’s easy to lose focus.

We researched this topic, and we found a possible explanation. When using whole module optimization, the Swift compiler performs the whole optimization on the module level. It’s not performing optimization based on a single Swift file, but it’s doing it on the whole framework level.

The difference between whole module optimization and O-none is that we had faster build times (10 minutes versus 40 minutes for the compilation from scratch).

One problem with whole module optimization is that incremental builds were not supported in Swift 2. Every time we were fixing a bug, we had to wait about 10 minutes to compile the project. The debugger does not work well with whole module optimization, and stepping behaved oddly.

Every time we wanted to debug something, we had to switch versions - which can be cumbersome. On the other hand, with O-none, we have slower compilation times and incremental builds.

Solving the compilation issue (13:37)

We had a suspicion that the problem was not in the compilation of code, but in processing dependencies. Reducing this number of files would help, but this was hard when we had a single monolithic setup without frameworks.

The only solution was to introduce frameworks into the project. With frameworks, we composed our project into smaller parts which had less dependencies. We no longer had to recompile the whole project from scratch.

The drawback to introducing the frameworks post-factum was that we had to convert all the existing code into the approaches taken by the frameworks. For example, we had to annotate classes with proper scope by making it public, and then we had to add missing imports.

Migration (20:30)

We started our project with Swift version 1.2. When it was time to do a migration, it took us three weeks.

The migration process was divided into several parts.

The first part was to use the auto migration tool. In our case, automigration tool was running nine hours. And it was running in a way that without feedback on the progress.

After this was complete, we had over 30,000 errors or warnings, and had to manually fix them. For example, the automigration tool likes to suggest forced upwrapping optionals, and we did not want that.

Lastly, we had to undergo code review. This process took about three weeks.

Migrations pitfalls (23:44)

Completing the migration did not solve all of our problems. The new version of Swift introduced some inconsitency between the legacy code and the new version. For example, the new version had guard statements. This caused some confusion regarding why some part of the code had the statement, and others did not.

What’s Next? (32:36)

We are planning migration to Swift 3, but now is not the time. We can expect problems because of all the changes in the language.

We do not regret writing the app in Swift. All of our developers are still enthusiastic to have had a chance to work in Swift in an early version.

Q & A (36:45)

Q: When you are planning to move to Swift 3, you think it will take three weeks, or it should be easier now?

Tomasz: Frankly speaking, we don’t know.

Q: I have two questions. First one: do you use your frameworks cross projects, or this is only frameworks for this one project? How do you manage these dependencies? Do you use some tool, or you just use Xcode workspace for this?

Tomasz: We are using CocoaPods.


Tomasz Gebarowsk

Tomasz Gebarowsk

Tomasz is a software Engineer currently working as an iOS Developer at mBank. He switched to Mobile apps development after 4+ years of C/C++ and writing distributed VoIP servers. Tomasz is experienced in maintaining large and long term projects.

Wojciech Łukaszuk

Wojciech Łukaszuk

Software engineer. Problem solver. Can’t stand workarounds and spaghetti code.