iOS device - iPhone, iPad etc. as an audio playback device

I was very pleasantly surprised when the iPhone was added as a controller.

Unfortunately, that opened another idea. Whilst waking up this morning, was just thinking how great it would be if my iPhone could also be an “end point” playback device.

Is that a potential long term viable option?


Hi Mike,
@Brian posted these comments in the Roon 1.2 Feedback Thread.
So long term yes it’s a possibility.

I would like this too. I have an old iPad attached to powered speakers that I use for Tidal playback in my kitchen. Roon 1.1 does not show it as an AirPlay device (have not tried 1.2 yet), so I’d love to have Roon Bridge for it.

You could try something like Airfoil in the meantime.

1 Like

Yes, it is an option, but it does not appeal to me.

I had hoped 1.2 would allow us to stream music to the iPad. Am I right that this functionality was not included ?

As far as I understand. The iPad is a user interface surface, not an audio endpoint.

No it can’t, but it may change in the future. It’s complicated.
You can read Brian’s explanation here, I don’t understand it.
Cheers, Greg

Thanks Greg.

Hah. I only wrote that stuff because I know Anders is technical enough.

The less ridiculous version:

If we turned on playback on iOS right now, there would be clicks and pops and dropouts and sound quality issues.

We have a solution to this problem, and we use that solution on the other four platforms, but Apple won’t let us release it because of App store rules.

The root cause is an interaction between audio playback and the technology that allows us to deploy Roon across five platforms without doing five times as much work. This is a technology that we depend on for strategic reasons, not something we can migrate away from.

The people who make that technology are working on the problem. Once their fix is available, we can incorporate their latest code and see if it fixes Roon. It’s a complicated change for them, and they are an established team with lots of customers that depend on them to build stable infrastructure, so their pace is not super fast, but they are working on it.

@Brian - Why can’t RAAT end-point code be ported to iOS? Surely the version(s) of the RAAT end-point being using in most devices is not .net based.

1 Like

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.


Thanks for the additional details. I think an iOS Roon Bridge that can only run in the foreground is still better than nothing.

1 Like

Why do you have to use Xamarin as a platform for Roon Remote on iOS?

Because we use the same code for each platform, most of it is C# or other .NET languages, and Mono/Xamarin is the only mature way to run that code on non-windows platforms.

Tidal and Spotify allows streaming to BT speakers from iPhone/iPad therefore what is it they do that you guys are not doing that makes it work? I am just wondering if you could emulate their functionality on iOS devices.


Once the bugs have been shake out of the Mono/Xamarin software libraries that the Roon application is dependent on, it too will be able stream to iOS devices.

The development of Xamarin is not controled by the Roon devs, however, I believe there is activity by the Xamarin team to resolve this.

Great news!

Xamarin is now owned by Microsoft. Not sure what difference, if any, that will make for iOS and MacOS.

No difference other than it now being free for MSDN subscribers.

1 Like