Oct 1, 2018

NativeConnect Internals

Here I’d like to share some technical information about the app. If you are into Cocoa development, maybe you will find this post useful. This is a technical article, and it would be nice to periodically discuss the ongoing challenges and their solutions on NativeConnect.

100% Swift

Every single line of NativeConnect is written in Swift. I heavily considered Objective-C because this product is not a toy, but after checking some nice books and videos the choice was evident. I wanted to have fun, so here we go.

By the way, my experience with adopting Swift is extremely positive. During the first week of development, fighting Swift took about 40% of my time, but I kept digging. The second week brought more success with just 20% of digging the language instead of writing new code. The third week it was 5%! And one month later, guess it, -5%… Well, my code is more like Objective-C wrapped into the new syntax, but not having to #import and .h adds so much to productivity anyway.

100% AppKit

NativeConnect is a classic Cocoa app, with Core Data for a data layer. I have some clue about things like reactive programming and MVVM, but there is still something cool in MVC. Like Dave DeLong suggests, I carefully think about managing responsibilities and use a lot of view controllers.

This approach served me really well and it is quite easy to refactor things with such standard codebase. Also I like to think that Xcode is happier and probably faster when it works with NSView and NSViewController instead of RxSomething.

Core Data

I considered many options, including the ones from past projects, but finally figured out that I do not want the data layer to depend on the third party framework. So the modest choice for the model in NativeConnect is Core Data. From my experience, this framework is pretty easy to debug and work with, when used properly.

Package Manager

One of the best things I like about Swift is its Package Manager. Not having that .xcodeproj files in your repo adds a very special feeling, for my taste. Luckily, Swift 4 has commands for full-featured integration with Xcode and enables Build Settings customization.

For Mac app development, SwiftPM is totally production-ready. For the rare third-party libraries incompatible with SwiftPM e.g. Hockey SDK, I use Carthage.

Xcode Bots

To make sure NativeConnect is a good quality, I’m trying to keep all code in core covered by Tests. At the moment, both NativeKit and NativeData frameworks are 100% TDD.

BitBucket which I use for private repos has a limited set of CI integrations, so I tried Xcode Bots and cannot be happier! Auto-builds and nightly releases work like a charm, and it’s all free. Totally recommended.

Interface Builder

The only IB file in NativeConnect is a proud MainMenu.xib. I went with code-only UIs long time ago because of refactoring and functional programming, but let’s talk about this another time.

Speaking of declarative non-code formats though, I really enjoy asset catalogs for images and colors. Sometimes I even think that it would be nice if they supported fonts as well. But even in current state, graphics management in Xcode is just great.

Conclusion

My choice for this project is mostly native tools provided by Apple. Swift is a fantastic language, and AppKit on Mojave feels better than ever. Cheers!