My iOS Development Kit - January 2016

If you surveyed me annually, you’d likely find that my toolkit for building Mac and iOS applications changes a bit year over year. This year, however, the changes seem to be even bigger than before. With Swift 2’s release, I made the full transition from Objective-C to Apple’s new language du jour.

The transition has not been without growing pains (hello, constantly crashing debugger!), but overall I am writing better, more idiomatic code. And this is coming from someone who spent the last decade happily writing Objective-C. Since I’m making the transition, I’ve also used it as an opportunity to re-evaluate the third-party libraries I am using in my client applications.

I tend to have a fairly reserved stance on third-party dependencies. I am not vehemently against them like some, but I also don’t want to turn my app into a Lego set where I’m merely piecing together library after library that I don’t fully understand. The tools below are things I have used and successfully deployed to production.

Carthage

In the Dependency Wars, I have tried them all. I started with vanilla Git submodules, and did a brief tour of duty with Cocoapods. Submodules didn’t offer nearly enough wins for the management overhead I seem to have. Cocoapods worked for the most part, but I have fundamental disagreements with how they package and build their products.

Carthage seemed like a happy medium for me. I get the wins of using some sort of dependency management system, and it sticks with using the shared Xcode schemes that are bundled with the project itself.

RxSwift

This is the most recent addition to my list, but it’s one I’m growing to enjoy most. Functional programming is what all the hipster developers are doing these days, so I am trying to wrap my head around it. I may not understand why they wear wood framed glasses, tight jeans, and so much flannel, but I am starting to come around to the idea of building things functionally.

RxSwift is from the same folks who do Rx.net, RxJava, and a host of other implementations, which may or may not be appealing to you. When learning something new, documentation is important and I’ve found the docs for RxSwift to be pretty well done. There’s still cases where the generic ReactiveX documents are “TBD” in terms of RxSwift, but having the header docs fills in many of those gaps.

My biggest complaint with RxSwift isn’t so much a complaint with the library as it is with the idea of functional programming. It is a major change in how you think, so I spent most of my first few weeks re-reading docs, cursing and trying to understand what was actually happening. Eventually it will click, and when it does it’s a really nice way to build iOS libraries.

RxSwift includes a library for making UIKit more reactive, but I’m shying away from it presently. Right now I have limited RxSwift mostly to integration with network modules I build. I reserve the right to change my mind about this in the future, but right now delegates and data sources don’t bother me that much.

SwiftyJSON

It is a toss-up whether there are more Swift JSON parsing libraries or Republican presidential candidates in the US. I don’t really have anything negative to say about SwiftyJSON. It works and saves me from writing JSON parsing code over and over again.

You can likely choose one of the other 107 libraries and it will do pretty much the same thing: just like a Republican presidential candidate!

Realm

I have used Core Data since it was introduced way back in OS X 10.4. I have never loved Core Data, but it has always gotten the job done and proved better than raw SQLite queries (I’m that much of a masochist).

I interviewed the Realm folks way back when on my CocoaRadio podcast and found it to be an interesting project. I just didn’t have anything to implement it in since I was already successfully deploying Core Data in my existing client projects. With a new project that ramped up early last year, I decided to give it a shot.

I’m having a hard time convincing myself to go back to Core Data for anything right now. Core Data has always felt bloated to me, especially when trying to bring up the stack in an application. I also have many battle wounds to show for Core Data threading issues over the years. All things of the past with Realm. I can query the same Realm from any thread and bringing up a new one is at most three lines of code.

Apple is working to improve Core Data each year, but I’m starting to believe they should just reboot the framework like a comic book movie and start over. Or keep it as is, and I’ll keep using Realm.

Aspen

I was a longtime user of CocoaLumberjack, but was running into a issues when starting to migrate an existing client application to use Swift in some places. I also started having issues where there updates to the library would just fail to work in the application without me spending a few hours each release debugging things.

I decided to use that as a chance to write my own clean room logging implementation that does everything I need: which isn’t that much. I call it Aspen, and you probably shouldn’t use it.

It works for me and is deployed on millions of iOS devices, but it’s also something that I don’t really see growing beyond the scope of the project as is. I’d like to add log rolling and ASL support, but after that there’s not much else I need in a logging framework. If your needs are greater, any other solution will probably work better for you.

Fastlane

The newest piece of my kit is Fastlane, a suite of Ruby scripts from Twitter’s development folks. I am using Fastlane to help run unit tests from the command line, build releases and automatically upload them to TestFlight. The suite can do a lot more, but my needs are fairly simple.

The next piece to my Fastlane puzzle will be getting some sort of continuous integration component. Maybe next year.

Plain Old NSURLSession

You’ll notice that I’m not using a networking library like AlamoFire or similar. For most of the projects I am working on, I don’t need the extra overhead those libraries offer me. I tend to put each network request in its own Swift class and make them return an RxSwift Observable. I then have a parent class that will vend those request classes out. I may write about this more in the future, if enough people ask nicely.

My Ultimate Developer and Power Users Tool List for OS X (2013 Edition)

This is the fifth installment of my must have must have list of tools and utilities as a Mac and iOS developer (2009, 2010, 2011, 2012). This year’s edition of the list takes into account the new tools I am using as part of my transition to working exclusively on iOS 7 and OS X Mavericks, as well as an amateur designer.

The idea for this list was shamelessly ripped off from Windows developer Scott Hanselman whose list has long been an enjoyable read when he updates it.

Many of the products you will recognize from previous years’ lists. I’ll outline new additions to the list as I go by marking them in bold.

Hardware

My hardware is mostly the same as last year. I am still maintaining a dual Mac setup. My daily driver is a 27″ i7 iMac with a 256GB SSD, 2TB spinning disc and 16GB of RAM. There is absolutely no reason for me to have 16GB of RAM other than to brag about the fact that I have such a ridiculous amount of memory. After almost four years, this machine is still humming along like a champ. The only reason I would consider upgrading to a new one is aesthetics at this point.

At home I am using my 15″ Retina MacBook Pro with a 512GB SSD and 8GB of RAM. This is the first revision of the Retina MacBook Pro and it’s probably one of my favorite Macs ever assembled. My only request going forward is a much higher retina resolution. It’s really a challenge to jump between the massive amount of pixels that a 27″ iMac affords you and then head back to a 1440×900 display at home.

I am using Dropbox more than ever to keep everything between the two machines in sync. I symlink Documents, Downloads, Movies, and Sites to point to those respective directories on Dropbox. I am also using shared Dropbox folders for Second Gear projects that require collaboration with a designer. I’m still using GitHub for storing all of my code.

In terms of accessories and upgrades:

Software

I am really hard on software. This is for a variety of reasons, but I think it is because I build it myself. I have always envisioned that directors and actors can sometimes lose focus during a movie as they judge the decisions others made in their productions. I feel like I do the same thing with software.

I loathe poor and/or non-native user interfaces and cherish simple tools. These are applications I constantly rely on.

The Essential Five

Developer Tools

User Tools

Audio Production

Outside of doing software development, I talk about software development and technology in general with my Windows development buddy, Mikel Berger on IRQ Conflict. These are the tools used to produce the show and some other audio gimmickry I pursue: