Hacker News Reader

Comment by linux2647 | Hacker News Reader

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.

View on HN

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.

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...

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.

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.

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.

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.

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.

> 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.

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!

> 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.

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.

Reply on news.ycombinator.com