Bean counters took over, now it's maximum profit extraction until slow decline takes over. Decline in profit mind you, their software and service quality took a dive a while ago.

Apple's web services are shit, so I hope not. When it works it's great/okay, but when it breaks 5-10% of the time (that's about the rate AirDrop doesn't work for me) there's absolutely no indication what the hell is going on. Apple's allergic to progress indicators and useful error messages.

You can write your own crash reporter now.

Calling them a 3rd party push notification vendor is being generous. Google is still doing the push notification and I guess OneSignal offers a wrapper around the libs.

While Firebase has support for queries with realtime updates and offline caching, I wouldn't quite call it offline sync.

I wasn't aware that Supabase is self-hostable - thanks for pointing that out, will have a look. Customer is in Europe, if they decide to move away from Firebase, they don't want to migrate to another managed platform run by a US company (digital sovereignty etc.)

They’ve been accepting this for years and so have users

That's true. It's one of those phrases that, for example in an interview, an Indian might not be aware holds them back because of how jarring it sounds to the native speaker. My feeling is that while it's true it's effectively colloquial English in the subcontinent it's also appreciated if people understand rather than everyone being too polite to say anything and never coach the person. Well I'm here I will admit I love you the words thrice and the needful

So we have not learned anything since then, on both sides from the SDK builder side and the client side.

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.

The coding side of this isn't even the problem - that a broken change like this made it to production is an operational failure.

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?

And in many companies, if they move at a responsible speed (rather than the speed the AI vendors promise, if you let their tools work in yolo mode), that person will get replaced by someone who will just yolo it

No matter how many times this is said, the reality is that it is not true: no one will get blamed if the AI can be blamed.

there's a LOT of push from vibecoders to stop with PR reviews.

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

Just blaming AI seems to be the norm now, we have companies literally hacking other companies by "rogue LLM" and not getting any responsibility for it

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.

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.

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.

Yes, but the SaaS adoption is also the reason. Many analytics SDKs, observability tooling etc.

Well, you don't have to use the proprietary third-party SDKs in your apps... If you want analytics you can either implement your own, or use some open-source ones that aren't dependent on some third party backends switching some features on for everyone all at once...