Hacker News Reader

Comment by yreg | Hacker News Reader

The apps are broken serverside by Facebook. No amount of testing (automated or not) on the side of the app developers would have prevented this.

Facebook's own apps did not break since they are on the latest version of FBSDK.

What Facebook needs to do is to test whether their changes don't break other people's apps.

View on HN

1. Server-side APIs can be versioned. If an old version is somehow changed, I would call it plain malpractice and in some other industries your license to practice could be stripped.

2. Client-side SDKs can be designed in a way that even if the server-side changes (which it shouldn't), it does not cause the whole application to crash. This can of course be hard depending at which level the SDK operates and how integrated it is into the app.

3. Are there no contracts between Google/Spotify/etc and Facebook? If I were FB and there were contracts on the line, I would make sure that there is no way something like this can slip through (automated testing).

> What Facebook needs to do is to test whether their changes don't break other people's apps.

I'd argue this is at the very core of why you test. I mean this problem is as simple as (n+1).m vs n.(m+1) in terms of versioning vs revisioning.

If that is not being tested then I'd say Facebook isn't actually testing at all - at least not in a practically relevant sense ...

... despite the shit-load of YouTube videos from FB devs lecturing about CI/CD and what not.

Sounds like you have it backwards. They use other people's apps to test whether their changes break Facebook.

It is not acceptable to have your client crash due to server-side stuff going on. When the server is faulty the client must handle that gracefully, like disabling the functionality or displaying a message about what is wrong if no further use is possible due to the error.

I disagree. While, yes, Facebook needs to test their SDK, app developers need to build resiliency into their apps to ensure third party dependencies don’t break their app. The developer adopted it into their app; it’s their responsibility to do the proper checks in cases like these where Facebook broke things on their end.

This is a native SDK that is crashing the process. There is nothing an app developer can responsibly do to prevent or recover from this crash.

Other than remove the SDK, of course.

Yes there is: a remote kill switch that prevents the third party SDK from loading. That puts you back in control of the software you’re shipping.

Fool me once, and all that.

You have to be technically competent enough to know how to dynamically load a framework, though.

And most SDKs are provided as static frameworks. You have to be technically competent to know how to wrap a static framework as dynamic, and then use dlopen to load them properly with a rather high one-time runtime cost. A mess.

For a tech company with a multi-billion dollar valuation this shouldn't be insurmountable

Facebook knows how dynamic loading works. (At least, I think so…) However, their many clients may not, as a lot are not multi-billion dollar companies.

So there is no way to try {} catch {} it, right?

Not in this case, as it's not code explicitly called by the client, but automatically loaded on app launch...

Yes, but 1. it’s hard to inject that as the crash happens very early at launch and 2. Objective-C exceptions of this type are not intended to be caught.

That's not strictly true, and anyway it's different for the app developer versus a library provider. If you're making a 3rd party SDK that can throw, you need to make it can catch those throws.

NSInvalidArgumentException is not intended to be caught. You can, of course, but receiving one indicates a serious run-time error.

If it's an objective C exception, you can catch those with an objective c wrapper function. Ive done that before in my Swift projects.

> Other than remove the SDK, of course.

Bingo! App developer voluntarily pulled in a dependency which they didn't fully understand. When you bring in a dependency, it's not still someone else's code/problem, it becomes your problem.

Ah yes.

If hacker news goes down while you are writing this comment, it is your responsibility to ensure you can still post your comment despite the service breakage.

Unless your app is designed for browsing Facebook, there's no reason that anything on Facebook's servers should affect if your app works.

Many of the apps crashing are using Facebook for a portion of their app, such as one login option.

Letting that take down the whole app is insufficiently defensive coding, whether in the app, sdk, or glue between them.

> there's no reason that anything on Facebook's servers should affect if your app works.

Absolutely, but the problem is that in order for you to use these features, you're supposed to use the official Facebook SDK. The additional problem, is that Facebook has no interest in defensive coding, because if you're not interacting with Facebook in an app, there's no benefit to Facebook for you using that app at all.

How do you defend against abort() in library code?

Don't include libraries which contain such code?

No abort here, the crash is coming from the runtime, which you’re not opting out of if you want your app to work.

Then we can agree the FB sdk should have been better written to avoid this, right?

Obviously, and now we agree!

So how could the app developers have prevented this, other then not using the SDK? (I'm not advocating for using the SDK.)

Would disabling SDK autoinit have fixed this? That was a suggestion raised back in March. Seems like a net win to avoid static initializers in the first place.

(Am not a mobile dev, but it wasn't exactly hard to find that, either).

Maybe (although some people report that not working), but not necessarily, as "autoinit" is just an if case checked in the same auto executed code in the Facebook SDK, which could still crash before the flag is checked.

Are you telling me that Facebook Inc. has no capacity or ability to test their own, one of the most popular SDKs in the world, in the wild? Like have a single phone connected by USB and open spotify app and simply login after they make a backend change?

By app developers I mean the consumers of FBSDK, not Facebook.

The truth is, 1st-party apps are well-supported but 3rd-party SDKs provided by these companies, especially the ones don't generate revenues (Facebook SDK, and many others) are simply not well-supported within the organization. They are not dogfooded, they don't develop with the latest and greatest tools available for 1st-party apps, some of them have very spotty CI, and often their release schedule is not as rigorous (many 1st party apps adopted weekly release schedule).

I would disagree that the 3rd-party SDKs don't make revenue for Facebook. They likely provide additional targeting and behavioral data that feeds into their giant ad machine and lookalike audiences.

That is a long chain. Internal promo doesn't work that way. That's why it is easier to get promoted when you work directly on ads.

Maybe don't include the Facebook SDK (Facebook Spyware Development Kit) in your tier-1 app?

1. Mock dependency

2. Throw exceptions

Don't tell me "No amount of testing" just because you aren't responsible for your own dependencies.

You can't mock it, that is the entire point. Simply loading the shared library of the SDK will execute the broken code.

90% of people in this thread think “native code” is a react plugin

I don't, but I'm fairly sure there is a solution and others just don't want to try hard enough

Can validate, no reasonable way.

Removed the SDK myself from a top 100 App Store app.

So an app (which you control), is told to load a shared library, and there's no way to handle that? Even by delaying the loading to only when it'll be used?

It's not "is told", it is "it is writen in the binary itself that the kernel/libc runtime should load the shared library".

To be fair, you don't have to do it that way. (Library loading is done by dyld, FWIW.)

Reply on news.ycombinator.com