Software Dev

Scaling up: how AirBnB ships a quality, gigantic app

AirBnB’s iPhone app has a gigantic code base (1.5 million lines of first-party code), a giant mobile team (75 iOS engineers), and a long history (first commit: 2010).

Over time, their app got so big and complex that the project began to take minutes to open (not build) in Xcode. Developers had to use the USB port on the right side of their MacBooks to avoid thermal throttling. ๐Ÿคฆ๐Ÿปโ€โ™‚๏ธ

Given all this sheer complexity, the team there made some clever adjustments to develop, test, and ship their app pretty efficiently. Check it out.

๐Ÿ‘‰ Designing for Productivity in a Large-Scale iOS Application

Among the highlights are independent modules called Dev Apps.

A Dev App allows a product developer to iterate on their featureโ€™s UI and much of its business logic while building a fraction of the overall Airbnb application.

Dev App for an existing Airbnb module

For dependencies across modules, module types allow for “visibility rules” to minimize and document dependencies.

Also, AirBnB uses the Buck build system to keep Xcode projects out of source control (bye bye, Xcode project merge conflicts).

via iOS Dev Weekly.

Software Dev

What Adding Dependencies Will Do To Your App in 2020

I like the title of this article because it recognizes that pulling third-party dependencies into your app has a cost.

๐Ÿ‘‰ What Adding Dependencies Will Do To Your App in 2020

And yet we all do it because it also has its benefits. ๐Ÿคฆ๐Ÿปโ€โ™‚๏ธ๐Ÿ˜‚

That article is a realistic and practical look how the dependencies affect your app in terms of app launch times, app size, and build times. It compares Swift Package Manager ๐Ÿค“, Carthage ๐Ÿคท๐Ÿปโ€โ™‚๏ธ, CocoaPods ๐Ÿ˜ฌ, manual dependency management ๐Ÿฅบ, and Git Submodules ๐Ÿคฎ.

I still have a dream of zero dependencies ๐Ÿคฉ, but I know it’s not realistic in a complex app. ๐Ÿ˜‘

Via iOS Dev Weekly.

Software Dev

Playbook

Developing features for a large, established app, I often run get slowed down trying to throw together a new screen. You have to find the right spot in the code to update, build the whole app (not just what you changed), log in, and drill down to the right spot to try out your creation. Something’s off? Do it all over again.

Which is why I love the idea of the Playbook library, which is “a library that provides a sandbox for building UI components without having to worry about application-specific dependencies.” Yass! ๐ŸคŸ

๐Ÿ‘‰ Playbook on GitHub

Supports both SwiftUI and UIKit.

playbook

Via iOS Dev Weekly.

Software Dev

Using Type Erasure to Build a Dependency Injecting Routing Framework in Swift

This post is just as weird and abstract as it sounds. ๐Ÿคฏ On first pass, I don’t get it. But I’m saving it here because I always like anything that promises easier dependency injection.

We’ll take an exciting look at how the treatment of methods/closures as properties can be used in this context to bypass one of the Swift Compiler’s most annoying compilation errors.

๐Ÿ‘‰ Using Type Erasure to Build a Dependency Injecting Routing Framework in Swift

Type Erasure is the process of abstracting constrained, generic types inside an unconstrained non-generic type that can be passed around freely

Via iOS Dev Weekly.

Software Dev

DI with Interface Builder

In this dated but thorough Objective-C dependency injection article is a reference to a rather old article asserting that Xcode’s Interface Builder is their “favorite di framework of all time”.

๐Ÿ‘‰ Dependency Inversion Principle and iPhone

I keep feeling frustrated by the added complexity and extra code involved in dependency injection. It can make simple code complex very quickly. So I really love the idea here, which is that Xcode is perfect for DI because it lets you literally just wire up things visually with no extra code. It goes on to make the case for using Interface Builder to wire up more than just UI elements and use it for just about anything.

Whatโ€™s great about it is that it doesnโ€™t just generate a bunch of code, but instead โ€œfreeze driesโ€ real objects to be instantiated when the program loads.

This article is so old that the images don’t load, but I love the ideas and the reminder that DI does not have to involve a bunch of extra code. Thanks to iOS Dev Weekly for the initial link. ๐Ÿ‘†