How do you manage your iOS app dependencies?

This is a question I’ve answered more than a few times the past few months.

Answer: with as few third-party dependencies as possible.

A bit cheeky, yes, but there’s truth in it. As I’ve matured as a professional developer, I’ve learned to understand that a dependency and liability are many times interchangeable.

In general most of the projects I work on have as few third-party dependencies as possible. I do my best to work with what is provided by Apple’s frameworks, as well as my own suite of categories and subclasses I’ve accumulated over my years as a developer.

When something new and shiny comes along that I’m thinking about using, I have a few questions I ask before making a decision.

1. How long would it take me to write my own version of this?

Are we talking about a single class and header file that does something fairly basic that I could churn out in a few hours, or something more feature-filled and complex that is represents weeks or months of work.

Single classes I am more than likely to write on my own. Something heavier like CocoaLumberjack (which is awesome) I am likely to include as a dependency.

2. How well maintained and supported is the codebase?

Is the project actively maintained by a developer, or are we just talking about a code dump that’s just been thrown on GitHub? Is there documentation? At a minimum, is there header docs?

Open source contributors are under no obligation to provide support for their projects, but at the same time, I’m less comfortable basing a major part of my project on something that’s just out there on the web without any direction.

Projects like AFNetworking and ReactiveCocoa come to mind as good, well moderated open source projects.

Sidenote: It bugs me when people look at a codebase that hasn’t been updated in a year and claim it’s been abandoned. Projects can be completed without being considered abandoned.

3. Can I understand the code base enough that I’m comfortable patching/contributing to it?

All software has bugs. Even yours. With a third-party code base that you don’t manage, you are likely going to run into a situation where there are bugs that need to be fixed and patched. How comfortable am I reading and understanding the code base that I am thinking about adding as a dependency? If it’s not comfortable enough that I’d be willing to patch it, I’m may not be willing to include it.

One exception to this is the HockeySDK and PLCrashReporter. I have zero idea how that stuff works because I am not Landon Fuller or Mike Ash. I think they actually speak binary as a first language. Even thought I don’t understand the internals, I depend on Hockey for managing my betas and crash reports. Wonderful service.

4. How much of this code will I actually be using?

A lot of developers have the tendency to instantly import AFNetworking into their project without a second thought. It’s a wonderful resource for the community and something I have used in my own projects. At the same time, it’s a fairly heavy library that does a lot.

If you’re building an API wrapper for a third-party web service, do you really need all that AFNetworking offers or are you just using maybe 10% of its features to accomplish your goal? More importantly, if you are offering the API wrapper for consumption by the open source community, do you really want to force another third-party dependency on them?

With OvershareKit, Jared and I try to err on the side of conservative when it comes to adding external dependencies to the library. As is, it’s a pretty heavy amount of code to ingest in your project. But, most of it is self-contained which we see as a feature, not a bug.

So….about Cocoapods

I have been hesitant to adopt Cocoapods in any of my iOS projects these past few years. I’ve also been pretty vocal about this, but without much explanation.

If you look at any other major platform in play today, they have some sort of dependency management story:

• Node has npm
• .Net has NuGet
• Ruby has Gems
• Android has Maven and Gradle

Dependency management is admittedly a problem that OS X and iOS have dealt with for years. So, Cocoapods comes along and offers a solution for the problem, but I don’t want to jump on it. Why?

For one, stability and predictability. The dependency systems for every other platform are for all intents and purposes the “official” solution. In some cases such as NuGet, they’re even baked into the IDE. Cocoapods, on the other hand, is developed outside of Apple by the community and hacked into the current Xcode workflows. That’s not to insult the developers of the project. It’s pretty impressive what they’ve made from a technical standpoint. But as cool as a project is, that doesn’t eliminate the inherent risk with using it.

Let’s assume that Apple releases an amazing new Xcode 6 this summer. It has all these amazing features that you absolutely have to use. The tradeoff is that because of so many changes under the hood of Xcode, Cocoapods is now broken and your app is no longer capable of building with the new toolset without a lot of surgery.

On a lesser level, let’s say Cocoapods switches from Ruby based spec files to another format (JSON?). Now I’ve got to spend client time just fixing my build system, which isn’t adding much value to their product.

Are these scenarios this likely to happen? I hover somewhere between ‘maybe’ and ‘probably not’.

Contracting vs Personal Projects

Having described how I analyze third-party dependencies and my thoughts on Cocoapods in general, I will say that I am now using it in Glassboard.

Wait. Didn’t I just say it’s risky to use?

Well, yeah. But dealing with risk is a key part of software development. You have to find your personal threshold and work with it.

In my case, I’m not willing to stake the dependency management of a project I’ve been contracted to build by a client on a third-party platform that generates Xcode workspace and project files on the fly and may prevent the app from building cleanly without a 5+ step setup process. For my own projects, however, I’m much more liberal in my choices.

Let’s say the mythical Xcode 6 build breakage occurs in Glassboard. It will suck, but it’s a problem to resolve in my own product, on my own dime rather than someone else’s.

My personal projects likely also have a longer shelf-live than most client engagements where the codebase evolves over time. Glassboard’s code base is over three years old and is still evolving. Many of my client engagements are to build a shippable version and then move on to the next thing. There’s likely to be a lot of built up bit-rot after a project sits dormant for an extended period of time. Dealing with that rot is part of contracting as much as it is your own projects, but I do my best to limit the amount of rot I put on myself in those client engagements.

I apply the same ‘client vs personal projects’ principle to third-party code dependencies as well. I’ve taken to using the #GlassboardNext codebase as my playground for experimenting with new third-party projects like Cocoapods, ReactiveCocoa, and Mantle even though I can’t imagine a scenario where I’d currently use them a client project (well, maybe Mantle. It’s pretty isolated.)

It’s possible these choices will come to bite me in the ass eventually, but they’re risks I’m willing to take.

I’m assuming this post will get my invitation into the “Old Guy Coders Club” where you hate anything you aren’t used to. I’ll be waiting for my coffee mug and membership card in the mail.

You’re likely sick of hearing about the show “True Detective” by now. Like millions of others, I became engulfed in HBO’s latest 8 hour masterpiece over the last few months. Plenty has been written about the Yellow King, Big Hug Mugs, and Matthew McConaughey’s amazing performance as Rust Cohle.

What I haven’t seen get nearly as much play is how the show is actually created. It wasn’t fully aware to me until the 4th episode’s 6 minute long take scene (Spoilers behind that link). It was riveting the first time I saw it. It was even more amazing when I discovered it was done in a single take.

As I read up on the show I learned that the entire eight episode season was written by a sole writer (show creator Nic Pizzolatto) and directed by a single director (Cary Fukunaga). Traditionally TV shows are helmed by a cast of behind the scenes folks who take turns at writing and directing different episodes. With True Detective, a true auteur theory was allowed to play out on screen.

One writer. One director. Eight hours of the best television I’ve seen in a long time.

The best creative works, whether they be TV shows, books, or apps, are the products of focus and vision. At Apple that was Steve Jobs and Jony Ive. WebOS had Matias Duarte, who has been doing wonders cleaning up the mess that was the Android experience. James Dyson does it for vacuums. I just bought a Dyson and it’s a fantastic product.

As I look at my iPhone I can name the person in charge of the vision for most of the apps on my home screen. Here’s a hint: most aren’t from large corporations that include the marketing folks and bean counters as part of the development process. They are from small development shops run by just a few people who have an idea of what their product should be and how it can impact the world. There are no focus groups or A/B testing. It’s just gut reactions and validating it with user response.

Everyone has a role in the creation of a product (even the bean counters), but having one or two talented people charged with shaping the direction of the product results in something that people actually enjoy using and, more importantly, championing to others.

Who knows? You might even make something that puts a smile on Rust Cohle’s face. OK, maybe not.

Last week at Mobile World Congress Nokia unveiled the Nokia X, their first foray into the wild world of Android devices. On the consumer side, the sales pitch has been an affordable phone with all the great Android apps you love, just with Nokia and Microsoft services rather than Google’s. On the developer side, which was the obvious target of announcing this devices at MWC, the pitch was that it should take less than a day to port an Android app from using Google’s services for things like push and in-app purchase to Nokia’s.

On the surface, expanding your product into a new market with minimal effort seems like a great idea. Once you dig a bit deeper, it may not be so easy to justify.

Let’s say you have a product like Glassboard. Its core functionality is wrapped in a server-side component that you manage. The API is the key to everything else. It handles accounts, billing, data access, and all the notifications you need to send out.

The other parts of the Glassboard platform are the client apps. In my case, there are currently three: iOS, Android, and the web. I ran Glassboard’s Android app through the Nokia X Analyzer and had a pretty clean sheet. My biggest issues was replacing Google’s Cloud Messaging with Nokia’s offering.

Here’s where we run into issues. Building a version of Glassboard that uses Nokia’s jars instead of Google Play Services likely isn’t that big of a hassle. The much bigger hassle is then adding support on the server-side to handle the Nokia services.

Now, the “just a day” pitch becomes much harder to justify. Not only do I need to update the Android app, I also now have a slew of C# tests and code to write so that I can pass notifications from Glassboard to Nokia’s servers in additions to Google, Apple, and Sendgrid (our email provider).

Who Is The Market?

Any time I have to add another code path to the API and server components of Glassboard I have to really justify the work that’s involved. There’s usually four things I consider:

1. Who is the target market?
2. What’s the current install base?
3. What’s the potential installed base?
4. Would you use this thing?

The target market of the Nokia X is what the industry considers “developing nations”. The politically correct term is emerging nations because there’s plenty of room to grow, but the main point is that the Nokia X isn’t going to be on the store shelves in the US, UK, or Germany.

With a brand new platform, the current install base is zero. That’s not necessarily a bad thing as every platform starts from nothing at one point. In many cases, there’s a first movers advantage you can take advantage of.

That first movers advantage depends of course, on the potential installed base. This one was a toss-up for me. On one hand, Nokia is poised to put this in dozens of markets with millions of potential customers at an affordable price. On the other hand, Nokia is about to get sucked up by Microsoft who could snap their fingers and kill this project pretty easily. That’s a big risk.

The final question is more personal than business. I have always built software for myself, so asking if I would use a Nokia X is an important question. I’m curious about the device and would like to give it a shot. Would it be my main Android device? I’m not sure. I marked this one as a “maybe” rather than a hard yes or no.

Can You Make Money?

Once you’ve answered those four questions, you should be able to answer the most important question pretty easily: can you make money on the platform? More importantly, can you make enough money to justify the extra investment of time and resources in supporting it.

With Glassboard, my current belief is that no, I can’t.

Glassboard lives and dies by the amount of people that pay for some sort of premium subscription through the service. Since we have zero outside funding, the amount of users we gain isn’t an important metric. I’m confident that I could add several thousand free customers to Glassboard’s active user base by porting to the Nokia X. I’m much less confident that I can convert a decent percentage of those into folks that would be willing to pay for the service on a monthly or yearly basis.

That’s one of the key differences in running your company as a traditional business. Being on every platform is great if you’re a venture funded startup. If you’re bootstrapping, however, growth isn’t necessarily a good thing unless the financials are there to back it up. You have to analyze each different platform as a liability and justify whether its worth pursuing.

Simplifying Towards Profitability

This isn’t the first time I’ve had to do this sort of liability analysis with Glassboard. When I acquired the service, it was available on two additional platforms: the Kindle Fire and Windows Phone. I made the decision to kill both of these products for many similar reasons that I’ve opted not to tackle a Nokia X version at this time.

In the case of the Kindle Fire, the active user base wasn’t nearly enough to justify the continued investment. None of our premium customers were using the Fire version and that version also wasn’t equipped with any existing in-app purchase functionality, which meant I’d need to write more code myself.

That decision turned out to be the right one. I believe we’ve gotten maybe two total complaints about pulling the Fire version in the three months since it occurred.

The Windows Phone version of Glassboard was similar to the Fire in some aspects. The active user base wasn’t anywhere near the iOS or Android apps, but a decent chunk of the server components were already there. I’d have just need to add support for in-app purchasing to start upselling users to premium, which wouldn’t have been that much effort.

Ultimately the decision to kill the Windows Phone version came down to quality. It was not a good app. Given the small user base and the amount of time I felt it would take to make it an app I would be proud to showcase, pulling it from the shelves was the right move.

We get a few requests for a Windows Phone version a week still, so I believe there is some sort of market there. Whether they’re willing to convert to paid customers remains up in the air.

Focus on the Financials

As enthusiasts, it’s hard to avoid to allure of the new shiny. Updating an years old app to look and feel like an iOS 7 app makes sense as someone who loves to play with the latest stuff. Spending those days or weeks doing that conversion may not make financial sense if the product isn’t making enough money to justify the development time.

The same can be said for services such as Glassboard, and perhaps at an even higher level. With a freemium model, you have to think about every move in terms of its ability to convert free customers to paying ones. Free users are loss-leaders. If you have too many of those loss-leaders, you may have a popular product, but you don’t have a successful business.