Some technical points about Krell. It leverages the ClojureScript `:bundle` target which was released last year <a href="https://clojurescript.org/news/2020-04-24-bundle-target" rel="nofollow">https://clojurescript.org/news/2020-04-24-bundle-target</a>. By simply producing output that is JS bundler friendly we can just piggieback on Facebook's Metro just like we piggieback on Webpack etc. when targeting the web.<p>We simply reuse the debug loader provided by Google Closure and load ClojureScript and Google Closure JavaScript files through the Metro server. But this is the core of ClojureScript's hot-reloading capabilities without caveats. In Google Closure namespaces can be represented as nested JavaScript objects which delivers pervasive late-binding - which simply cannot be done with ES6 modules because imports will be captured (early bound).<p>The REPL bit (which is an independent piece from the hot-reloader) just runs on top of react-native-tcp-socket.<p>The only tricky part is that we need to be able to require Node libraries and assets into ClojureScript during development. This is done by a compiler pass - first we start at the entry point of the ClojureScript React Native project and follow the dep graph collecting all libraries required from `node_modules`. This is dumped to a file that is required transitively by `index.js`.<p>Asset handling is done as a simple compiler pass over every AST node searching for JavaScript `require` statements in the ClojureScript.<p>The end result is that we have an extremely rapid development workflow that simply is not possible with other existing technologies - not React Native, not Flutter, not SwiftUI. All of our apps are built via live-coding from our text editor of choice + REPL (either embedded in IDE or via shell).<p>Happy to answer any further questions!