[realharo]

It's certainly possible, but comes with a large number of its own issues:

- 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.

[LeoNatan25]

With modern C++ language features, the "complicated language with the manual memory management" a lot less obvious or necessary. Debugging is only complicated on Android, where NDK is pain in the ass for some reason, even after so many years of Google developing the toolchain.

[realharo]

>With modern C++ language features, the "complicated language with the manual memory management" a lot less obvious or necessary

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.)