What is the best way to approach debugging a bigger iOS problem?
Recorded – watch the full episode on YouTube.
How would you try and solve a larger Swift problem more quickly? What's your tip for looking at a problem and thinking, “what's the fastest way through this?”
Carola Nitz: Usually it's breaking it up if you can, even if it's just something simple like you add two values and then you return the result. Just maybe save it into a local variable then return on the next line – that's an easy way of breaking something up. But sometimes you have even more problems, bigger problems that you're trying to debug where the breaking up helps a lot. And then if you have bigger problems what else do I do? It's a good question. Simplifying.
Paul Hudson: Do you have big problems?
"If you have bigger problems what else do I do? Simplifying."
Carola Nitz: Yes of course, but it's also just simplifying, right? For example, if you have a custom view that does a lot and you need to figure out, “oh is the problem actually my custom view or is it something else?” Then you just replace the custom view with the standard Apple view just to figure out where the problem is, and sometimes just remove functions. Honestly I have had a big problem where I just commented out code and looked at it – does it work now? Yes, then it's somewhere in the commented out code.
Paul Hudson: And that was the way we solved compiler errors in SwiftUI when it first shipped. You'd write some perfectly normal code and make one tiny mistake – you'd pass something incorrectly, for example – and you'd get a useless error message along the lines of, “you provided me a CGFloat, but I want an optional CGFloat.” And that makes no sense but it was misdiagnosing the errors. So you'd basically delete half your code and the error would still be there, then you’d delete half of the remaining code and it would go away. And then I'm like, “okay so the problem is in there somewhere." You do a binary chop on your code trying to find where the problem might be. It was exhausting, so that shouldn't be your first port of call all being well!
"You could just break it down and make it easier, and then the compiler would actually understand what you're trying to do and could help you with better error messages."
Carola Nitz: I remember actually back when I started out with Swift development that the compiler was actually getting confused if you had two complex things. And it would throw at you like “t1, t2 is not working with this CGFloat.” You could just break it down and make it easier, and then the compiler would actually understand what you're trying to do and could help you with better error messages.
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 Join a FREE crash course for mid/senior iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer! Hurry up because it'll be available only until April 28th.
Sponsor Hacking with Swift and reach the world's largest Swift community!
