Consumers of spine-android will most likely use Kotlin (with a small minority still using Java). The reference Spine Runtimes implementation is spine-libgdx, which is Java based. libGDX is Nate and my game dev library and has been battle tested for almost 15 years on mobile, specifically on Android. As such, we know the ins and outs of Android (or more precisely ART) performance. For most of the stuff happening in spine-android (and spine-libgdx, which is spine-android is built upon) going C++ would not yield any benefits. On the contrary, crossing the JNI bridge is very costly. I.e. having to go through JNI for every class' setters/getter would be much slower in C++.
The one place where performance would be slightly better is vertex transformations of attachments. But even there, the returns are diminishing. Once we've transformed the vertices of an attachment based on the current pose, we'd have to talk to Android's graphics API, which would require us to push native side float* back into Java land (which incures allocations every frame). The Java solution is pretty much allocation free in the renderer (after a few frames).
Memory management of native resources on the Kotlin/Java side is also not exactly trivial and there are many foot guns, with which users can shoot themselves.
TL;DR: for the work loads we have, C++ does not quite give us many benefits compared to ARTs performance, while everything else (exposing the full API, memory management, talking to the graphics API) becomes worse.
react-native-spine-player is neat btw! You have to draw into an Android Bitmap via Skia, which will eliminate the JNI round trip I talked about above:
Hau-Hau/react-native-spine-playerblob/main/android/src/main/cpp/spine-android.cpp#L55
But the downside to this approach is that you now have to composite that Bitmap into your UI, while our approach can more directly render to the underlying rendering surface, so less round tripping through the compositor.
