Introduction

EXC_BAD_ACCESS KERN_INVALID_ADDRESS means your iOS app touched memory it should not have touched. In practice, that usually points to a use-after-free bug, invalid pointer access, buffer overrun, unsafe C or Objective-C interop, or a concurrency bug corrupting memory. The important part is that this is a memory access violation, not a generic "something went wrong" crash.

Understand what the message is telling you

EXC_BAD_ACCESS is the exception class reported by the system when the process makes an invalid memory access. KERN_INVALID_ADDRESS is the kernel-level detail that the address being touched is not valid for the process at that moment.

That usually means one of these:

• an object or pointer was already deallocated
• a raw pointer is garbage or miscomputed
• an array or buffer write corrupted nearby memory
• multiple threads raced and one invalidated memory another thread used

A useful correction: messaging nil in Objective-C is normally safe and does not itself cause EXC_BAD_ACCESS. Invalid non-nil pointers are the real problem.

The most common cause is use-after-free

With manual memory management, unsafe bridging, or low-level APIs, a pointer can outlive the object it once referenced. The code still compiles, but the pointer no longer points to a valid object.

1NSObject *obj = [[NSObject alloc] init];
2__unsafe_unretained NSObject *unsafeRef = obj;
3obj = nil;
4
5NSLog(@"%@", unsafeRef); // risky access if the object has been deallocated

Modern ARC reduces many of these mistakes, but not all of them. Unsafe references, Core Foundation bridging, and C-level buffers can still create the same category of bug.

Enable the right debugging tools first

The fastest route to diagnosis is usually not staring at the crash line alone. Use the memory debugging tools that change the crash into a more obvious signal.

Useful Xcode tools include:

• Zombie Objects, for detecting messages sent to deallocated Objective-C objects
• Address Sanitizer, for buffer overflows and invalid memory access patterns
• Thread Sanitizer, when you suspect data races
• Guard Malloc, for certain heap corruption bugs

These tools often turn a vague crash into a very specific report.

Read the crashing frame carefully

When the crash lands in system code, that does not necessarily mean UIKit or Foundation is broken. System frameworks often crash only because your code passed them a corrupted pointer earlier.

So inspect:

• the exception backtrace
• the first frame in your own code above the system frame
• what object or pointer was being accessed
• whether the object lifetime was still valid

The bug is often one or two frames earlier than where the crash becomes visible.

Unsafe Swift and C interop still matter

Swift eliminates many ordinary pointer mistakes, but EXC_BAD_ACCESS still happens when you use:

• 'UnsafePointer or UnsafeMutablePointer'
• unmanaged Core Foundation bridging
• C libraries
• buffer math with manual indexing

For example, writing past allocated storage can produce exactly this crash class later.

1import Foundation
2
3let pointer = UnsafeMutablePointer<Int>.allocate(capacity: 2)
4pointer[0] = 10
5pointer[1] = 20
6// pointer[2] = 30 // invalid write
7pointer.deallocate()

The invalid line may crash immediately or corrupt memory and crash elsewhere later.

Concurrency bugs can masquerade as memory bugs

If one thread mutates or destroys state while another thread is using it, the resulting crash may look like a random invalid address. That is why thread-safety bugs often surface as EXC_BAD_ACCESS rather than as neat logic exceptions.

If the crash is intermittent and hard to reproduce, especially under load, do not ignore race conditions as a possibility.

Common Pitfalls

• Blaming nil messaging in Objective-C when the real problem is an invalid non-nil pointer.
• Looking only at the crashing system frame and ignoring the earlier application frames.
• Assuming ARC makes all lifetime problems impossible.
• Skipping Address Sanitizer, Zombies, and Thread Sanitizer during investigation.
• Treating intermittent memory crashes as random instead of considering data races and buffer corruption.

Summary

• 'EXC_BAD_ACCESS KERN_INVALID_ADDRESS means the app accessed invalid memory.'
• Common causes include use-after-free, invalid pointers, buffer corruption, and race conditions.
• Objective-C messaging to nil is usually safe and is not the typical cause.
• Use Zombies, Address Sanitizer, and related Xcode tools to narrow the bug quickly.
• Focus on object lifetime, pointer validity, and thread safety rather than only the crash line itself.