TLDR;

I'm keeping all (handle logic and store state) in js in my music player app and this works even when app is closed/killed if we registered it properly as a foreground service.

What I was trying to do

I was playing making a music app with the next features:

• track queue

• auto play next song

• play/pause/stop

• play when app is closed

• control the app with a persistent notification

What I did

I found a lib that could do the whole work exact as I needed... but it was too buggy. So, should I write all that code in a Java/Swift native module? before giving me up I looked in Android docs about process and services and I found that the app and service code runs in the same main thread, so all I need is a service attached to a notification and my app bounded to that service in order to prevent be killed when app closes. Based on this, we can keep all our logic (skip to next song, etc) and state (track queue) in js and use native code just to play music and handle interactions with the notification calling the js code to handle it. But, before trying that, I wanted to try some native libs to handle the audio player and the notification.

• react-native-sound

• react-native-music-control

Results

As react-native-music-control uses startForeground(NOTIFICATION_ID, notification); our app is already safe of system clean up. I tried this and indeed it worked as expected. I tried simulating memory warning and it still working and skipping songs perfectly. I "killed" the app from apps menu and it still works as expected.

But what about iOS? I don't know much about this one but as iOS is "inspired" on unix system too, it just worked as expected. Here it worked as a music foreground service because we have to say that in Info.plist

Questions

• Is this enough to consider it a good production practice at least in this context (music app)?

• Am I missing something that could be a problem in the future?