Xcode debug service
My decades of experience getting up to speed fast on large amounts of other people’s code, and getting it to work, mean that I quickly complete software maintenance and get your app updates finished and ready to ship.
My good communication skills and extensive experience working with other people’s code means I work fast and do a good job debugging your Apple iOS app or Mac OS X application.
Recommended for debugging:
- A prioritized list of bugs.
- How to reproduce each bug. I’ll need the exact sequence of events need to reproduce the issue.
- Screenshots of UI cosmetic problems.
- It’s best if a program snapshot checked out of source code control builds and runs. Without that, whether your application is fixable depends on how complex it is. If something added just broke the build, that’s probably fixable.
- Having crash logs and console logs is helpful. Having stack traces in the crash logs is optimal.
When we get on the phone, I’ll want to know:
- What do you have?
- What do you want? (Pictures usually help.)
- How many megabytes is the total project? How many source code files? (This gives me a ballpark for the project size and level of complexity.)
- How many programmers were on the project, for what duration? (This helps me estimate how big a can of worms I’m jumping into, and how long debugging is likely to take.)
- Was this the first app someone wrote? (If yes, the code is more likely to include nonstandard implementations.)
- What does Build for Analyze in Xcode say about your project? Does your program have obvious memory leaks? How many? How big?
- How many warnings does Xcode generate for your project? It’s important to have less than a page full, because whenever I change something I’ll need new warnings to show up on the first page. If your project generates over a page of warnings, the first thing I’ll want to do is fix them.
- Are the original programmers available for quick phone consultations? If yes, this turns 4 hour searches into 30 second phone questions. If the programmers are not available, be prepared for me to pay the learning curve. Understanding your code requires time and attention; there is no way around it.
Important to know:
- I can easily fix most reproducible crashes with stack traces and most aesthetic problems, optimize for speed and memory usage, and hunt memory leaks.
- Debugging multithreaded projects requires more time, partially because it takes longer to make sure I’ve nailed down the real problem. The bugs tend to be obscure.
- Intermittent bugs are the worst to fix. Intermittent crashes are problematic at best.
- Not fixable: crashes that happen in third-party libraries without source code.
- Have realistic expectations. Code maintenance is always a can of worms. Software is complex. Seemingly good code could have been implemented badly. Expect surprises.
Ready to take action on your software?