Xcode on Andrew Bancroft

4 Reasons Your iOS App Is Crashing

Sat, 25 Jan 2020 00:00:00 +0000

CPU cannot execute an instruction

Sometimes we developers don’t play fair with the CPU.

Suppose that I wrote some code that ended up telling the CPU to divide by zero.

That’s… impossible… for you and the CPU.

iOS is ensuring its own stability

iOS may be enforcing a fundamental requirement or policy for its own stability.

Apple isn’t going to let developers wreck the overall user experience of iOS.

Examples:

Your app takes forever to launch
Your app is using too much memory

iOS will opt for killing your app to protect the user’s overall iOS experience.

Swift runtime is preventing failure

There are certain protections within the Swift runtime that may cause your app to crash.

For example, if you’ve got an array with 5 elements inside (indexed from 0 to 4), and you attempt to access the 6th one by referencing index 5, the Swift runtime will kill your app when it sees this kind of instruction.

Force-unwrapping optionals using the ! operator is another classic app crasher.

Another developer is preventing failure

Finally, it may be that the developer of a framework or function you’re using is preventing you from misusing his/her API.

Some developers will use assert in a function to test that a condition is met before their function proceeds.

Guard statements mixed with a fatalError in the else block could also be a failure protection strategy.

In both cases your app would crash when the assert or guard conditions are not met.

While it would be nicer to see an Error instead of a crash, knowing that these are posssible “under the hood” reasons for the crash you’re seeing can be helpful.

Summing Up

It’s true: a crash can feel like it comes out of nowhere. Scoping the problem into four “big picture” reasons for a crash has helped me think rationally and probabilistically about what’s going on.

If you’re getting your bearings when it comes to debugging iOS apps, I’d love to impact your learning experience. Perhaps my iOS Debugging Fudamentals course on Pluralsight will guide you to more efficient debugging experiences!

Resources

iOS Debugging Fundamentals

4 Things You Should Never Do When Debugging iOS Apps

Thu, 16 Jan 2020 00:00:00 +0000

Never change code without reproducing the problem first

Reproducing the problem is a critical first step in debugging.

Before you start scouring your code… Before you start setting breakpoints… Before you start using tools or changing things…

See if you can cause the bug to happen again.

The goal of this exercise is to confirm that the problem is consistent. Reproducing the problem helps you clarify the conditions that are present when the bug happens.

Do your best to clearly state what’s going on – I even write it down sometimes to document the problem and make sure I’ve got it pinned down.

Never bug hunt before hypothesizing

Having a plan sets you up to avoid haphazardly hoping to find the source of the problem you’re experiencing.

Before you set off to track down what’s going on, make an educated guess about what you think might be going on.

Jot down a hypothesis or two (or three) and rank them in order of which feels more likely, based on your past debugging experiences.

Pair your hypothesis with possible Xcode tools to use and spots to look within your codebase to gather evidence to support or discredit the hypothesis.

Then, once you have a plan, head out into the code on a mission to investigate your hypothesis.

Take appropriate action based on your findings.

Never make code changes without a new branch

When you’re taking action though, make sure you’ve created a new code branch first.

Often, your investigation of a best-guess hypothesis about a bug’s root cause means you need to change something about your app.

Without a branch, you won’t be able to roll back to the original state of your code.

Set your self up to quickly iterate on evidence gathering.

Make a branch -> attempt a fix -> Did it work? Great! Does the bug persist? Rollback! (rinse and repeat)

Never change more than one “thing” at a time

Imagine experiencing a bug.

Now you go in and change a line of code here, toggle an Xcode project setting there, refactor a function, and then re-run your app.

The bug is fixed! Buuut… which change from your list of changes was the actual fix?

Never change more than one thing at a time.

Doing so not only makes the actual fix ambiguous, but could also inadvertently cause different bugs that you didn’t anticipate.

Whatever you do, only change one thing at a time when you’re attempting to fix a big.

Now…what does “one thing” mean?

“One thing” means “one fix strategy”.

In order to attempt some bug fixes, you may have to change 2 or 3 lines of code. That’s okay. You’re changing them as a “unit”, of sorts, as part of a single fix strategy.

Trying more than one fix strategy at a time is what I’m cautioning against.

Summing Up

Debugging is challenging enough as it is. Don’t make debugging harder than it needs to be. Avoid these four things and you should be a much happier developer.

Resources

iOS Debugging Fundamentals

What Is Debugging (And What Isn't)?

Mon, 30 Dec 2019 03:11:48 +0000

Does it ever help you to narrow the scope of overwhelming topics like “debugging”?

It helps me.

When you’re new to something like iOS development, you may find yourself stepping into a world of problems. Everyone around you is always fixing something it seems!

All kinds of problems can happen when you’re building an iOS app.

But are all problems… debugging problems?

TLDR; Answer: Not necessarily.

My brain appreciates focused definitions. It lightens the the mental load a bit to “bucket” problems into categories.

Which problems don’t fit into the “debugging problems” category? Which ones do?

Non-Debugging Problems

This list of common problem areas definitely take up a developer’s time. But rather than lump them all in with “debugging”, I prefer to treat them as problem sets of their own.

Build Problems

If your app won’t build, that’s definitely a must-solve problem. However, buildtime errors are not debugging problems.

Learning Curves

When you’re learning a new framework or trying something you’ve never done before, it can take some time to clear the hurdle of the Swift complier as you’re coding. Even still, this isn’t debugging.

Xcode Warnings

If Xcode is issuing warnings, you should probably take heed and resolve them before shipping to the App Store. But I still wouldn’t call this debugging.

Design Dilemmas

Design can get controversial, but overcoming these often-subjective dilemmas is not debugging.

User Experience Debates

As with design dilemmas, user experience debates are also trouble spots for many developers. The debates themselves, however, are not debugging.

Performance Optimization

Sometimes, you get your app built and running, but you’re struggling with performance-related issues. Even though it works (in a technical sense), it could be faster, more responsive, use less memory, etc.

Optimization, however, is big enough to be in a category of its own for me.

Debugging Problems

So… what is debugging then?

This is how I define it in iOS Debugging Fundamentals:

Debugging is…

Investigating and fixing flaws that you and your users experience while your app is running.

Thinking about and correcting defects that happen at runtime.

Debugging is a two-part problem solving exercise: It involves thinking skills and fixing skills. Debugging involves reasoning about the probable causes of flaws and defects in your apps. When you debug, you spend time trying to figure out the root cause of an issue you’re noticing.

Once you find the source of the problem, your job shifts to applying your programming skills and your knowledge of the app’s purpose (domain knowledge) to fix the problem.

But just as I started off this discussion by asking, “Are all problems… debugging problems?”, I’m able to answer “no” by emphasizing when the problems occur, namely, at runtime.

That’s why build problems, learnig curves, Xcode warnings, design dilemmas, and UX debates aren’t considered debugging activites (in my view).

I grant that performance problems are typically noticed at runtime, but, I believe this to be a separate activity, primarily because the app works (even if it could work better).

Summing Up

Narrowing the scope of debugging to reasoning about, inspecting, and repairing runtime problems lifts some cognitive weight for me.

It allows me to enjoy programming a lot more when I know that I’m not actually spending 99% of my time “debugging”. 😂

Resources

iOS Debugging Fundamentals

Showing the Live View in a Swift Playground

Tue, 28 May 2019 05:06:19 +0000

Where’s the Live View?

So you’ve created a new Single View playground from the template picker…

You run the playground right out of the gate to see what you’ve got…

But… Where’s the Live View?

Showing the Live View

To get the live view to show up, you need to open the Assitant Editor.

You can do this by clicking View - Assistant Editor - Show Assistant Editor.

Or you can press option + command + return to show it.

And we’re off to play!