> "all 3rd-party libraries are a potential liability."
Yup. Even if they are responsive today, doesn't mean they will be, tomorrow.
My views on The Dependapocalypse are not usually welcome, in modern discussions of software strategy.
Not exactly sure why they are using string(describing:) in ship code. I suspect the architecture may need a bit of a look-see.
I only use it in debug tracking. It's the reflection API, and that's not really something I'd consider for runtime. Sort of like using exceptions for branching. It works, but your results may not be optimal.
UPDATED TO ADD: I did think of one place I might use it (actually, the ".description" computed property), and that's in a "one-off" bit of code that may be doing something like figuring out how to deal with some JSON I parsed, or reading stored prefs. Otherwise, I've usually figured out other ways to deal with it. One advantage I have, is I seldom use third-party libraries, and can actually go into my modules, and tweak them to serve the frontend better (in fact, I just did exactly that, this morning).
I've fixed similar performance problems, typically the reason people use this is because it's a convenient way to get the name of the type or because they are logging it somewhere and get the default Swift behavior.
I don't think we can conclude from this that there's anything wrong with the third-party library people... there are tradeoffs and doordash probably isn't their only user. Doordash may not be paying or contributing either. Maybe the 3rd-party library people could have sent a basic "Thanks for the feature request" reply for the sake of politeness... But lacking that polish doesn't make them "selfish".
> Maybe the 3rd-party library people could have sent a basic "Thanks for the feature request" reply for the sake of politeness... But lacking that polish doesn't make them "selfish".
Why would they? I mean, when was the last time you got a "thank you" message by opening a feature request to any open source project bug tracker?
I am going to guess it is google maps. Here is a non-exhaustive list of frameworks they have in the app:
- Google Maps
- Persona
- InstaBug
- CardVerify
- SendBird
- Stripe
- Google Sign-in
- PhoneNumberKit
- Riskified
- VGS
"The third-party framework in question had a total of nine module initializers". I would guess it is probably google maps simply because they tend to do things like this and IIRC you have to setup in the startup even if you use the map later.
Might have missed some frameworks but I think I got most of them.
Edit: maybe not google maps... it seems that 200ms added to any app that uses it would be fairly noticeable. Perhaps one of the lesser used ones.
If you have an iPhone and a Mac, you can use Apple Configurator to download the App Store .ipa. You can unpack that like a zip file and look at the dynamic frameworks it contains.
I'm with you, but I also think that discussion about specific tools often is wrongly prioritized over discussion of general principles. The lesson should be "always profile your programs, and be especially wary of third-party dependencies" rather than "avoid this specific library at all costs."
I'm assuming they also understandably don't want to start a flame war, where their specific criticism of the library is going to be taken to mean "this library is always bad, do not use it, even if its effect on performance is negligible in your case."
I'd put my money on either the Facebook SDK or a crash/bugreporting tool. They say it's important to UX, and both of those are (for sign-in-with-FB, or bugreporting).
No FB SDK, they do have a bug reporting tool - but you always would want it to init immediately simply to catch those crashes which occur before the rest of app setup. It is unlikely this. My money is on google maps.
