IRC was designed, mostly, for two types of users: A) Large institution users who had a fixed link to the internet and ran in their shell on a mainframe. B) Dial-in users, who's devices mostly stayed connected, and when they disconnected, usually required manual intervention to get back on.
Anyone, and I mean ANYONE using a mobile phone SHOULD be using a 'bouncer' or other gateway to access a live communications environment. This would be more like use case A where someone has a small agent on a slice of a server they 'trust' and that maintains state (for their client) and stateful connection (for links to other servers and users).
IIRC, Quassel IRC has such a client/server model for the client, there are probably others too.
It occurs to me that if IRC networks hosted their own bouncers, but that these bouncers were written efficiently to exchange data directly with the IRC servers' and their database rather than keep individual logs and so on, we might have something close to the "open-the-app-and-see-past-messages-without-needing-to-be-permanently-connected" quality that people have come to expect from instant messengers, Slack, Discord, etc.
(but then you might as well just write such functionality directly into the IRCd)
Nah, such a thing would make most sense as a separate daemon that uses the server-server protocol to connect to the ircd (ie. it appears to the rest of the network as just another ircd).
It wouldn't be hard to build such a thing, the hard part would be convincing an existing IRC network to run it.
That's what SASL has been for for over a decade nowadays :)
So I had an android IRC app for a bit, some top paid one, and get booted from a bunch of my favorite channels because apparently it was just sat in my pocket cycling my connection and flooding the channel with join/unjoins.
That, plus the weird way to authenticate doing /msg Nickserv identify. That might be just how the server I was connecting to was implemented, but it felt fucky.