Adding the breakpoint would lock the device's UI, but doesn't "turn on" debugging
The debugging session to start up, stack traces, variables etc
So I have a simple trivial example, you would need to run npm install then start a debug run for iOS inside VS Code.
https://cl.ly/3C0V2Z2i200l/react-native-debugger-issues.zip
You should tap the view to see it say both "yo" then "hello". If you add a breakpoint at "hello" (line 11) and tap the view, the console will print "yo" but not "hello" - and VS Code will not start showing the trace etc
/cc @mennenia
Thanks for reporting this, that's definitely a bug. We recently made some changes that we haven't yet released which update the debugger to a newer version. If you are keen, you could try checking out this codebase and see if your issue reproduces still. Otherwise I'll take a look at this soon and see what's going on.
I just tried out the example you linked above, and it works fine for me with all the same versions (Except I'm on OS X 10.11.4)
Does this fail consistently for you every time?
Yep, just tried it now, 100% reproducible, based on the file uploaded on another computer, same VS Code / React-N setup

What version of nodejs do you have installed? node -v should tell you.
I'm running 5.10.1, and the process being debugged is actually running in a node process so a mismatch there may explain the difference in behavior.
This was tested on node version 6.1.0.
Ok, looks like that's the cause, I just reproduced this using node 6.3.1
We are using the vscode-node-debug debugger internally, so I'll let them know and see if we can get a fix out. Thanks for letting us know!
I'm trying to get a minimal example to help the node debugging team analyse the issue. In the mean time though, I did notice that manually pausing the debugger (clicking the pause button) when the execution was already stopped at a breakpoint does cause the debugger to realise it is stopped at the appropriate line and you can debug and continue on. Not the best, but a workaround while we try and sort this out.
Here is an update:
So this looks like a bug in Node.js itself.
Tracking this issue here as well.
We've managed to get a stable minimal repro case and sent it to nodejs team, so hopefully they will be able to reproduce and fix this on their end.
@orta, @mennenia, as of now as a workaround _we recommend to use either 4.x or 7.x NodeJS version_ (it appeared that 7.x is also unaffected by this bug and debugging works just fine)
@mbraude, we can probably close this as there is nothing we can do at our end?
Thanks!
Most helpful comment
We've managed to get a stable minimal repro case and sent it to nodejs team, so hopefully they will be able to reproduce and fix this on their end.
@orta, @mennenia, as of now as a workaround _we recommend to use either 4.x or 7.x NodeJS version_ (it appeared that 7.x is also unaffected by this bug and debugging works just fine)
@mbraude, we can probably close this as there is nothing we can do at our end?