I did consider going that way with Arc Mini at the start. But it wouldn’t actually provide any greater energy savings, and it wouldn’t be very useful as a standalone app, so I decided against it.
When both Arc App and Arc Mini are in the background they go fully “headless”, meaning that they completely discard their UIs and operate as the equivalent of a “service” or “daemon” process. That means that there’s zero energy or memory being consumed by UI. In practice, they slim down to under about 50 MB of memory consumption, and both have identical energy consumption when recording. In headless mode they can continue recording for 24+ hours on a single battery charge.
By far the largest consumer of energy (and memory) for both Arc App and Arc Mini is the UI. When you bring the app into the foreground, the UI is built, memory consumed, and energy burned as the UI is updated while navigating around the app. A few minutes of foreground time, browsing around the app, can consume more energy than several hours of headless recording in the background.
Aside: That’s also why Arc App has its separate “Low Power UI”. When the phone is low on battery, people often open the app to check it’s still recording, but then end up churning through the remainder of their battery quickly due to the energy costs of the UI. So that desire to make sure the app is still recording while you’re rushing to somewhere with a charger ends up being self defeating, greatly increasing the chances of the battery running out before you get there. Arc’s Low Power UI instead doesn’t consume any energy beyond just the backlight of the screen.
This one’s a bit nebulous. iOS has an undocumented scoring system for apps, which it uses to decide whether to allow the app to continue running indefinitely in the background. A bit of foreground time can actually improve the app’s score, and be more likely to convince iOS to allow the app to continue running in the background. I presume the rationale is that if the user never opens the app they’re probably not interested in it, so why should iOS let it keep doing what it’s doing.
I’ll often describe iOS as being moody, and terminating apps “when it feels like it”. Really what’s happening is it’s keeping score, paying attention to how much energy apps are using versus how much attention the user pays to them, amongst other measures (perhaps - this is all undocumented, and we only get ambiguous glimpses of it in iOS debug logging).
Not at all! Until recently I’ve had three Arc family apps running all the time. The third one being the unreleased Arc v4 / Arc Journal (haven’t settled on the naming yet). I’ve paused development on that app temporarily (though still want to launch it eventually), so I’m not running all three at the moment. But when I was, energy consumption was effectively identical to having only one or two apps running. Only one of the apps will do the recording at any point in time - the others stay in standby, consuming effectively zero energy.
