Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> minus the whole "no background apps" thing

That's kind of a huge thing - it's the difference between this idea working and not working on the iPhone... and a great example of the kind of app innovation Apple could inspire by allowing background processes.



I bought an ipod touch hoping to make some productive use of it The no background processes thing makes that next to impossible. I can't risk my fancy dancy alarm clock not going of because I went and checked my email and forgot to re-open the alarm clock program. It's a huge problem with the platform in my opinion. Heck, my Dell Axim PDA from 5 years ago would happily run 6 or 8 apps at a time.


Really? The Apple Clock program's Alarms seem to work in the background for me.


you're correct. Apple does not expose this functionality to 3rd party apps.


It does, but I didn't like it as much as some of the other options in the app store.


Apple's alarm clock program works regardless of which app you currently have open.


Apple is never going to expose straightforward background processes, as it's way too late to switch to a Pre-style 'card' model that would make it natural. Fortunately there's a solution that's complimentary to the "no background processes" restriction that I'm sure some cretins at Apple have at least mocked up, if not implemented:

They just need to expose specific interfaces to launchd (Apple's clever init/rc/cron/xinet replacement), for doing particular kinds of local notifications. An app could register (with user confirmation) that it wants to have a limited helper run when an event has occurred: cron-style schedules, at-style timers, "Moved more than X meters", "Am near X:Y", etc. The registrations would be managed just like with the current push notifications.

With that, there'd be only a few other APIs needed to absolve the want for background processes. The ability to enqueue HTTP requests would make quite a number of apps friendlier to multitasking, and its already implemented privately in MobileSafari. The ability to play audio in the background would be huge, especially combined with queued HTTP requests, but I suspect that it'd be a lot harder to squeeze out of Apple.


Loopt got around this somehow:

http://www.businessinsider.com/loopt-to-run-in-the-backgroun...

I guess if you fellate / pay Apple enough, they let you do it.


If by 'Apple' you mean 'AT&T' and by 'let you do it' you mean 'give you a direct line from your data center to AT&T subscriber location data with which you can approximate the feature with the Push API and no actual third party code running in the background on each phone', then I concur with your assessment.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: