|< What is the best way to approach debugging a bigger iOS problem?||Which parts of Instruments are useful for debugging? >|
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.
SPONSORED Thorough mobile testing hasn’t been efficient testing. With Waldo Sessions, it can be! Test early, test often, test directly in your browser and share the replay with your team.
Sponsor Hacking with Swift and reach the world's largest Swift community!
Link copied to your pasteboard.