Skip to main content

Why a small Facebook bug wreaked havoc on some of the most popular iOS apps

Why a small Facebook bug wreaked havoc on some of the most popular iOS apps

/

Facebook’s near-ubiquitous SDK broke yesterday, taking major mobile apps with it

Share this story

Illustration by William Joel / The Verge

Sometime around 6:30PM ET on May 6th, popular iOS apps from major companies like DoorDash, Spotify, TikTok, and Venmo suddenly starting crashing. The culprit didn’t remain a mystery for long.

Developers on Twitter and GitHub quickly discovered the cause to be an issue with the software development kit (SDK) from Facebook, which is interwoven into the operation of countless mobile apps from companies large and small. The problem, while resolved rather quickly by Facebook, illustrates the scope of the social network’s platform and how even minor issues can have major ripple effects throughout the mobile software industry.

“Earlier today, a new release of Facebook included a change that triggered crashes for some users in some apps using the Facebook iOS SDK,” a Facebook spokesperson told The Verge yesterday in a statement. “We identified the issue quickly and resolved it. We apologize for any inconvenience.” The Facebook SDK is a bundle of software tools for developers that helps power features like signing in with a Facebook account and providing share to Facebook buttons. So the issue was not unique to iOS; it could have happened to the Android SDK and, in this case, simply affected Apple’s platform.

Yet Facebook didn’t exactly say what the issue was or how the new release of the SDK could have triggered the crashes. It also wasn’t clear why so many apps were so detrimentally affected, even when the user experiencing the crash didn’t log in with Facebook or even when the app itself didn’t make ample use of the SDK or rely on Facebook features.

According to app developer Guilherme Rambo, the issue lies with the way Facebook markets its developer toolset. “Facebook really pushes developers into installing their SDK, likely because they want the very rich data they can collect on those app’s users. The SDK is offered as a convenience for both developers and marketing teams, since it can also be used to track the conversions of ads run through Facebook,” he explained to The Verge over email. (Rambo also has an analysis of his own posted to his website here.)

“I’ve never seen something of this magnitude where an SDK affected so many apps at the same time.”

For instance, he says, if you want to run an ad campaign for your mobile app through Facebook, the only way to get valuable insight into the campaign’s performance is to install the company’s SDK. “Another major reason is the infamous ‘sign in with Facebook’ we see in many apps, which can be implemented without using their SDK at all, but since using the SDK is more convenient, many companies end up going through that route instead,” he says.

But if there’s an issue with the SDK, as was the case yesterday, then it has the potential to take everything down with it. Facebook pushed a server-side change to its SDK, which meant no developer had any say in whether their app would be communicating with the older, stable version or the newer broken one. And because an app communicates with the SDK every time it is opened by a user, the result was a cascading series of errors that led to full-blown app crashes.

“The issue was that the SDK was expecting a server reply in a certain format, which on Wednesday, the Facebook servers were not providing,” wrote ZDNet’s Catalin Cimpanu, who cited technical analyses of the situation on GitHub and HackerNews. “Without the proper response, the Facebook SDK crashed, also bringing down all the apps that used it.” It also appears that, once affected, there was little any developer could do to restore service until Facebook fixed the issue on its end.

Rambo says there should be ways to prevent this from happening, including developers deciding to implement sign-in with Facebook without using the company’s SDK. But other system-level protections are decisions Apple would have to make regarding the permissions it grants third-party SDKs. “The way it works today is if you install an app and that app includes third-party code (such as the Facebook SDK), that third-party code has the same level of permissions and access as the app itself does,” he says.

“If you grant the app permission to access your location, contacts or calendar, the third-party code it embeds can also get that information. The only way to fix that would be to implement some form of sandboxing model that separates third-party SDKs from an app’s own code,” he adds. “It’s a big challenge, but I hope Apple’s engineers are working on something like that.”

Apple did not respond to a request for comment.

That said, developers did not seem especially pleased about the situation. “From what I’ve seen, developers are really frustrated about this, especially because the engineers who have to deal with these types of problems are usually not the ones who have decided to add such an SDK to the app they work on,” Rambo says. He adds that the decision to integrate with Facebook’s developer tools is usually a top-down decision, “many times from the marketing or product teams who only see the benefit of using those types of SDKs (more data, more analytics).”

But those types of employees at tech companies “don’t see the enormous amount of engineering hours spent dealing with the problems they can cause in an app,” he says. “Crashes caused by SDKs in major apps are not that uncommon, but I’ve never seen something of this magnitude where an SDK affected so many apps at the same time. I’d say this was an unprecedented event and it shows that something must be changed in the way apps integrate third-party code.”