3 ms·
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
by yreg 6y ago
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.
- akerro 6y agoAre 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?
- yreg 6y agoBy app developers I mean the consumers of FBSDK, not Facebook.
- linux2647 6y agoI 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.
- corndoge 6y agoAh 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.
- slipheen 6y agoUnless 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.
- corndoge 6y agoHow do you defend against abort() in library code?
- Nextgrid 6y agoDon't include libraries which contain such code?
- frenchy 6y 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.
- yreg 6y agoSo how could the app developers have prevented this, other then not using the SDK? (I'm not advocating for using the SDK.)
- mattgreenrocks 6y agoWould 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).
- Sephiroth87 6y agoMaybe (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.
- monocularvision 6y agoThis 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 agoSo there is no way to try {} catch {} it, right?
- Sephiroth87 6y agoNot in this case, as it's not code explicitly called by the client, but automatically loaded on app launch...
- valuearb 6y agoIf 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 agoYes, 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 agoThat'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 agoNSInvalidArgumentException is not intended to be caught. You can, of course, but receiving one indicates a serious run-time error.
- 6y ago
- emerongi 6y ago1. 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).
- mrtksn 6y agoIt 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.
- rv-de 6y ago> 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.
- vsareto 6y ago1. Mock dependency 2. Throw exceptions Don't tell me "No amount of testing" just because you aren't responsible for your own dependencies.
- mschuster91 6y agoYou can't mock it, that is the entire point. Simply loading the shared library of the SDK will execute the broken code.
- vsareto 6y agoSo 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?
- mschuster91 6y agoIt's not "is told", it is "it is writen in the binary itself that the kernel/libc runtime should load the shared library".
- saagarjha 6y agoTo be fair, you don't have to do it that way. (Library loading is done by dyld, FWIW.)
- adamparsons 6y ago90% of people in this thread think “native code” is a react plugin
- vsareto 6y agoI don't, but I'm fairly sure there is a solution and others just don't want to try hard enough
- 6y ago
- tpmx 6y agoMaybe don't include the Facebook SDK (Facebook Spyware Development Kit) in your tier-1 app?
- jayd16 6y agoSounds like you have it backwards. They use other people's apps to test whether their changes break Facebook.
- liuliu 6y agoThe 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).
- nathanyz 6y agoI 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.
- liuliu 6y agoThat 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.