# Arc constantly being terminated by IOS **URL:** \ **Category:** Arc App Support\ **Created:** [1 March 2021 10:19 UTC](https://support.bigpaua.com/t/arc-constantly-being-terminated-by-ios/93 "2021-03-01T10:19:20Z")\ **Posts on this page:** 1\ **Showing post:** 41
**Author:** ![Amido](https://avatars.discourse-cdn.com/v4/letter/a/5f9b8f/32.png) [@Amido](https://support.bigpaua.com/u/Amido)\ **Post date:** [27 September 2021 16:55 UTC](https://support.bigpaua.com/t/arc-constantly-being-terminated-by-ios/93/41 "2021-09-27T16:55:51Z")
> [@matt](#): > > Before reading further: If you want a solution to the terminations problem, install Arc Mini, and add one of Mini’s widgets to one of your home screens. Having multiple recorders will almost completely solve the problem. I did, and it definitely helped. It still feels super weird and most users won’t know about it. And it will solve the symptom, not the cause, meaning I still have to reload Arc for the data to make sense otherwise when I need it, all I get is “thinking” and super sluggish UI. > [@matt](#): > > It’s not recording detail level that causes the terminations, it’s the fact that Arc does all of its work _on device_ , with no server side processing or storage required. Yes, but that’s why I asked what about deferring everything to a mode where the screen is on, like Amazon Photo’s system. You don’t want to add a low accuracy mode that doesn’t require this much processing - fine, but what about making sure that this processing is done in a moment where it doesn’t hurt the core functionality of the app? I mean, I understand you don’t have the time to build a new tracking engine, but you still went to the extremes of making _an entire other app_ partly in a desperate move (if I understand correctly) to fix this problem, something that I’ve never seen done by anybody else in the history of iOS, so it’s not like you are not willing to sink time into solving this, even with extreme decisions. I’m super grateful that Arc Mini came out of this endeavour, don’t get me wrong! I still think, from my humble dev experience and from my mere user point of view, that requiring your users to find out that they need another app for the first app to work properly should be regarded as a super last ditch resort. Like, you literally said that if you remove the processing from the app it doesn’t get kicked. Then for real, don’t process this stuff in the background, and make it clear it needs foreground time. At least give us the option. Yeah, of course I’m pestering the devs of the other apps to add the features I need from them so not to depend on any single app/developer, but this is Arc’s support forum, not the other devs 😃 You wrote this in another thread: > [@Missing events in Month / Year view](https://support.bigpaua.com/t/missing-events-in-month-year-view/159/2): > > So plug the phone in, open Arc, then switch to monthly or yearly view and swipe through to the months with missing data, and Arc will start working on filling in the gaps. This is literally what I’m saying, but with extra steps, and it needs the user to keep the app alive by tapping on it from time to time. Way better to have a dedicated “processing” mode. I could even make an automation to open the app before going to sleep! Maybe one day all of these swiftui efforts will pay off and you can let us install the app on Mac and use the M1 to plow through the data in seconds… (; --- _[View the full topic](https://support.bigpaua.com/t/arc-constantly-being-terminated-by-ios/93)._