4 ms·

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 remov

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.

XCSme 6y ago
So there is no way to try {} catch {} it, right?
- Sephiroth87 6y ago
  Not in this case, as it's not code explicitly called by the client, but automatically loaded on app launch...
- valuearb 6y 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.
- saagarjha 6y 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.
  - robterrell 6y ago
    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.
    - saagarjha 6y ago
      NSInvalidArgumentException is not intended to be caught. You can, of course, but receiving one indicates a serious run-time error.
hyko 6y 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.
- saagarjha 6y ago
  You have to be technically competent enough to know how to dynamically load a framework, though.
  - bognition 6y ago
    For a tech company with a multi-billion dollar valuation this shouldn't be insurmountable
    - saagarjha 6y ago
      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.
  - liuliu 6y ago
    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.
ryandrake 6y 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.

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.

XCSme 6y ago

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

Sephiroth87 6y ago
Not in this case, as it's not code explicitly called by the client, but automatically loaded on app launch...
valuearb 6y 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.
saagarjha 6y 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.
- robterrell 6y ago
  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.
  - saagarjha 6y ago
    NSInvalidArgumentException is not intended to be caught. You can, of course, but receiving one indicates a serious run-time error.

hyko 6y 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.

saagarjha 6y ago
You have to be technically competent enough to know how to dynamically load a framework, though.
- bognition 6y ago
  For a tech company with a multi-billion dollar valuation this shouldn't be insurmountable
  - saagarjha 6y ago
    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.
- liuliu 6y ago
  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.

ryandrake 6y 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.