Hacker News Reader

Comment by lostmsu | Hacker News Reader

I actually have an app in iOS store that completely executes in the background: https://itunes.apple.com/app/id6737482921?mt=8

Never had it stopped by iOS. So not only there's no fundamental restriction, the App Store itself allows some apps to do that.

View on HN

What API are you using to keep running in the background? Most likely you are misusing it on some manner and have yet to get caught by App Review.

I've seen this bypassed via background audio and background location.

The app does background audio, and its use is legitimate. It is an audio app.

But the point is - there's no fundamental restriction from the OS itself.

You contradicted yourself.

Whether you want to call it a “restriction”, “a lack of permission without being X type of activity”, or “it works because the app exhibits Y behavior”, it’s all functionally a restriction.

You can run some background activities that are not audio apps, but you’re at the mercy of iOS’s decision to keep your task active or not. If you’re off the charger, all bets are off. iOS’s dev docs make this very clear.

No, basic set theory: not every restriction is a fundamental restriction.

Elaborate?

I said NOT(rule in "fundamental restrictions") AND (rule is XXX). You showed (XXX in "restrictions"). It would have been sufficient to prove my statement false if "fundamental restrictions" === "restrictions", but it is not.

Another way of phrasing this: There is a fundamental restriction, with a carve out for a few specific things, including audio playback.

I don't think you understand the difference between a fundamental restriction and a restriction in general.

What’s not fundamental about the OS pausing any background thread that doesn’t have an excuse to continue running from a relatively short list?

I am not here to debate meaning of words. If LLaMA 3.1 8B can understand the difference between a fundamental restriction and a restriction in general on its own, so can you. If you feel like this topic is worth your time for intellectual pursuit, feel free to debate with it: https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct I don't feel that it is worth mine. See if you can convince it the definition your are implying is more accepted than the one I am.

> I am not here to debate meaning of words

You say that, but then you dedicate a whole paragraph to my potentially (I’m not a native speaker, so it’s very possible) incorrect word usage :)

But also, I took your advice and had a chat with an LLM – seems like it's pretty much in agreement with my understanding of the meaning of "fundamental" as a plausible one.

Plausible is not more common/more accepted.

In this context, fundamental just means something inherent to the system, like a thing that can’t happen because of the way the system was defined. A boat fundamentally can’t fly, because it wasn’t made in a way that would allow it to fly. This is different from a plane which is restricted from flying because of a no-fly order. There’s no fundamental restriction (the plane was designed to fly, after all) but there is something keeping it from flying. And maybe one plane get special permission to fly despite the no fly order—that’s a carve out. So with iPhones, they are built in such a way as to allow background execution (there is no fundamental restriction) but Apple has made it so they cannot do so, with certain carve outs for things that people will want to be able to do while the app is in the background, like listening to audio or tracking the phone’s movements with gps. So there isn’t a fundamental restriction to background execution, it’s just a rule Apple makes (and then makes some exceptions to). There are other ways you could use the word fundamental, as in something that is important because other things rely on it. But that’s not the way it was being used here. Hope that helps!

Not sure what you mean with fundamental. As mentioned in the thread parent comment links to, the issue lies in enforced limits and lack* of general mechanism available to developers to allow background execution for any kind of app or/and purpose. No one said iOS itself lacks the functionality for background execution.

*In the same thread, it is noted that this lack is by choice and special-purpose mechanisms are preferred instead to prevent abuse.

Reply on news.ycombinator.com