undefined | Better HN

0 pointslinux26475y ago0 comments

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.

0 comments

monocularvision5y ago

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.

hyko5y ago

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.

saagarjha5y ago

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

2 more replies

XCSme5y ago

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

Sephiroth875y ago

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

saagarjha5y ago

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.

1 more reply

valuearb5y ago

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.

ryandrake5y ago

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

corndoge5y ago

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.

slipheen5y ago

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.

frenchy5y ago

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

corndoge5y ago

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

1 more reply

yreg5y ago

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

mattgreenrocks5y ago

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

Sephiroth875y ago

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.

j / k navigate · click thread line to collapse

0 comments

monocularvision5y ago

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.

hyko5y ago

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.

saagarjha5y ago

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

2 more replies

XCSme5y ago

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

Sephiroth875y ago

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

saagarjha5y ago

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.

1 more reply

valuearb5y ago

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.

ryandrake5y ago

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

corndoge5y ago

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.

slipheen5y ago

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.

frenchy5y ago

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

corndoge5y ago

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

1 more reply

yreg5y ago

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

mattgreenrocks5y ago

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

Sephiroth875y ago

j / k navigate · click thread line to collapse