Thread

1. Skwid · 1790672984 · focus · HN ↗

   I'm hearing an awful lot of "How could they do this to us?" and not a lot of "Wow, maybe we should have read some of this 3rd party code we bundled into 'ALLLL' of our apps"

   Just an ignorant and naive outsider's take, but to me it paints a pretty damning picture of the state of mobile development.

   1. freakynit · 1790673097 · focus · HN ↗

      Mobile and frontend development, both, now-a-days contain way way way more dependencies than they should.

      1. pranshuchittora · 1790674781 · focus · HN ↗

         Yes, but the SaaS adoption is also the reason. Many analytics SDKs, observability tooling etc.
   2. [deleted] · 1790673202 · focus · HN ↗

      [deleted]

   3. skeledrew · 1790674419 · focus · HN ↗

      > maybe we should have read some of this 3rd party code we bundled

      Not really practical though, if you push the thought to its limit. That 3rd party code is literally everything that's not written by you, from firmware to the launch UI. And if you don't push the thought to the limit then there's always that risk leading to the same "maybe we should've read X" if something happens in X. Trusting that others will be good stewards of all that 3rd party stuff is a hard requirement for making progress.

      1. alt227 · 1790675451 · focus · HN ↗

         I agree its not practical, but including any 3rd party libraries in your project puts it at real risk of upstream bugs. There needs to be acceptance of this rather than blame culture.
      2. Skwid · 1790683250 · focus · HN ↗

         I appreciate what you're saying. Commercial realities are very different to theoretical ideals, and of course you have to draw the boundary of trust somewhere to get anything done.

         I don't think anyone is saying it's an app developers responsibility to ensure the user's bootloader is securely implemented.

         There is a lot of space between verify everything and trust nothing, and I don't think it's unreasonable to question whether that trust boundary is in the right place.

         I also think that the code compiled to produce the binary you ship is a perfectly reasonable place to put that boundary, would you disagree?

         I'm sure that within the mobile dev world it is normal, accepted practice to include lots of unseen code. I don't begrudge anyone involve for taking the money and doing what's expected.

         But I still think it's a mad way to run a business or community project, and it's worth considering how we got here and whether it really has to be this way.

   4. bcye · 1790674823 · focus · HN ↗

      You're already trusting them with their proprietary cloud products, whose code you can't read. Why wouldn't you trust them with their client SDK code.

      1. jeroenhd · 1790675260 · focus · HN ↗

         Because their client SDK might crash the entire app if the server does something funky. We saw it before with Facebook, and now it's Firebase's turn.

         A dependency on code you can't read reaching out to servers you don't control is a recipe for disaster. If you can control the server, you can try to add fixes, redirect DNS to a backup cluster, you name it. If you implement the client, you can write the code in a way that doesn't cause full crashes when the remote server does something weird. If you can do neither, you're handing over your business flow and uptime to a third party that doesn't care about you in the slightest.

         1. bcye · 1790701437 · focus · HN ↗

            Well your database crashing isn't much better for your uptime really
   5. whstl · 1790692228 · focus · HN ↗

      > state of mobile development

      If only it was just mobile development.

Unofficial Hacker News client; not affiliated with Y Combinator.