Yes, because overloading HTTP(S) as a data layer for native apps leaves a ton of performance and security on the table. It's for web browsers, not every possible use case for sending a buffer of bytes from A to B.
People use HTTP because it's what they know, not because it's technically a good (efficient, reliable, scalable) approach for their particular use case.
It does make sense for apps that also have a web component, but that's becoming less and less necessary. When you can drop it, the possibilities are pretty amazing having a fully-capable computer with CPU equivalent to a 2010 Macbook Air at your disposal at the edge of the network.
I had to fight more than once against management in order not to use HTTP for everything. HTTP isn't even that simple to deal with. Good thing is that the numbers were always with me, and with code examples, it was always doable, but it's incredible how HTTP got its way in people's minds!
People use HTTP because it's what they know, not because it's technically a good (efficient, reliable, scalable) approach for their particular use case.
It does make sense for apps that also have a web component, but that's becoming less and less necessary. When you can drop it, the possibilities are pretty amazing having a fully-capable computer with CPU equivalent to a 2010 Macbook Air at your disposal at the edge of the network.
Hell, my latest project doesn't even use DNS.