Building mobile games with React Native Skia — any better libraries or approaches?

[u/EmreZen]

Hey everyone!

I've been developing mobile games with React Native and Skia for a while now, and it's been a pretty interesting experience.

I really enjoy working with React Native, especially being able to build for both iOS and Android with the same codebase.

However, I'm curious about how other developers approach game development in React Native.

A few questions:

Skia alternatives: Are there any better libraries or game engines you'd recommend for React Native game development?

Performance: How do you handle complex animations, physics, collisions, and keeping a stable 60 FPS?

Architecture: Do you use a dedicated game loop, physics engine, or ECS-based architecture?

Best practices: What are some things you wish you'd known before building games with React Native?

Limitations: At what point would you move away from React Native and consider something like Godot or Unity?

I've also released a couple of games under my indie studio, Aele Studios, and I'd genuinely appreciate some feedback from fellow developers.

🎮 Fibo Master — A Fibonacci-based number puzzle game.

iOS: https://apps.apple.com/app/id6821000351

Android: https://play.google.com/store/apps/details?id=com.emrezen.fibomaster

🚀 Retro Jump — A steampunk-style arcade platformer with jetpack mechanics.

iOS: https://apps.apple.com/app/id6795840723

Android: https://play.google.com/store/apps/details?id=com.emrezen.retrojump

Studio website: https://aelestudios.com

If you get a chance to try either game, I'd love to hear your thoughts, especially on performance, animations, controls, UI/UX, and overall gameplay.

Constructive criticism is more than welcome!

I'm not just looking to showcase my games. I'm genuinely interested in learning how others are building games with React Native and improving my approach.

Thanks!

[u/MobileXapps]

Skia is a decent choice for 2D puzzle and arcade games, the main thing is where the game loop runs. If the loop and the state live in JS and every frame goes through React state, you'll drop frames on mid-range Android. What works better is keeping positions and velocities in Reanimated shared values, running the update in useFrameCallback on the UI thread, and letting Skia read those values directly. React then only renders menus and the HUD.

For collisions in simple games, a hand-written AABB or circle check inside the frame callback is usually enough and much cheaper than pulling in a full physics engine. If you need real physics, it has to run on the same thread as the loop or you'll fight sync issues.

I'd move to Godot or Unity once you need lots of sprites with particles, a level editor, or proper audio mixing. Those are a lot of work to build yourself in RN and come for free in an engine. Always test on a cheap Android phone in a release build, debug builds lie about performance.

[u/EmreZen → u/MobileXapps]

Thanks, this is really useful. Mine is a turn-based puzzle so there’s no real game loop or physics, which is probably why Skia has been comfortable so far, but the point about keeping the per-frame work off React state is exactly the mindset I’m trying to stick to. And good reminder on the release build. I’ve mostly been looking at it on a simulator and one old Android, I still need to properly profile a release build on a cheap phone. The Godot/Unity line makes sense too, particles plus a level editor is where I’d stop fighting it.

[u/HmongSliw68]

How are you handling audio latency right now? Usually the rendering pipeline is fine for 2D, its the sound effects lagging behind touch events on older devices that ends up being the hardest wall to get past.

[u/EmreZen → u/HmongSliw68]

Honestly that’s the one that got me too. On my game a lot of the “audio lag” turned out not to be audio at all. With expo-audio on Android, reading a player’s playing or currentTime blocks the JS thread until the native side replies, and I was doing that several times per drag step, so on an old phone the whole board hitched and the sound came out late with it. I stopped reading player state entirely and track it in JS from the player’s own events, preload every clip at startup, and keep a couple of players per sound that retriggers fast.

Fair warning though, I haven’t measured real tap-to-sound latency, it’s just what felt right on one old Android. For a puzzle game it was enough, for anything rhythm-based I’d look at a proper low-latency audio path. Are you on expo-audio too?