Using Operator in Xcode

Operator in a Playground

For the longest time I have been using Meslo as my monospaced font of choice in Xcode, Atom, and Terminal. I couldn’t resist the urge to give Hoefler & Co’s Operator release as a replacement. I don’t really have issue spending money on tools that make me more productive in my day to day work. I never truly considered buying a font for development work though. For $179, I could have spent that money on at least 150 iOS apps!

After rolling my eyes at the absurdity of that thought, I transferred $179 from my bank account to Mr Hoefler’s, installed the font, and updated my Xcode theme to use it at 16pt universally.

My quick verdict? I like it. I don’t starch my plaid shirts nearly enough to offer a critique on the baselines and kerning of a font. I’ll leave that to the designers. But, it’s pleasant on my eyes and I can easily tell the difference between a capital O and a zero.

Is a new font going to make you more productive? Doubtful, unless you’re using something like Papyrus. I like it though, and you might too.

Check out Operator from Hoefler & Co

Read more about. . .

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.

Read more about. . .

Learning How To Make Sausage

Let’s imagine there is someone out there who watched last week’s WWDC keynote and thought to themselves, “This is it! Now! Now is the time for me to learn to program and build an iOS app!”

Nevermind that they are about 6 years late to gold rush, it’s an exciting proposition. Programming is fun! I come from a family of builders. The only difference between my father and grandfathers is they built homes with hammers. I sit in front of a keyboard all day typing and looking at cat GIFs.

I digress. You want to learn to be an iOS developer. What are you supposed to do? Aaron Hillegass (whose books I credit with teaching me this stuff way back when he was the only person writing about Cocoa development) says you should learn Objective-C. Ash Furrow and a few others say you should learn Swift because Objective-C is too hard.

Guess what? It doesn’t matter what language you want to learn.

If you want to be an iOS developer you realistically have four options:

  1. Objective-C: old faithful.
  2. Swift: New hotness.
  3. Xamarin: The crazy kids in the corner who want to use C#.
  4. RubyMotion: Know Ruby? Tired of arguing with DHH about whether tests are dead? You too can build an iOS app.

I’d lean towards choosing one of the first two options because they are first-party solutions provided directly by Apple, but the language you choose to learn matters little compared to learning the frameworks. The Cocoa Touch frameworks have always been the secret sauce. Whether you’re using Objective-C, Swift, C#, or Ruby you’re still going to have to learn how to use a UIButton and a UITableView.

Will you be more of an iOS developer because you took the time to learn Objective-C and it’s 20+ years of history versus Swift and its eleven days? Nope. Your customers care about what’s on the surface of your app: does it look, interact, and feel like an iOS app. If you can do that, the language doesn’t matter.

There is no right answer to this question. Choose what the language that speaks to you and then go build something awesome.

Read more about. . .