The cost of build & workflow problems

So many new technologies promise the ideal world of write once, run anywhere. Xamarin, React Native, numerous JS-based platforms. While the promise of writing once seems like a huge time saver, in reality these gains can easily be cancelled out with build problems and cumbersome workflows eating into development time.

Take an example I experienced recently on a native iOS app: to save time we used a library to do X. This library probably saved one week worth of development time (1x developer — 1 week), two at most — as we still had to integrate and work around anything that it didn’t quite do exactly as we needed.

Since introducing this library a year ago, it’s probably cost us around a month (4x developers — 1 week) in build issues that have blocked other work. E.g. We needed to upgrade xcode, which updated the Swift version, but then that meant the library version had to be updated. We wanted to use the library in an App Extension, but it didn’t have the necessary build flags, so we had to fork it. We hit github rate limits, despite being authenticated, because of something to do with its Carthage config and the way binaries are downloaded (or something like that). Imagine these problems with Xamarin thrown into the mix, the time lost could easily double.

By contrast, the Android (also native) team implemented X by themselves in about a week (1x developer — 1 week). It matched the requirements perfectly, and has had no issues whatsoever in the, same, past year.

Another example. I wrote an app called Carte. I wrote it natively for iOS and Android. The iOS version took some time to build, as we were kind of prototyping with it and iterating quite a bit (a bad decision, but that’s another topic) — probably 4–8 weeks spread over the course of a year (very) part time.

Once the iOS version was complete, I started on the Android version. This took 5 days to build and release. Now, by writing the app in Xamarin, how long do you think I’d have lost to build issues, library/version incompatibilities, slow build times, poor debugging, App Store rejections? It’d be more than 5 days.

Now, to maintain it and add new features you could argue that writing in Xamarin would now be saving me time. But to that I’d also disagree. One of the fantastic things about Android is Android Studio/IntelliJ (and to a lesser extent for iOS — AppCode). It is outstanding. It saves me hours per week due to it’s keyboard shortcuts, refactoring tools, and workflow plugins. Having tried Xamarin Studio on Mac a year ago, I know that using that would have slowed me down by a half. It just doesn’t compare to IntelliJ.

(I know that Visual Studio is also very, very good, so developing on Windows would workaround that, but then you’ve got the pain points of building on a remote Mac, and…er…using Windows)

These cases are the best way I can explain the need to question the benefit of the promises platforms/libraries make in the real world. Someone looking at the bottom line in a company only sees the write once claim, thinking it’d halve their costs, without seeing potentially huge caveats. When in reality, writing it twice can actually be the most cost-efficient solution.

(Saying all this, I am actually going to try Xamarin properly soon, once I get some time to put Windows back on my laptop, it’s just that I’m not very optimistic about it.)