TEAM LICENSES: Save money and learn new skills through a Hacking with Swift+ team license >>

Tips for debugging iOS memory problems

Recorded – watch the full episode on YouTube.

If you've got a memory problem, things are not working correctly that's hard to diagnose because it's not visible anymore. How would you start to find those kinds of problems?

Carola Nitz: I mean, sometimes I add print debugging in the dialogue to see if something actually gets the eloquent I expect it to be de-allocated. Then you can also use the Memory Graph in Xcode where you can just see what is all holding on to certain objects. It's like in the same view next to the view to bugger I believe but then also in instruments if you have... What is it called again? I'm always forgetting the name? Paul help me.

Paul Hudson: Is it leaks?

Carola Nitz: Yes it's leaks – that’s the one that I'm usually using, or Zombies. Zombies is also something that can help if you have memory issues with something that has already been deallocated. It really depends on what kind of memory issues you’re facing – if it's too much definitely Instruments, allocations, the memory debugger, the memory graph, and Zombies for new objects.

Paul Hudson: I do wonder whether there's a divide between people who had to do memory debugging before Automatic Reference Counting (ARC) came along – before Swift came along, certainly – and those who did it afterwards. Because when I meet folks who did early ARC iOS code or even pre-ARC iOS code they became intimately familiar with the various memory debugging options; tracking memory zombies was a standard thing. You would turn it on regularly trying to figure out what was happening, and often I meet folks today who have never even heard of zombies and they aren't aware of how useful they are.

If that's you, folks, zombies are a brilliant tool: when destroying an object, rather than just freeing up the RAM to be nil, iOS puts a new type of object there called a zombie and when you try and talk to that zombie object it'll cause a crash. It's just a really important warning flag for bad memory access in your code. It's been there for 10 years or more – it's been around for a very long time.

Carola Nitz: Yeah that is definitely a great one.

Paul Hudson: I think people are genuinely scared of Instruments, that's for sure. And of course they are, because I find instruments daunting as well – I only use five or six of the instruments available!

This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.

Listen on Apple Podcasts

Hacking with Swift is sponsored by String Catalog.

SPONSORED Get accurate app localizations in minutes using AI. Choose your languages & receive translations for 40+ markets!

Localize My App

Sponsor Hacking with Swift and reach the world's largest Swift community!

Buy Pro Swift Buy Pro SwiftUI Buy Swift Design Patterns Buy Testing Swift Buy Hacking with iOS Buy Swift Coding Challenges Buy Swift on Sundays Volume One Buy Server-Side Swift Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Advanced iOS Volume Three Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with macOS Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Beyond Code

Was this page useful? Let us know!

Unknown user

You are not logged in

Log in or create account

Link copied to your pasteboard.