Apple runs servers for managing iMessage key exchange, just like Google’s RCS encryption. Both of them use device attestation to restrict access to those servers to their own apps.
Their infrastructure is iMessage protocol specific, though, and that's incompatible with whatever Google does for RCS.
So either somebody has to build some new service bridging the gap, or RCS encryption is "serverless" in the way that e.g. OTR was, but unlike Signal (which needs explicit server support for managing pre-keys to bootstrap new connections while the recipient is offline, for example).
Some of their infrastructure is iMessage specific but things like account management, abuse mitigation, and device verification should have plenty of opportunities for reuse.
Think about it this way: you create an RCS message and hit send. Apple has to encrypt it now but all they have is a phone number. The phone number might belong to a local carrier or one on the other side of the planet. They need the public key associated with that number, right? Who has that? How do they get it? Who owns and manages that infrastructure?
That’s the same problem they have with iMessage: you can watch this the first time you use a new number and it displays green at first but switches to blue once it retrieves the other party’s key. That happens by connecting to Apple’s servers, which seems likely to be the same thing they’d do for RCS.
Another function which is the same: you connect to the server to register your device to your account. It uses hardware attestation to verify that the hardware is what it claims, trying to make spammers have to buy physical devices and to prevent spoofing.
