Hacker News Reader

Comment by aaaaaaaaaab | Hacker News Reader

You were misusing background location updates to periodically run your app in the background. I bet you were also misusing some keychain API or similar, to determine whether the device is locked or not, because there’s no official API for that either.

You were misusing multiple APIs and hoped that the reviewers won’t notice.

Facebook used to play silent audio in the background to prevent their app from being suspended. They got found out too and had to stop doing it. Suck it up!

I hope Apple would one day reject those apps that misuse silent push notifications for uninstall tracking too.

View on HN

I haven't used this app, but it sounds like people who installed the app knew about those features and wanted them.

If Apple is preventing developers from providing useful apps for arbitrary technical reasons, that's Apple being bad, not the developer.

That's different from uninstall tracking that surprises users in a bad way.

It’s not about surprising the user or not.

Ultimately, Apple gets to decide what is allowed and what isn’t. If I make a handwarmer app that purposely runs the CPU at 100% I’m pretty sure Apple would reject that too, even though it would be useful for users.

Why should Apple be allowed to decide what runs on phones owned by other people?

That's like letting appliance makers decide what food people can store or cook, or letting phone makers decide who people can call.

I understand this is the status quo, we can also discuss whether it's right, even if it's currently technically possible and legally permitted.

Actually you can run anything you want, just can’t distribute it via the AppStore. Anyone with a Mac can compile any app themselves and install it via Xcode.

And it’s not like iPhones are being forced onto people. People go out of their way to buy iPhones... Maybe there is some merit to these Draconian rules? Just look at the sorry state of the Google Play Store with all the low-effort adware or outright maliscious crap.

Being able to put any food you cook yourself in a refrigerator isn't the same as being able to put any food you want in it. Nor is being able to run any code you write yourself the same as being able to run anything you want.

You can run pre-built binaries via Xcode. You just need to re-sign it with your developer certificate and voila, you can deploy whatever you want on your phone.

Please re-read the guidelines and the use. No API has been used that wasn't explicitly allowed to be used for said purposes. Location provided location. The public signal that indicates screen off and on was used. Neither was used surreptitiously, rather, used explicitly. Apple says this os OK. They just have an inconsistently applied definition of what qualifies as "location is the primary use".

>Apple says this is OK

No, Apple clearly said this is not OK by rejecting the app.

This is not a courtroom where you get to debate how the letter of the law should be interpreted.

If I invite you to my garden party, but don’t like your behaviour then I can throw you out.

The debate to me seems to be about whether apple is within it's moral rights. The fact that legally they may be able to do whatever they want (modulo anti trust) seems pretty clear.

Ok. Then consider the following: can I use this app to track my screen time without giving it always-on location access? No. Therefore the app is not using the location API for its intended purpose. They use it to get unlimited background execution time under the disguise of location tracking.

(iOS developer here.) As an iOS user I'm generally very happy with the various app restrictions, because they increase my control over the device and my confidence that apps aren't doing naughty things behind my back.

On the other hand, there clearly exist good product ideas* that need more privileges, long-lived background execution being one. There ought to be a way for a proven good actor to get blessed for special entitlements where they're critical to the product. (There's already at least one entitlement in this model: "Hotspot Helper".)

On a technical front, Apple's positioning the iPad as a laptop replacement; well, the users who are going to buy into that are going to be using authoring, productivity, and communications software that they'll want to be flexible and responsive. That might mean -- horrors -- the occasional helper daemon...

*I don't actually know if RescueTime is in this bucket; I'd never heard of it before this article.

If and when general-purpose daemon processes will be allowed, RescueTime can be implemented on iOS again. Right now it’s not possible to implement it while using the existing APIs for their intended purposes.

But then again, I’d highly doubt Apple would ever allow general-purpose daemons on the iPhone. On the iPad Pro, maybe.

Reply on news.ycombinator.com