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

“What you can see here is that I was learning…”

I love this post from swiftjectivec.com.

👉 Things I Made That Sucked

Not only does he detail the interesting stories of some old apps he made, but also the valuable lessons learned from each app that he shipped.

Highlights

Aim first, then shoot. “Ask yourself why you’re doing what you’re doing and channel your excitement into less action and more thinking before you fire away.”

Pace yourself and don’t complicate. “Take time to learn about design and holy moses don’t toss in an open source project just because it’s shiny.”

There is no overnight success. “Always remember that character is carved out rather than instantly created. Each of these misses can eventually add up to a win.”

My own lessons

Applying the same thought process to my own old sucky apps, here is what I come up with…

Where in the World is Santa Claus?

Ignorance is bliss. I genuinely thought it would be easy to make an augmented reality Santa tracker as my very first iPhone app. Who cared that built-in AR support on the iPhone was years in the future?

I understood that I’d have to learn Objective-C and Xcode as I went. However, I did not appreciate how much there was to learn about location APIs, motion APIs, audio APIs, audio editing, 2D animations, CoreData, the State Pattern, linear algebra 🤯, the terrors (at the time) of shipping in the App Store, plus legal/privacy matters. Also why not translate the app into six languages, starting with Spanish?

And all just to see Santa blink on your screen when you pointed your iPhone north. 😆

My blissful ignorance allowed me to jump in fearlessly and forced me to conquer a mountain of challenges as I went (or quit).

This app only ever sold a few hundred copies but was a goldmine of experience and made me a mobile developer.

Bedtime Balloons

Simpler is better. App #2 was more useful and less technically challenging than the AR Santa app. Bedtime Balloons let me get into some fun art and more interesting animations. Plus this app actually made a difference in at least a few people’s lives.

Third-party frameworks can kill your app. At the time, there was no standard 2D animation engine for iOS. SpriteKit was not a thing yet. 🤷🏻‍♂️ So just like the Santa app, I built the animations around the very nice Cocos2d engine, which would eventually morph and evolve and… break my app. 🤦🏻‍♂️ Yeah, I could have rewritten my app, but again only selling a few hundred copies, I chose to avoid all the sweat and tears and just move on.

Continuous Math Cards

Be practical. I never expected to sell many copies of my barebones but highly configurable math flashcards app for kids.

Written quickly in the new (at the time) Swift language, the app was alright. 🤷🏻‍♂️ But it worked for me professionally. My next step would be a full-time day job as an app developer, which had long been my dream.

Software Dev

The case for creating a merge commit

I’m always interested when someone has a strong opinion on how to merge code. I like this article because the author acknowledges that it’s just a matter of tradeoffs and then makes a case for a merge commit.

👉 The case for creating a merge commit

His basic argument is that a merge commit is the best of both worlds since it “maintains the small changes while allowing for 30,000 feet view of the history” with the --first-parent git log option.

But…

At the end of the day, what matters is to find a workflow that suits your team well and lets you deliver.

He also links to a couple of great articles on using small iterations (Kent Beck’s SB chages and GeePaw Hill’s MMMSS) that I need to blog later!

Software Dev

 Technotes

Looking for some tips on tricky Apple development issues like refactoring your storyboard, customizing the appearance of UINavigationBar, or an overview of the iOS Wi-Fi API?

Get it straight from the source on the new Apple Technotes.

Technotes are focused, timely documents from Apple Developer Technical Support. They explore a wide range of development topics and provide guidance for developers creating apps and accessories for all of Apple’s platforms.

Via iOS Dev Weekly.

Software Dev

Automatically resolve Xcode project file conflicts

Xcode project files are complex and not meant to be human-readable, so they can be scary to merge. When there’s a conflict, it’s never fun.

The tool Kintsugi intends to automatically solve these conflicts for you “99.9% of the time.”

👉Automatically merging conflicts in Xcode project files | github

The name Kintsugi (金継ぎ) is well-chosen, meaning “the art of repairing broken pottery by mending it with gold.” 🤯

Another interesting note: this project relies on a framework called Xcodeproj that lets you create and modify Xcode project files automatically. That sounds likes a better alternative than a homespun shell script. 👍

via iOS Dev Weekly

Software Dev

Debug network connections right from Xcode

Debugging live network traffic in your app is always interesting. There are some great apps for tracking your network connections, such as the cross-platform classic Charles Proxy, the more modern and Mac-assed alternative Proxyman, and even an embedded framework like Pulse.

And now with Xcode 13, you can forgo the third-party apps altogether if you so choose. This comes in especially handy if your company has third-party apps locked down. 🤷🏻‍♂️

👉 Check out Inspecting HTTP Traffic With Instruments

Or go straight to the source with Apple’s WWDC session Analyze HTTP traffic in Instruments.

via iOS Dev Weekly.

Software Dev

Why asynchronous programming is (was) hard

One of the most difficult things about mobile development is asynchronous programming, which means doing different things at the same time. This is not the normal flowchart-style sequence of traditional programming.

Weirdly enough, with Swift completion handlers, an asynchronous function exits before it finishes. Or if you’r not careful, it might never finish at all. 🤯

Oh no! This is entering annoying quantum mechanics territory. 😭

If none of this makes any sense to you, then you’re not alone.

All of this is why I love the following video from WWDC 2021. Nate spends the first eight minutes showing how downloading an image and generating a thumbnail quickly becomes “verbose, complex, and even incorrect” in traditional Swift programming. (Side note: I like how Nate apparently worked hard on his hand gestures as well.)

The payoff: Nate then explains how async/await will let you write asynchronous code basically like “regular code.” 🤩