Not completely though, you still have to think a lot more about ownership and object lifetimes (https://www.youtube.com/watch?v=JfmTagWcqoE), which is a lot better than manual new/delete, but still not as simple as just having a GC.
Plus you have to deal with lifetimes of objects proxied to Java code, where something in the Java code becomes the object's owner. Though you can use a bindings generator like djinni (https://github.com/dropbox/djinni) to handle this for you (with some tradeoffs).
>Debugging is only complicated on Android
It's gotten slightly better recently, but it still sucks.
With Swift it's not trivial either, it's not that easy to set breakpoints into C++ code, stack traces on crashes are often not helpful (so any unhandled C++ exception that you didn't catch and convert into a Swift error is hard to track down, etc.)
- C++ is a way more complicated language with the manual memory management. C is way too low level for things like this.
- Complicated builds if you need to use a bunch of C++ libraries as dependencies.
- Much slower iteration.
- Complicated debugging.
- The need to either write (slow) or generate (constraining) the Java/ObjC bindings.
Then there are things like having to reconcile the lifetime of your C++ objects with the Android Activity/Fragment lifecycles, etc.
If I was faced with the decision of what technology to use for a set of typical mobile apps, I would definitely want to avoid the native C++ path if at all possible.