Our app is good to go and everything seems to work just fine. We have tried to manage the memory as much as we can and we have no crashes at all.
Now before release, I want to check if there are leaks, or some problems that may cause my app to be rejected by Apple.
What's Apple's policy on memory leaks? Are even small ones not allowed? If some are allowed, then what's the limit?
What software/tool should I use to check memory management/leaks, to be sure that if it gives me good results, my app will be approved by Apple, if simply not crashing is not enough?
Is there a guide about one of this tools ?
Is checking my app in all iOS versions in the iOS Simulator enough? I have only 1 iPhone 4 :)
What you can do:
Run "Analyze" (MenuBar -> Product -> Analyze or SHIFT+CMD+B)
This checks your code for possible leaks and dead stores
Run "Profile" (MenuBar -> Product -> Profile or SHIFT+I)
This runs Instruments which allows you to track your allocations and possible leaks at runtime.
I don't think there is a specific policy about leaks - but a program that leak will crash - and Apple do reject apps due to crashes.
Otherwise I do agree with MatzeLoCal - run Analyze, and fix everything - and run a lot of profiling if you suspect there to be any issues.
In addition to running Analyze...
There is a tool in Xcode called Instruments that allows you to search specifically for memory leaks in your application. Choose the Leaks option when prompted when you open Instruments and then mess around in your app while recording to see any memory leaks that may be hiding in your app.
Here is the official Apple documentation for using Instruments: https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingLeakedMemory.html
Related
I developed OSX project in objective-c. I disabled ARC and I dealloc(release) memory manually. Is in xcode any tool, which can show me that I forget release any objects?
Nowadays i would recommend using ARC. But back then, when it wasn't available, the Profiler "Leaks" Tool did a pretty good job for me. You can see total allocations and potential leaks there.
You can start it by clicking Product --> Profile --> Leaks .
That's doing a analysis on runtime.
The Product --> Analyse Tool can analyse your code statically and show up further potential leaks (The arrows it draws can be a little confusing at the beginning).
Use the Profile menu item in Xcode and select the Leaks instrument.
Yes, you can use Instrument for that.
XCode-->Open Developer Tool-->Instrument.
Check out :
https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingLeakedMemory.html
and
https://developer.apple.com/library/tvos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/
Well, while running my iPhone game on my iPhone 4 through Xcode, my app crashed (sometimes does, sometimes doesn't), and when it crashed, Xcode didn't throw me any info. In the log, I could see (gdb) written, but nothing else that could help me find the problem.
What could cause such an error? At least it should tell me something, no?
Crashes without explanation on the device itself are often due to using up too much memory; the device simply terminates the app when it has requested more memory than available. This is easy to do in game development, with all those images.
Use Instruments to track memory usage, and/or put some good memory management code in the App Delegate methods for memory warnings and always release as much as you can.
I'm put together a CoreMIDI iOS app where I'm testing MIDINetSessionBrowser and MIDINetworkSession. I've been looking at this for a while now, and it appears that CoreMIDI has memory leaks.
Also, I just tried Pete Goodliffe's CoreMIDI objective-c demo and it also generates memory leaks when I run through profiler!
Thus, I think the chances that I'm missing something are smaller :)
Has anyone else profiled CoreMIDI and found the same?
Note: I'm using latest XCode and latest iOS and profiling by running on iPod touch 4 device.
I've some memory leaks due to CoreMIDI too.
It appears that the same issue still remains on iOS 5.0.
By the way, I'm not using PGMidi classes, but only the CoreMIDI API.
I am getting close to finishing the release of my application and are trying to use Instruments to fix any memory leaks.
How come that I can spot one memory leak when using Instruments and my device but not when I am using the iPhone simulator? I understand that this is a high-level question, but I don't think posting any code would help anyways (quite a bit of code...).
And is it possible to get instruments to point to the source code where it think the leak is? I can do it when using the simulator, but it seems like it doesn't work when using it for the device (objects are represented by the address (I assume) while running it for the simulator it sees what object it is, setup issues?)
Thanks in advance!
Regards,
Niklas
Update: Could it have something to do with that OSX is having automatic garbage collection but iOS doesn't?
Trust only the device. That's what your user will use to run your application.
Don't trust the simulator.
As a demonstration of this, I just intentionally added a leak to a project. The leak was not detected while in the simulator, but showed up as expected on the device.
The simulator is just that: a simulator. It can be useful to work faster, but is never a replacement of the device.
Once Instruments showed you a leaked object, you can double click on it. It will show the part of your code responsible for the leak. This works for the simulator and the device.
When you compile for the device, make sure you are in debug mode (and that the settings for this mode kept all your symbols).
Some more tip that you might find useful:
For a more fluid session, disable the "Automatic Leaks Checking", and manually press the "Check for Leaks Now" button when appropriate.
The "Build and Analyse" command will do a fantastic job to help you find leaks. It's not (totally) magical, so it won't find all leaks. For example, iVars leaked won't be identified. But for the scope of a method, it's just awesome.
I highly recommend to activate the "Run Static Analyser" flag in your build settings (or only for the Release mode if you have a slow to compile machine).
If you want more info about how to use Instruments to find leaks, read this Apple doc: Instruments User Guide: Built-in Instruments and Instruments User Guide: Viewing and Analysing Trace Data > Looking for Memory Leaks
You can also watch the video of the WWDC related sessions.
If you still don't understand where your leak come from, it's time to (re)read the Memory Management Programming Guide.
Thank you for wanting to ship a leak-free application. With iOS 4, it's now more important than ever.
If you haven't already take a look at the handy "Build and Analyze" option in the build menu. It will run the static analyzer which generally does a great job. If nothing turns up with that you should could some time reviewing the WWDC session videos on Instruments.
There is no substitute for profiling on hardware and with the debugger and instruments connected you can get everything you would in a simulator context.
I've been working on a new app, and when I run it on the simulator, it's VERY slow. There's nothing fancy in the app, just UINavigationControllers and text. The slowness only occurs if I launch the app from Xcode (with or without debugging on, doesn't matter). If I run the app on my iPhone or launch it directly from the simulator by clicking it's icon from SpringBoard, the performance problems all disappear.
For what it's worth, all my other apps perform just fine when run launched from Xcode in the simulator, so it must be something specific to this app. Has anyone experienced this before?
UPDATE: There is no performance hit when the app is run through Instruments either. I'm not using any 3rd party libraries. It's all calls to the Apple SDK.
Thanks,
Arash
Have you looked at it in Instruments to see where it's spending its time? No reason to guess when you can test.
Running an app in the simulator while in active debugging will always make the app slower. Always, and in a way that is exactly what you are describing.
Basically, "Build and Go" will be slow because its running the debugger.
This is different from "Debug" vs. "Release". The debug build will run fast if you aren't actually debugging it.
Are you using NSLog() to print a large amount of information? When you launch through Xcode, that information is piped to the debugging console and, if there's a lot, will take time to update the window. When you launch directly or on the device, the data is simply stored in a file, which generates less overhead.
I once reduced a program's run time from several minutes to a few seconds simply by removing logging statements. Unfortunately, it was for a timed programming contest.
I had the exact same problem and spent about 2hrs now to solve it. In my case I think it was because I had "Enable Guard Malloc" set. If it wasn't that, my other guess is bad karma.
Simulator Debug, You should need to be ensure when your app running on simulator debug->slow animations isn't check marked