rqlite[1] author here. Just to be clear, rqlite is not SQLite but rewritten in Go. rqlite uses the vanilla C code, and calls it from Go[2]. I consider that an important advantage over other approaches -- rqlite gets all the benefits of rock-solid[3] SQLite. As result there are no questions about the quality of the database engine.
That would be interesting for sure, but considering you don't hear yourself the same way someone else or a mic does, I'm not sure it would have the benefit you're expecting.
Phones in Japan used to receive actual TV. Well, slightly different, but still directly from the waves rather than the internet.
Phones used to receive AM and FM, too.
Some still can! Usually more low-mid teir devices.
Some of the higher end ones (such as my phone, which is how I know this) have the AM/FM signal processor built into their SoC, but the pins aren't wired to an antena.
I have both and they're surprisingly essentially the same size. Except the iPhone has less bezel and is thicker. I only have the iPhone for dev purposes and I actually prefer the Pixel 3a, but I'm afraid it might die soon...
Anyways, are you sure you're talking about the iPhone 16?
Some developers are lazy. Some probably don't know that that is the right way to do it. There is a lot of legacy code from when checking user agents was more acceptable. It is much more difficult for server code to know the capabilities of the client (although in practice this isn't usually much of an issue).
Also, sometimes the feature exists so the feature check is positive, but there is a bug in one browser that breaks your functionality, so you put in a user agent check. Then the bug gets fixed, but the user agent check isn't removed for years. I've seen that happen many times.