How I Debug Flutter Apps — My Actual Process, Not The Textbook Version

Every Flutter tutorial about debugging shows you the same things. Set a breakpoint. Inspect the variable. Step through the code. Very clean. Very tidy. Very much not how real debugging actually feels.

Real debugging is messier. It’s elimination. It’s “okay that’s not the problem, so what is.” It’s checking five things before you find the actual one. And honestly — most of the time it’s a print statement, not a fancy debugger session.

This post is about how I actually debug things. With a real example from literally today, because I think watching someone’s actual thought process is more useful than any generic checklist.

My Honest Toolkit

I use breakpoints sometimes. But if I’m being completely honest — print() statements are my most efficient tool, most of the time. I know debuggers are more "proper." I don't care. Print statements are fast, they don't interrupt my flow, and they tell me exactly what I need to know without clicking through layers of variable inspectors.

Use whatever actually gets you to the answer fastest. Nobody is handing out awards for using the fanciest debugging tool.

The Real Debugging Process — A Story From Today

Let me walk you through something that actually happened today. I was setting up notifications and they were not arriving on my device. Here’s exactly how I worked through it.

Step 1 — Assume the most obvious cause first

I was sending the notification through my backend API. So my first thought was simple: maybe the backend has an issue.

This is always step one for me. Start with the most likely, most obvious cause. Don’t jump to exotic explanations when there’s a boring, simple one sitting right there.

Step 2 — Eliminate one variable at a time

Instead of guessing, I removed the backend from the equation entirely. I printed my FCM token to the console, copied it, and went straight to the Firebase Console to send a test notification directly — bypassing the backend completely.

This is the core of debugging. You isolate variables. If I send directly from Firebase and it still doesn’t work, the backend isn’t the problem. If it does work, the backend is the problem.

I hit send from the Firebase Console.

Step 3 — Read the result carefully, don’t assume

The notification arrived on Android. It did not arrive on iOS.

This told me two things at once. First — my backend genuinely did have an issue, because going around it fixed Android. That part is solved. Second — there’s a completely separate problem with iOS specifically, because even bypassing the backend, iOS still wasn’t getting anything.

This is an important debugging lesson: sometimes you find one bug and uncover a second, completely unrelated bug hiding behind it. Don’t assume fixing one thing means everything is fixed. Test each platform, each path, individually.

Step 4 — Narrow down further

Backend was ruled out for the test. So now the question was — where exactly in the iOS flow is this breaking?

I added a print statement right where I call the function that displays the local notification. If this print statement fires, it means the message is being received by the device and the failure is somewhere in how it’s being displayed. If it doesn’t fire, the message isn’t even reaching the device.

I tested again. No print statement. Nothing.

That one missing print told me everything. The message was never even reaching the device. This wasn’t a display problem. This wasn’t a Flutter code problem at all. Something was stopping the notification before it even got to my app.

Step 5 — Think about what’s outside your code

This is the step a lot of developers skip. When you’ve eliminated your own code and the problem is still there — stop looking at your code. Start looking at what’s around it.

If the message isn’t even arriving at the device, the problem has to be somewhere between Firebase and Apple’s notification servers. Not in my Flutter code. Not in my display logic. Somewhere upstream.

So I went to my Apple Developer account and checked the APNs certificate.

It was expired.

Step 6 — Fix it, verify it, move on

I generated a new APNs certificate, uploaded it to Firebase, and tested again.

The notification arrived.

That was it. The entire bug — backend issue plus an expired certificate — found through a step by step process of elimination, not by guessing, not by randomly changing things and hoping.

What This Story Actually Teaches

Let me break down the pattern, because this is the part that matters more than the specific bug.

Start with the obvious cause. I assumed backend first because that was the most likely explanation. Don’t overthink your starting point.

Isolate variables one at a time. By going directly through Firebase Console instead of my backend, I removed one piece of the system entirely. This told me definitively whether that piece was the problem.

Pay attention to partial results. Android worked, iOS didn’t. That asymmetry was the most important clue in the entire process. If I had only tested on one platform I would have missed an entire second bug.

Use print statements as checkpoints, not just for values. I wasn’t printing a variable to see what it equals. I was using a print statement as a checkpoint to confirm “did execution even reach this point.” That’s just as valuable as checking a value.

When your code isn’t the problem, look outside your code. Certificates, permissions, configuration, account settings — these live outside your Dart files and they break just as often as code does. Don’t get tunnel vision staring at your IDE when the issue might be in a developer console somewhere.

Fix one thing, then re-verify everything. I didn’t just assume fixing the certificate fixed everything. I tested again after the fix to confirm.

My General Debugging Checklist

When something breaks, here’s roughly the order I think through things:

1. What’s the most obvious, most likely cause? Check that first.
2. Can I remove a piece of the system to isolate where the problem is? Bypass the backend, bypass a package, bypass a layer — see what happens.
3. Does the problem happen on all platforms, or just one? That asymmetry is always meaningful.
4. Add print statements as checkpoints — not just to see values, but to confirm whether code is even being reached.
5. If my code seems fine, what’s outside my code? Certificates, permissions, API keys, account settings, server configuration.
6. Fix the suspected cause, then re-test from scratch to confirm it’s actually fixed — not just assumed fixed.

The Honest Truth About Debugging

Debugging isn’t really a technical skill as much as it’s a thinking skill. The actual tools — print statements, breakpoints, DevTools — those are just ways of getting information. The real skill is knowing what question to ask next based on what you just learned.

Today’s bug wasn’t solved because I’m great at Flutter. It was solved because I followed the trail — backend, then platform difference, then code reach, then outside the code entirely — one logical step after another, until there was nowhere left to look except the actual problem.

That’s debugging. Not magic. Just patient elimination.

— Shivani Bagal 🤍

“Stuck on a bug right now? Ask yourself: have I actually isolated where the problem is, or am I just guessing? That question alone fixes half of debugging.”