Upcoming iOS 7 APIs: Gaming Improvements, Multitasking Support, AirDrop, and More

[pgiguere1]

On the topic of improving their multi-tasking, I would really like to see the option of a button to "kill all" running apps in the background as opposed to closing each one individually.

You never had to close each app individually in the first place.

Most of the apps (unless they're playing audio or using your GPS) will just become inactive in the background so they don't use any RAM/CPU, their state was simply saved to storage so you it can resume when you switch to it again. "Killing" them had no effect except to clear their state cache.

Apple has never really made the way iOS multitasking works clear so I can't blame users who think iOS manages multitasking like a desktop, but it doesn't. It's made to manage stuff by itself. Only killing active apps has an effect, and apps are rarely active in the background unless you have a clear sign they are.

 

[Daveoc64]

Apps that include support for the controller are also required to make the game playable without the controller as well.

Define "playable".

There are a lot of games that just don't seem to work well with touch controls (hence this whole initiative). You might say they're "playable", but that doesn't mean that people will want to buy them - particularly if people know that they can work better with a controller.

 

[bushido]

so whats the point of having apps update in the background if they cannot be added anywhere as a "widget" like weather?

 

[Mac21ND]

Define "playable".

There are a lot of games that just don't seem to work well with touch controls (hence this whole initiative). You might say they're "playable", but that doesn't mean that people will want to buy them - particularly if people know that they can work better with a controller.

What I don't care for the most with touch controls is that your fingers are taking up part of the screen. It's less of an issue with an iPad, but on an iPhone or iPod Touch, the screen size is much more of an issue.

 

[Daveoc64]

so whats the point of having apps update in the background if they cannot be added anywhere as a "widget" like weather?

It should mean that the content you want to see is already there when the App opens. Potentially you might want to use the App at a time when you have no signal (e.g. in the subway).

 

[WilliamLondon]

No. This does not mean Apple TV apps. It's to allow hardware manufacturers to concentrate on making great hardware, because Apple handles the other crap. This is the whole point of Apple standardising here. And that means an even better ecosystem for Apple. One more thing competitors will have to do to catch up.

This doesn't mean no apps either, that's just as wrong as stating categorically this definitely means apps - we don't know, but it could. It *could* lead to apps on the ATV (or they might be already part of the roadmap, of which this is one small milestone of that roadmap). I can't imagine the ATV will never get its own apps - the apps are what make the iPad and iPhone such interesting devices, and that is exactly what is missing from the ATV.

 

[baryon]

iBacons, sounds tasty!

 

[andrew78]

Finally!!

Finally!!!

my biggest complaint with iOS games so far has been that all input has been touch-based or balance-based.

And, I know this sounds crazy, like really crazy, but I'm hoping for some support for mouse-input sometime in the future.

 

[sshhoott]

These APIs are a good balance between iOS's "openness" and security.

 

[andrew78]

"Killing" them had no effect except to clear their state cache.

sound political

 

[applefanDrew]

Apple has never really made the way iOS multitasking works clear so I can't blame users who think iOS manages multitasking like a desktop, but it doesn't. It's made to manage stuff by itself. Only killing active apps has an effect, and apps are rarely active in the background unless you have a clear sign they are.

What I want to know is this... are the "new" multitasking APIs replacing the old ones? Or are they in addition to the old ones? For instance will VoIP still be handled like it is now or will they just let the app run continuously since it would need to constantly listen to its port?

 

[Rogifan]

so whats the point of having apps update in the background if they cannot be added anywhere as a "widget" like weather?

Hmm...if this means my downcast podcasts will download automatically in the background as new ones become available then I'm a happy camper. Though for some reason downloading them over wifi can be painfully slow, worse than dial up. Not sure why.

 

[Daveoc64]

What I want to know is this... are the "new" multitasking APIs replacing the old ones? Or are they in addition to the old ones?

These are in addition to the old APIs.

For instance will VoIP still be handled like it is now or will they just let the app run continuously since it would need to constantly listen to its port?

That's pretty much how VOIP works now on iOS.

 

[wilhoitm]

These APIs are a good balance between iOS's "openness" and security.

Sprite Kit also contains something like a Bullet Physics API. Actually it looks like Apple has implemented something like Bullet Physics throughout the iOS 7 UI, it is not just limited to games!

Can't innovate any more my ass!

 

[cclloyd]

Now that they have p2p in the iPhone, let's make it connect directly to the ATV for AirPlay shall we?

 

[applefanDrew]

That's pretty much how VOIP works now on iOS.

No, my understanding (according to developer docs) now is that the app sleeps while the OS listens to the port created by the app. When it gets something, it wakes up the app and lets it do its thing. The app isn't churning away doing anything otherwise.

For instance it was discovered recently that the FB app registers as VoIP and wakes up every 15-30 minutes and does 10 seconds of checking before sleeping again. This has led to poorer battery life than if you just close out FB and Messenger altogether.

My worry is with iOS 7 multitasking that battery will go down since it will basically be doing this for all apps that I use. I usually check my core 6 apps every 1-2 hours.

 

[drewc1138]

On the topic of improving their multi-tasking, I would really like to see the option of a button to "kill all" running apps in the background as opposed to closing each one individually.

Why? As I understand, it doesn't affect performance to have a ton of apps in your multitasking tray. iOS keeps as many open as the allocated memory allows, and automatically closes the rest.

----------

For example, a Twitter app might incorporate this functionality, downloading new content in the background while the phone is not otherwise in use, staying up to date without unnecessarily draining battery.

I thought it was the other way around. It won't do it while the phone is asleep, but if you turn the phone on and start doing something, it will use that opportunity to start refreshing apps in the background.

 

[Daveoc64]

No, my understanding (according to developer docs) now is that the app sleeps while the OS listens to the port created by the app. When it gets something, it wakes up the app and lets it do its thing. The app isn't churning away doing anything otherwise.

The app can also "wake" periodically (no more frequently than every 10 minutes) to communicate with the VOIP service's servers.

So, you're very much correct in your understanding!

The new APIs aren't designed to allow developers carte blanche to do whatever they want in the background, Apple's approach to multitasking is to offer features that mimic the functionality of an App "always running" as much as possible.

The new features are quite similar to the VOIP API in a way, Apps will be able to:

1) Download data in the background when they are triggered by a push notification

2) Request that the OS wakes them periodically to update data in the background. The way the API is described, this will not be very "reliable" - in the sense that Apps aren't guaranteed to run at any specific time or for a specific length of time.

 

[rovex]

They may not include it in the default camera app, but they probably are providing an API for developers to take advantage of.

Why wouldn't the camera film at 60FPS? Obviously, it might be something they're keeping secret for the ip5s.

 

[applefanDrew]

The app can also "wake" periodically (no more frequently than every 10 minutes) to communicate with the VOIP service's servers.

So, you're very much correct!

The new APIs aren't designed to allow developers carte blanche to do whatever they want in the background, Apple's approach to multitasking is to offer features that mimic the functionality of an App "always running" as much as possible. I don't think it will be possible for a developer to have a VOIP (or other App) app that just listens for incoming connections.

Ah! Thanks for the clarification.

It has been a while since I read it and I guess I just plain forgot that part of it.

 

[cclloyd]

controller support? that is cool!

Now those pokemon emulators will feel that much more real.

 

[CDew]

Separate Alerts for Calendars?

Does anyone know if Apple will finally allow separate alerts for calendars?

Any family with His, Hers, and House calendars has likely run into the current limitation where you either get alerts for all shared calendars (that you can edit), or no alerts.

If you need to add meetings to all three, want alerts for the House & your calendar, but don't want your spouse's alerts, you are out of luck in iOS 6!

I hope someone can verify that Apple has overcome this annoying obstacle in iOS 7.

 

[vmachiel]

so the next iphone will have 60FPS capture? Sweet!

 

[applefanDrew]

The app can also "wake" periodically (no more frequently than every 10 minutes) to communicate with the VOIP service's servers.

So, you're very much correct in your understanding!

The new APIs aren't designed to allow developers carte blanche to do whatever they want in the background, Apple's approach to multitasking is to offer features that mimic the functionality of an App "always running" as much as possible.

The new features are quite similar to the VOIP API in a way, Apps will be able to:

1) Download data in the background when they are triggered by a push notification

2) Request that the OS wakes them periodically to update data in the background. The way the API is described, this will not be very "reliable" - in the sense that Apps aren't guaranteed to run at any specific time or for a specific length of time.

If you don't mind, could you post the link to the API?

 

[Colonel Badger]

You never had to close each app individually in the first place.

Most of the apps (unless they're playing audio or using your GPS) will just become inactive in the background so they don't use any RAM/CPU, their state was simply saved to storage so you it can resume when you switch to it again. "Killing" them had no effect except to clear their state cache.

Apple has never really made the way iOS multitasking works clear so I can't blame users who think iOS manages multitasking like a desktop, but it doesn't. It's made to manage stuff by itself. Only killing active apps has an effect, and apps are rarely active in the background unless you have a clear sign they are.

Actually that's incorrect. When an app moves to "suspended", it stills consumes all the RAM it originally did. You're correct it doesn't consume CPU. So Apps can "eat up" RAM that the foreground App needs. iOS will send a "Memory Warning" to all apps when it gets low on RAM and it's up to each app to clear its RAM in response. If they do not and iOS deems the app still to large, it will terminate that app and it will no longer be in suspended mode. However this can take some time and while this is happening it can cause the foreground app to potentially run out of memory. Hence quite a few people find that removing a lot of suspended apps from iOS, by killing them, helps running the foreground app.

Additionally, some of Apples apps don't seem to play by the same rules. For instance, in iOS 6 or below, try loading Safari up with as many pages/tabs as you can and use heavy pages for each. Then try loading an app that requires lots of RAM. It'll probably crash. That's because Safari doesn't seem to obey the cleaning of memory and iOS doesn't seem to terminate it, like it does third party apps. I use this method a lot to test memory usage of apps we're developing, on devices.

Mark.