The quality of an app in terms of "frequently crashing" is not a reliable indicator of its security. Either state could have false positives or false negatives.
For instance (as pointed out in comments), an app with insecure memory use patterns could be exploited silently without a crash. Alternately, apps could contain memory access faults and crashes that that are not exploitable, or even intentional.
For instance, a common programming pattern is to initialize pointers to 0 at creation so that accidentally uninitialized pointers cause a null pointer dereference (segfault) rather than accessing some random memory which is less likely to crash (and less predictable and harder to debug). Zeroing the pointers at creation could make a program segfault frequently, where if those pointers were left with old values from a previous stack frame, it might be exploitable rather than crashy.
So if a program crashes frequently, I would be wary it may contain exploitable bugs, but this is not a reliable judgement on its own. In general, I don't think it is safe to say that a non-crashing program is safer either. This metric alone is not enough in either direction... Other metrics of code quality and corporate attitude towards clean code, code audits, and bug fixes are also important.