The memory leakage is more consistent in 64-bit version of iOS 7, but not only in that ...
You probably are the only one not having memory problems with Safari and ram ... I mean the only one in the world
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iPhone Do you kill apps from multi-tasking on iPhone?
- Thread starter Jonytheblue
- Start date
- Sort by reaction score
The memory leakage is more consistent in 64-bit version of iOS 7, but not only in that ...
You probably are the only one not having memory problems with Safari and ram ... I mean the only one in the world
I close them after I'm done using them. Sort of an OCD habit, but it gives me a placebo that things are running well. I also play games like My Little Pony that will do annoying things in the background if you don't close them. I also heard from an AT&T employee that it supposedly saves data, but I'm not sure about that.
No they won't. 95% of the applications in the switcher are not even running and the very few that are are only running for a maximum of 5 minutes before they're force paused by iOS.
The memory leakage is more consistent in 64-bit version of iOS 7, but not only in that ...
You probably are the only one not having memory problems with Safari and ram ... I mean the only one in the world
I'm really not. An unbiased reading of this forum (itself heavily skewed towards the minority with problems) would tell you the overwhelming issue is with 64bit IOS, for most 32 bit users safari is fine.
----------
I'm making the blindingly obvious point that IOS will fill any application memory you empty with another application because that's the point of it - you're never truly freeing space and in fact IOS is far more adept at sensibly apportioning that memory to different applications than you are anyway. Stop chasing the fictional benefit of having x% free and just let IOS do it's job..
Once again you fail to realize that an iPhone 4 on iOS 7 running any decently large application would see a difference, the world doesn't revolve around just your experience.
If the OS is working as intended there is no reason to ever kill an app manually. That said, there are cases right now were apps need to be killed. iOS 7.x is significantly different under the hood and is IMO the least stable version of iOS in the last 5 years. Killing apps under 7.0.x is occasionally the right choice.
Fortunately 7.1 addresses most issues. Personally I have seen no reason to kill any app on my devices since I began running the beta. Looking forward to the general release.
Fortunately 7.1 addresses most issues. Personally I have seen no reason to kill any app on my devices since I began running the beta. Looking forward to the general release.
Absolutely not except for two scenarios:
1) A clearly unresponsive app (strangely this seem to happen a lot to IMDB on 7.1)
2) For apps that absolutely need every last piece of resource to function reliably. For me that is XCom and Traktor DJ on the iPad.
Any other time I can pretty much trust the OS to manage resources reliably for me.
1) A clearly unresponsive app (strangely this seem to happen a lot to IMDB on 7.1)
2) For apps that absolutely need every last piece of resource to function reliably. For me that is XCom and Traktor DJ on the iPad.
Any other time I can pretty much trust the OS to manage resources reliably for me.
Nonsense. iOS manages memory perfectly well without user intervention.
Apps that you haven't used for a while, or which are using a lot of memory, are automatically killed.
Since iOS' multitasking was mostly fake, in the past, it was pointless to manually "close" apps, as they were all closing anyway, save for as some have mentioned, the navigation stuff, which I would force quit when I was done.
But with iOS7, I'm not 100% sure? There's actually been an issue found that a program in the background can collect input from a forground program. Apple's claimed they've redone how multitasking works, but I've never seen it explained very well.
There's background refresh...I don't know if turning that off for a program prevents it from running at all, and not turning it off allows it to do anything?
On the other hand, iOS devices are RAM constrained, and you won't go long before programs are kicked out of RAM anyway...unless maybe if the program wants to, it can keep running, prevent itself from being kicked out of RAM? (But maybe not if background refresh is disabled for it?)
This stuff really isn't documented anywhere I've seen.
At any rate, I use it just like iOS 6 for the most part. Programs on my iPad 2 are clearly getting kicked out of RAM really fast, sometimes even after using just a single other program, so force quiting it would do nothing, as it's already quit.
The exception would be if a program doesn't resume right, but that doesn't even mean it was running in the background, just that it won't resume right, and that's pretty rare from my experience. If something's messing up, I just kill it at that point.
But with iOS7, I'm not 100% sure? There's actually been an issue found that a program in the background can collect input from a forground program. Apple's claimed they've redone how multitasking works, but I've never seen it explained very well.
There's background refresh...I don't know if turning that off for a program prevents it from running at all, and not turning it off allows it to do anything?
On the other hand, iOS devices are RAM constrained, and you won't go long before programs are kicked out of RAM anyway...unless maybe if the program wants to, it can keep running, prevent itself from being kicked out of RAM? (But maybe not if background refresh is disabled for it?)
This stuff really isn't documented anywhere I've seen.
At any rate, I use it just like iOS 6 for the most part. Programs on my iPad 2 are clearly getting kicked out of RAM really fast, sometimes even after using just a single other program, so force quiting it would do nothing, as it's already quit.
The exception would be if a program doesn't resume right, but that doesn't even mean it was running in the background, just that it won't resume right, and that's pretty rare from my experience. If something's messing up, I just kill it at that point.
I'm not sure what to say other than try it for yourself. I provided a clear explanation. Not my fault Apple's documentation isn't clear enough for you.
It's easy enough to test. Find an app that predictably uses Background Refresh. "Quit" the app. See if it still does a background refresh as it normally does.
Does it really make sense to you that Background Refresh would only work if that app is suspended in memory? Seems a bit silly to me.
Why not? The app is effectively "in the background" in a state like that (rather than completely closed) and thus refresh allows it to update while in background at various times (whereas it wasn't able to do that before or without background refresh enabled for it as apps in the background, with some small exceptions, aren't allowed to run after a bit of time and are suspended).
Because only the last 3-5 apps (on average) that you opened are suspended in memory. Less if you open a memory-intensive game. If the OS is only refreshing the last few apps that you have used, it's defeating the whole purpose of Background Refresh.
But, again, there's no need to talk about this theoretically. Background Refresh works even if an app is completely closed. It will even work after a reboot.
Before the Air, I had an iPad 4, and before the 5S I had a 5, both with iOS 7 installed.
The issue was less noticeable, but still present ...
Now I'm checking iOS 7.1
----------
That's simply not true (now I'm checking if iOS 7.1 is doing any better) ...
I've done several tests, some published on other threads in this forum, and in many cases iOS 7 crashes the app instead of releasing ram. Especially with Safari involved.
----------
Apple's documentation is very clear on the matter, and I've posted TWICE.
----------
Absolutely NOT, as Apple, not me, stated:
When Background App Refresh is on, apps that take advantage of this feature can refresh themselves in the background. For example, an app can check if new content is available and download the updates, or retrieve the updated content in the background when it receives a push notification, so the new content is ready for viewing when you launch the app. Apps can also schedule background refreshing based on your location. If you force an app to quit by dragging it up from the multitasking display, it won't be able to do its background activities, such as tracking location or responding to VoIP calls, until you relaunch the app.
You could post it THREE times and it wouldn't change the fact that Background Refresh continues to work if you "close" an app.
The part that you are missing is "such as tracking location or responding to VoIP calls." As I said, these activities (in addition to background music and task completion) are quit when you close an app from the multitasking view. However, Background Refresh is not stopped. It happens on a schedule, or in response to push notification regardless of whether the app has been closed.
Again, you can test it yourself.
No, I'm not. As described in the paragraph that you posted, push notifications can trigger a background refresh. The latest update to the Gmail app adds this feature.
Push notifications can, because is a system service and it is supposed to operate also with apps not running.
Other apps cannot.
Again, you are not understanding what is happening. You posted the explanation yourself. Push notifications are one way to trigger a Background Refresh.
For example, a notification comes in for the Gmail app. Prior to iOS 7, that's all that happened. However, with the latest update that supports Background Refresh in iOS 7, the Gmail app now runs in the background to download the message and then moves to a suspended state. The message is available when you open the app.
That's what a Background Refresh is. It can also be triggered by the OS on a schedule determined by when you typically use the app. And it can be triggered by a location. All of these work even if the app is completely closed.
That makes sense. Is this documented anywhere though?
Interesting that various apps may be getting loaded and unloaded in the background to pull this off! I just have background refresh disabled for most of my stuff.
Hmm, anyone know about Notes syncing? Does that need background refresh on to stay in sync (without loading the program) or does it stay in sync even with that off? (I only just started using notes as it doesn't really sync with Google, so I started using iCloud.com finally, as it's handy)
Notes syncing originally worked through IMAP (Email folders). Not sure if that has changed recently.
They are in a folder. I can't keep all of my most used apps on a single home screen. So it would generally require me opening a folder or swiping home screens, that extra step. Obviously this isn't always the case because phone, mail, messages etc I have front and center.
But a lot of my work related apps reside in a folder. Exercise apps are less used so they are on my second home page but I goto the gym daily so even then they are used quite frequently.
At this point I still feel it's user preference and I'm trying different things currently and rearranging something's because a lot of you guys feel there are better ways. I'll give it a shot, nothing to lose aside from a couple seconds a day.