There is no .net version of RAAT. It’s C/C++ on all platforms. Porting it to iOS is easy. The problem is packaging it up in a way that makes a good user experience.
iOS apps get suspended when they go into the background. Apps that are playing music right now are allowed to be running in the background, but they get suspended when the music stops.
So think about the user experience: your zone would only be visible when:
- The app hosting the RAAT zone is in the foreground
- OR Music is playing
There are two places we could put RAAT
- Inside of RoonRemote
- Outside of RoonRemote in a separate RoonBridge app
If we put it outside of RoonRemote, then as soon as you switch to RoonRemote, the zone disappears because the RoonBridge app gets suspended. That’s no good, because then you can’t reliably pick music for the RAAT zone from the phone itself.
All you could really do with an iOS RoonBridge app is park it in a dock, leave the RoonBridge app on the screen and control it from elsewhere. Neat, but not that interesting. The really bad thing about that app is that people who are looking for the “control + playback on the phone” experience will be able to get themselves into really confusing situations trying to use RoonRemote + RoonBridge at the same time since their zones will be getting suspended at inconvenient times by iOS.
If we put it inside RoonRemote, we get clicks + pops because the .NET runtime mucks around with the audio playback.
On all other platforms, we separate the RAAT code from the heavyweight Roon process–this is what RAATServer is on win/mac/linux. On Android we run RAATServer as a service and isolate it to a second process so the .NET stuff doesn’t impact it.
On iOS, rules are rules. I know that we are better listeners than Apple, but that doesn’t mean that we are necessarily in a position to fix or work around their platform decisions. I know it’s frustrating–it is for us too. I wish we could just release this thing and stop discussing it.