Up to now, I believe, these systems were not first-party but built by the manufacturers of the infotainment systems. Now, Mercedes is taking this in-house to get it right and integrate it with the rest of the far more properly?
I don't really have any more faith in Mercedes than I do with infotainment systems.
I don't doubt that they have amazing org knowledge around integrating data systems, but how are they with... any of the myriad of other components of operating systems?
BMW's is alright IMO. Unorthodox in its layout but it actually works well with the center console knob thingy and has historically been low-latency even back when every other manufacturer had a 2 second delay for every action on their awful touch screens.
Of course even BMW's system is still going to end up being an overly expensive Android Auto/Apple CarPlay launcher because what people want is Waze & Spotify, not random traffic updates from last week & DAB.
Even with (more) UX engineers, it was incredibly difficult to get any development done. When I was in this space, management and contractors were incredibly entrenched playing political games to grow teams even bigger to get more funding. There was nobody with any authority using the thing end-to-end saying “this sucks”.
CarPlay and Android Auto aren't car OSes though, they're merely an infotainment interface. You still need a way for the user to check the tire pressure, choose between sports mode and eco mode... Cars manufacturers could just implement the basics and let CarPlay/Auto do the rest but in that case anyone that doesn't have a compatible phone is stuck without infotainment, same if you run out of battery.
CarPlay and Auto being so good is somewhat to blame for first party interfaces being that bad though: why spend litteral millions on look and feel if you know the users who care won't be using it
Yes, this is a good point. I think the best way to do it is to have the car controls visible at all times, with the CarPlay/Auto interface wrapped in a frame. This is how Jeep does it.
It's worth mentioning that Android Auto doesn't work on GrapheneOS due to the privileged access it requires, and will not support it unless it is re-architected. Which phones were you thinking of when you said "compatible"?
I'd be curious to read more about the context of this. It looks like there are soo many low hanging fruits for anyone with mid-level technical seniority to step in and improve the situation measurably. Scala isn't bad but sbt definitely has plenty of (avoidable in hindsight) footguns. The tooling ecosystem of Scala has also improved leaps and bounds in the last couple years. Of course that doesn't do anything to the seemingly disfunctional organization but like the engineering post it was, it didn't concern itself with it much.
While I agree that first party systems suck, as someone with neither an iOS or Android device I personally prefer something work rather than a screen that says "connect iOS/Android".
Because with QT you can have a propriatary mess of incomprehensible spaghetti code. And it's unknown by competent front end designers which means the back end guys can have all the fun!