tags:

views:

374

answers:

5

I have an application with multiple views. It works pretty fine without any leaks or crashes. But when you run using performance tool for leaks, I see when I switch through multiple views and comeback to home screen, my overall size of the application gets increased. Like if its 1.53MB after visiting 4-5 different views and getting back to screen increases the consumption to 1.58MB or less but definitely greater than 1.53MB. I tried resolving this issue but not able to figure out where I am going wrong since there are no memory leaks.

Does anyone know what could be the problem?

Will apple reject my application on this basis?

+1  A: 

I would go back and forth between the screens many many many many times (at least one hundred times). If the memory continues to grow (linearly) during that time, you have a problem. If the memory stabilizes, you might be okay.

MedicineMan
A: 

Definitely keep trying to fix you memory leaks. But if it's small, I doubt Apple will notice it. I mean, their own apps leak some too. You could get rejected for it, sure. But realistically, leaking a few bytes here and there shouldn't prevent an approval by itself.

(Source, 2 apps approved, one with the same issue, a tiny little memory leak I couldn't track down. I submitted it and was approved. Shortly after, I found and fixed it and released it as part of an update).

marcc
Well There are no leaks, like I can see any red pyramid for the leaks. But only memory consumption like Object Allocation is increasing.
rkb
I had this problem with some web service calls. Turns out that I was leaking a tiny little bit with every web service call. It's never been a problem, but I did fix it... I would never say "release it with known memory leaks", but, well... I'm just saying that it won't be the only app in the app store with memory issues.
marcc
A: 

There is no set in stone answer.

On the one hand is the fact that your application may have an obscure memory leak would be enough to reject it according to the posted policies.

On the other hand documents submitted to the FCC by Apple (in the AT&T+Apple vs. Google monopoly fight) give enough detail to work out just how much goes into reviewing an app - unless Apple lied the average app is reviewed by 2 people, and each of them spends around 5 minutes and 38 seconds (assuming Apple doesn't give breaks) to determine if your app passes or fails.

So the answer largely depends on if this memory leak can be discovered in the first 5 minutes of examination by some of the most overworked testers in the industry.

David
A: 

If you are using UIImageViews in your views, then part of the extra memory could be the caching that it does. See here.

Sometimes when we load views, and then switch to another, we leave the view around. For example, if you have a rootviewcontroller that has all the views as retained properties. Normally when you remove a subview, it is released, but not if you have it retained in your viewcontoller. As yu can see, that would add up to memory consumed, but not freed. It's not a leak, except that it gets released only when you release or remove the rootviewcontroller.

You could try to go through and find places where memory is tied up like this, or you could justify it based on the added speed of going through views without having to wait for them to reload.

In summary, it is good to know why your views and other objects consume and hold on to memory, but you may find that all those uses are justified, and you want to keep things that way. Having said that, I don't think Apple will be rejecting our app for decisions like this. If your app crashes because of memory usage, then that would get it rejected.

mahboudz
Yes I am using image animation and using UIImage imageNamed, so is that the issue, becoz I need those images most of the time and I cant use the strategy mentioned in the link u gave.
rkb
A: 

You're describing very typical memory usage.

If your app runs out of memory and crashes while they're testing it, they will reject it. Beyond that, you're fine.

Darren