NEW: Learn to build the incredible iOS 15 Weather app today! >>

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.

Listen on Apple Podcasts

Hacking with Swift is sponsored by Essential Developer

SPONSORED Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for iOS devs who want to become complete Senior iOS Developers.

Learn more

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

BUY OUR BOOKS
Buy Pro Swift 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 (Vapor Edition) 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 Server-Side Swift (Kitura Edition) 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.