[jonathanyc]

The app looks really good! Based on the title I thought it’d be something you made most as a testbed for Racket so I was surprised to see the app itself actually looks great :D

I tried looking through your blog but couldn’t find anything except the 40 minute YouTube video for your other app. It sounds like both the UI and the audio-related code are in Swift? What code ends up actually being in Racket then?

[Bogdanp]

That's right, the UI and the Audio Engine bits are in Swift, because it's easier to interface with those Frameworks directly from Swift (and not fight the platform). Everything else (the Database management & the models, the download manager, ID3 parsing, parsing release notes, syncing with the backend server, etc.) is implemented in Racket and is portable.

[jbhoot]

> Database management > syncing with the backend server

Do features like these, when implemented in Racket, consume more resources (battery, CPU, etc.) than if they were implemented using the native API equivalents (e.g., NSURLSession or whichever is more applicable)?

In the larger context of cross-platform apps with a common core written in a non-native programming stack, I often wonder this about network and disk I/O management. I understand using the native APIs for other "I/O" like UI, hardware interfaces (bluetooth, accelerometer, etc.), because they often don't have an equivalent API in the programming stack used to implement the common core.

As far as I know, Capacitor wraps over the native APIs.

[jonathanyc]

Thanks for the reply! That makes a lot of sense.