Hello, after the last support call, where ARC was stable for about a week, the same problems have returned. With my iPhone 14 Pro Max or iPad Air 4, the phone overheats and the battery drains very quickly.
When it does work, it usually only lasts for a minute and then the application closes.
One way I found to make it work for a while is to do a clean install of ARC, leave the iPhone screen always on with the brightness at minimum, and not be able to use the iPhone or switch between applications.
In the last support call, they concluded that this is due to my library being very large, around 870k tracks.
, yesterday I tested ARC on my account with an Android phone, a Motorola Edge 30, with much lower hardware than my iPhone, and ARC worked perfectly. The phone didn't overheat, the battery didn't drain, and it didn't close at any point.
In other words, we are clearly dealing with an ARC problem on iOS.
I don't know what to do anymore, my phone's battery has lost a lot of performance and I'll have to replace it, because using ARC is so damaging.
Thanks for reaching out. Can you please confirm what you are referring to when you mention last support call? Was this one of your previous threads? Did anything different occur when ARC was working as expected vs it was not? Do you also happen to have a large amount of playlists or anything similar?
Hi Noris, yes, I was referring to the last support call. I didn’t do anything different; it just seems like the app stabilized that week. Since I only use Arc on weekends during my second set at the country house, when I returned the following week, the symptoms of the phone overheating, battery drain, and the app crashing started happening again. I have about 20 or 30 playlists, mostly from Tidal and Qobuz, only 3 or 4 from Room, but look, how did it work so well on an Android phone? Same account, same library. It has something to do with the iOS app. My library has about 870k tracks; it’s large, but again, it worked perfectly on Android.
Note that we’re unable to guarantee full functionality with a library that large - we expect the right hardware will work, but it’s not something we test in-house.
Are the network conditions the same between both devices?
Feel free to share a more specific date, time, and name of track playing around when the issues occur again, and we’ll enable diagnostics to take a closer look.
Yes, I tested both devices this afternoon, both on the same Wi-Fi network. I tested the Arc device while it was on the same network as the Roon server, and the problem occurred there every time I tested it.
There was a recent update to Arc where one of the reported improvements was overheating on devices, but unfortunately, nothing changed on my iPhone. I can only use it for a single day, with a clean install. I have to leave the iPhone with minimum brightness, the screen always on, and I can’t use the phone; Arc needs to be in the foreground at all times. Anything outside of that, the app closes abruptly, and after closing once, it will repeat itself constantly. Another thing I noticed is that when the phone is at room temperature, it takes longer to close. Perhaps it’s even a defense mechanism of iOS; I don’t know why, but I’ve never seen an app heat up an iPhone so much and so quickly. With an ambient temperature of 15° Celsius, after about 1 minute of using Arc, the phone is already boiling in an area near the cameras, which I believe is where the processor is located.
If you could, I’d test out temporarily setting your local library at about 100k tracks, and then set up a fresh instance of Arc on the iphone and test how things perform.
Hi Benjamin, this procedure was suggested in a previous call, but I don’t think it’s productive for my case because I’m not going to reduce the size of my library to use ARC. Furthermore, it worked perfectly on an Android device with much weaker hardware than my iPhone. Do you have any knowledge that ARC is more stable on Android devices than on iOS?
To understand where the bottleneck is happening, we need to narrow down when exactly the overheating and app closures occur. Since your Android test showed stable behavior, the next step is to isolate which tasks on iOS are triggering the load.
Could you please check the following and report the results:
Open ARC and do not play anything.
Leave the app open for 2–3 minutes.
Does the device start to warm up?
Play only locally stored tracks in ARC (no streaming).
If possible, download a few tracks in ARC, enable Airplane Mode, then play.
Do overheating/crashes still occur?
Play from your local library vs. TIDAL/Qobuz streaming.
Does the behavior change depending on the source?
Check if overheating occurs only when browsing certain sections:
For example:
Albums
Artists
Tracks (especially with very large lists)
Search
Which pages consistently trigger the temperature rise fastest?
These details will help us pinpoint whether the issue is related to:
UI rendering of large library lists,
background streaming tasks,
library sync cycles,
or iOS thermal management behavior.
Once you’ve tested the above, please also send us your iOS ARC logs after reproducing the issue once more:
We’ve reviewed this case after escalation and internal discussion. Here’s the unfortunate reality: a library of 800k - 1 million tracks will, sadly, likely never sync reliably with ARC.
This isn’t a question of making ARC more efficient at syncing or improving the app’s framework. We’re up against a real development limitation with smartphone apps. Syncing a library in the realm of 800k tracks requires a continuous, high-volume connection between your phone and RoonServer, and iOS and Android. Both Google and Apple’s mobile operating systems limit how much data an app can move at once, so that all the open apps can share resources.
Another constraint is memory - most phones don’t have the RAM and temporary storage required to index 800k objects and the associated artwork, metadata, and playlists.
It’s for this reason that we strongly suggest you cleave off a portion of the library or create a new, dedicated database for ARC syncing. We recognize it’s frustrating, but it’s the technically feasible solution in this case.
