Software Dev

The what, why, and how of the RIBs mobile architecture

Continuing my mobile architecture kick, let’s look next at RIBs. In this case, RIBs is not a delicious, slow-cooked entrée but rather a software architecture that Uber developed a few years ago. It lets their 200+ mobile developers knock out features quickly without stomping all over each other.

Why RIBs?

The original design worked well for the first three developers. (via Uber)

Back in 2016, the Uber team had quickly expanded from three mobile developers to 15 to several hundred. But the app’s design did not scale well. It became difficult to add features, from both a UI design and a technical perspective. Citing “quite a few examples of, you know, pretty bad UI”, the design team bravely demanded a rewrite.

The design team came in and said, you know, ‘We probity have to redesign the whole application.’… Everybody was super concerned.

Classic engineering understatement

The Uber engineering team resisted the rewrite (which can be nightmare on a large app) for a year, but eventually came around to its necessity. So they defined a few goals for the new design (99.99% reliability, scaling to ~1000 developers, …) and experimented with that they knew – MVC, MVVM, MVP, and VIPER.

Nothing worked. 🤦🏻‍♂️

The problem is that all these architectures are based around the view, and if you base everything around the view, everybody has to integrate at one point, and that becomes a mess at the scale that we have.

The state tree solution

So they came up with a fresh idea, which was to model the whole app as a state tree. Much to their surprise, it worked really well. 🤷🏻‍♂️

We haven’t found an application that you couldn’t model with this very nicely.

The crack architecture team spent six months reworking some “super ugly looking” core app flows, and then turned the rest of the team loose on the new architecture.

And now we have RIBs and the modern Uber app.

Whoa! That looks too easy! (via Uber)

But how does it work?

A RIB is a combination of Router/Interactor/Builder (plus Presenter/View, but I guess “RIBPV” doesn’t sound very good). Each RIB represents a state of the app, which can have sub-states as children.

For example, the root of the tree has two children: logged-out and logged-in. Every RIB under logged-in can safely assume that the user is logged in — and it has an authenticated user token to prove it. 🔑

RIBs present themselves hierarchically on top of each other on the screen. Or some RIBs just do background support don’t show themselves at all.

No auth token for you, left side. (via Uber)

For more…

Pretty cool, eh?

Okay, I’ll stop here since this is a conceptual overview (aka a teaser) and not a tutorial. ✋ For more details, see the original Uber presentation below or try it yourself at the RIBs GitHub repo.

Up next in the architectural series, we’ll attack The Composable Architecture, which is responsible for at least one cool game and, like RIBS, has a concrete implementation rather than just a bunch of vague ideas. 🙏

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

Mobile Native Foundation: Developing Large-Scale Apps

Writing apps for a large organization has its own unique challenges.

Large teams require that you collaborate in complex ways while keeping quality and delivery speed high. It’s not straightforward, and it makes the days of knocking out an app on your own look fun and easy, if somewhat solitary.

@MobileNativeFoundation

It’s not just about “data structures and algorithms” or any of that Computer Science 101 stuff at this level.

The Mobile Native Foundation is a new organization that focuses on large-scale app development issues for iOS and Android.

It’s mostly just discussion groups right now, but they have contributions from people at large companies with apps you know and respect such as Lyft and Spotify.

The discussions cover relevant topics ranging from organizational (such as Encouraging and enforcing testing), to design (Building Modern UI), to technical (Splitting an app into modules).

👉 This site also reminds me of a book on large-scale app development that I’m currently working through: Building Mobile Apps at Scale.

Via iOS Dev Weekly.

Software Dev

The Singleton Pattern – When There Can Only Be One ☝️

Like so many smart and courageous people, the Singleton design pattern is often misunderstood.

Whether it is attacked as an anti-pattern, maligned as untestable, or misused as a global convenience, singletons take a lot of 💩 for just being what they are: a way to enforce that there is only ever one of something. I think they should call this pattern “The One”.

A real life example of a singleton is The President of the United States. We only ever have one president at a time. That’s a key part of the concept. It’s not just a convenience.

In software terms, singletons make sense in many cases such as the one and only instance of the current app running on the current iPhone.

With all this in mind, this quick post provides some nice context about singletons (aka the President) versus just a shared instance (hey, let’s all share this one bike) in Swift.

👉 What’s the difference between a singleton and a shared instance in Swift?

Thanks to iOS Dev Weekly for calling out the ongoing confusion on this topic. 🙏

Software Dev

Learn to Love Throwing in Swift

I really like the points made in this article about Swift error handling: using throw/try/catch is actually much better than returning optionals or the new Result type.

👉Benefits of using throwing functions (try) – Swift’s most underrated feature?

Throwing errors, when used throughout your codebase, helps you reduce and simplify code. It makes your unit testing easier too.

As a former Java programmer, I have to admit some hesitance to throw anything. Java error handling can turn into a nightmare of its own.

But the author makes some compelling arguments why throwing might make sense in Swift. Error handling is never fun; let’s do it the easy way. 🤷🏻‍♂️

In a related note, Re: Making Wrong Code Look Wrong also talks about the benefits of throwing in Swift, in particular with relation to local reasoning. 👍

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

Reducing Your App’s Memory Footprint

Retain cycles, timers, big images, caching. These are a few reasons why your app might be using more memory than it should.

It might be a good time to audit your app and see how much memory it’s really using.

Lazy loading, implementing memory warning methods, using NSCache, autorelease pools. These are a few ways to deal with it.

Also, let’s say, just make a clean, focused software design. 🤷🏻‍♂️

👉 How To Reduce Your App’s Memory Footprint