almost afraid to ask on new background modes.

Have you filed a feature request describing your use case?

You absolutely have to file enhancement requests and bug reports making your case for the features that you want that iOS doesn't yet support. You probably won't get any direct feedback unless there's difficulty understanding something in your report, but it's still necessary.

On the other hand, it's important to remember that Apple applications have both a longer leash (Apple makes the rules) and a shorter leash (Apple's going to be more conservative about most things).

The complication with "doing a specific task that lasts less than 10 seconds at a specific date and time in the future" is one of managing when a dozen different applications all want to do something at the same time. Who goes first? How much time do the have? How does the user tell what's going on? If the foreground application is hogging resources, do you launch late? What happens when you crash in the background?

I've begged them for this in "bug reports" 3 or 4 iOS versions ago, I've written Tim Cook, (and Steve Jobs) for this.

I discussed ways I am using past and current Apple tech, UI and frameworks to work around trying to keep my apps at least usable, and instead of Apple "helping", those "work arounds" disappear in the next update of iOS/OSX, this has happened 3 times... the last time, I didn't even think it was even close to something Apple didn't want apps to do, nor would any normal human, yet the next version of iOS/OSX, I could not, nor can anyone, any longer use this extremely useful method... that is just not right.... there just is no reason why it should have disappeared, not battery, not security, not any reason. (and why it was such a big surprise when an Apple employee said: "you/your app should not be able to do such and such") I am going to leave that as vage as it sounds, for fear of losing something else.

I've grown to use "bug reports" sparingly, and not at all, twice bitten three times shy, and I've been bitten 3 times now... I have resorted to just putting in a big "Caution:" alert when the user opens the app, to explain how to "work around" getting the app to do what they want it to do., and a huge instruction set, instead of the app "just working" with one step, like any normal human would use the app, instead having to use 5 extra tech/UI/frameworks and battery for that matter, and then income the emails about: "why can't I just do this in the background".... great.... Instead of Apple having literally 10's of thousands of more users just amazed that their smart phone can do such and such... I am not being altruistic, I would literally have 10 times the sales if I could get my app to "just work", the side effect though, would be that Apple would have 10's of thousands of more users just astonished, and then just "taking it for granted" that their smart phone can do such and such. (well more "taking it for granted" because this shouldn't even be a question of what a smart phone can do now a days.)

litterally, you could ask 10,000,000 users if they would want an app to do such and such a task in the background for 10 seconds at a specific time in the future, (using 1/10th the battery of what has to happen now) and you would get 10,000,000 Yes votes, and 0 No votes. that is what makes it more astonishing that one can not do it after 3 or 4 iOS versions of "background" upgrades of what apps can do.

does it sound like "giving up"? well after 3 or 4 iOS versions... one can just shake one's head.

every person here reading this would vote "yes" to this obviously very usable feature, after they thought for all of 2 seconds about the many things that could be accomplished by having an app do a specific task at a specific time in the future in the background, and remember local notifications already do this in a way, so obviously there is no extra battery burn for the timer, heck a server notification does this completely... except for the fact that it's timer is not specific, nor guaranteed which makes it impossible to use for this task, (while a local notification is specific, but can't wake up the app in the background, but should be able to, but even that is using more battery than the more obvious and simple thing that needs to be done, which is to do everything a local notification does except for the actual local notification to the screen... and then wake up the app in the background for a few seconds.)

and obviously the security is exactly the same as an app doing something for "location" in the background... simply have a switch that says: "hey do you want this app to be able to run in the background for a few seconds in the future to accomplish a task)

If you want unfettered access to background execution, you should consider other mobile platforms. The multitasking framework and APIs exposed by Apple represent their opinionated belief that one can provide a high quality, total-device experience to the user (i.e. easy to preserve battery life in the face of battery-hungry developers), with full-featured background APIs for developers.

It's been five years since the first introduction of multitasking on iOS 4: iOS's approach has evolved over that time, and it seems clear that they will not be adding any capability for unterminated background execution in the near future. They've added many, many APIs to multitasking and background execution to support the vast majority of use cases, but it's clear that unbounded background execution without GPS or audio work is one they consider off-limits.

They've added many, many APIs to multitasking and background execution to support the vast majority of use cases,

and one of those use cases that Apple deems valuable is a push notification that opens the app and allows an app background execution for some amount of time.

it would be astonishing if someone could explain how this use case that seems to be valuable enough for Apple to actually put into action, to be any different from a local notification doing exactly the same thing? battery wise or security wise, or any other wise.... remember a local notification can be done now using what ever battery it does use, having the app open and do background execution also uses the same amount of battery as when a push notification does it... there literally would be no difference... and obviously no difference with security since a push notification can do it.

simply astonishing....

excuse me while I cringe and answer another email about why?? because somehow they missed the "CAUTION:" in the description in the app store, the "CAUTION" in the first time they opened the app, and the "CAUTION" the second time they open the app... I guess I have to put it in three times...

they have so many security questions from apple, from the 5 techs i have to use and other apps have to use, they just click on "no" or "ok" for each thing they see now adays... for all apps... oh well, some day it will just "work".