See this 2016 article for the cultural background: https://cloud.google.com/blog/products/gcp/adventures-in-sre...

1. https://support.google.com/googleplay/android-developer/answ...

So many problems here, and no signs of an updated SDK that behaves properly on malformed input.

These days however it feels a bit neglected, and somehow poorly bolted on to GCP. I still have a few production apps running on it and news like this reinforces my belief that it’s in decline.

What are folks using these days that (ideally) is open source and self-hostable? I don’t want to lock in with another platform. Some of these apps use the offline sync feature of Firestore (apps used in basements and other low-connectivity areas).

[1] https://github.com/binwiederhier/ntfy

Offline mode and cross-platform support are some of the features most important to me.

Be hyperbolic if you want, but there are LOTS of apps on the Play Store that do not have internet access, let alone a dependency on Firebase.

The real alternative there would be to use some SQLite syncing solution and a different solution for auth and cloud compute.

However, I remember saying to the VP who was leading the acquisition, “shouldn’t we decide what market we want to be in, then evaluate if we should build, buy, or partner?”

He said “no, we should buy it first then figure out what to do”.

I’m not surprised Firebase feels like it’s bolted on. They never really knew what they wanted to do with it. That was true then and it’s true now.

That's the dark side of these types of dependencies.

But they provide a great deal of utility, so I can understand the attraction.

https://news.ycombinator.com/item?id=23097459

This will be the new normal as all human “engineers” from staff to seniors are now down levelled to interns and junior engineers when using AI; unable to understand what they are doing and pushing broken updates like this into production with “agents”.

Better not blame Claude on this outage.

Why is it that iOS is crashing but not Android?

Google should know better to not have such an incident like this as the Firebase SDK runs on millions of apps.

If you did not implement a fall back mechanism, perhaps you based your testing assumptions on that “Firebase could never crash my app” which is now false.

Why didn't testing catch this? Why was there no canary? How come alarms didn't wake up an on call as soon as the call-volume on the backend dropped? Why was this update rolled out to every customer at once, instead of gradually?

Users who will forget about it, and due to inertia stay on your platform.

i've also heard "the prompt is the only thing that should be reviewed"

Small company is down? Time to move to something else. Pitchforks.

AWS goes down, or Google brings down half the internet? Well lots of other apps are down, so it's not a problem.

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

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.

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.

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.

If only it was just mobile development.