Minimal mobile apps for Android and iOS

Just as the #1 feedback, being able to use this widget on iOS is a game-changer. The browser shortcut doesn’t work this way. With the browser shortcut, when the screen goes to sleep (like it’s supposed to) the music turns off. With the browser shortcut I can’t listen to a playlist on my phone and do something else with my hands, since I have to keep on coming back to touch the screen to keep it awake.

With the expo wrapper it functions more like a music app.

Obviously it would be nice to have some tweaks (like show what artist), but since the point is to listen when the screen is black not being able to see it is not an issue.


If the iOS PWA doesn’t allow for screen-off listening, it is rather useless!

Android PWA has always had this. IME, it is functionally indistinguishable from an app, although a recent update by Google seems to have removed most audio control buttons from the widget :thinking:

On Android:

This makes even a “minimal” app indeed a game-changer for iOS. Any ideas why screen-off listening doesn’t work on iOS PWA?

1 Like

it says " This beta isn’t accepting any new testers right now. "

Apple approved the latest build, 1.0.2, shortly after you posted this, so hopefully the link should now finally be open for public testing now.


It looks like I’ll be able to publish apps on Google Play (for both testing and eventually publicly) once they verify my Google Play Console account:

Screen Shot 2022-02-20 at 11.00.36 AM


Added a github spike to track this effort.
Repeating some of the thoughts I shared on the github ticket below:

  1. How would we manage the repo on github?
  2. How does this temporary solution gel with the long-term goal of building a mobile app
  3. Should we also be testing (at-least locally) with the development branch of stream repo considering the Wordpress transition should be launching within the next 2-3 weeks – change the WebView source prop to source={{ uri: '' }}. As far as I know, the only difference for the streaming player from a visual perspective should be signup/login flow and account settings
  4. Establish a process of QA testing the the mobile app when the streaming player is going to be updated

@piper, I just wanted to take a second on this thread to seriously thank you for stepping up and using your skills to just do this.

I have pushed and pushed and pushed for this exact approach to a temporary Resonate app for years now, and I’ve felt it’s been a struggle to get anyone to take me seriously on it, so this is an enormous breath of fresh air for me personally.

In my view, with just this simple first step, we are one step closer to making this platform as accessible as it needs to be in order for it to be taken seriously by those looking for a music streaming alternative. It’s not gonna be perfect right out of the gate, but again, one step closer… Accessibility.

Again, thank you.


Thank you so much for the kind words, that really means a lot!

I wanted to give everyone another update on our progress as of this morning:

has been merged, and I’ve pushed the new release associated with it 1.0.4 to both Apple and Android store.

Apple is still reviewing our release so that should be pushed to TestFlight and I’m hoping that should be available for everyone on iOS later today.

With respect to Android, Google Play Console verified my ID and have let me submit the Android 1.0.4 build for their review. Once approved, we should be able to get a public link out to everyone for external testing:
Screen Shot 2022-02-21 at 9.55.10 AM


New pull request up to address this issue reported by @boopboop (Minimal Mobile Stream App - #21 by boopboop) where iOS Now Playing and Control Center widgets show current page title instead of page user is currently browsed to. This wouldn’t show them album art metadata, but at least the Artist Name and Track Title would be properly functioning for iOS at least. (Android has album art and artist and title fully functional.)

It seems this is industry standard as well, most commercial industry web players have this enabled (I think because users like having a tab in their browser and being able to glance and see what song it changed to without having to switch to the actual tab).


It appears that the Google Play Console will not let us conduct open testing before we do internal, so here’s the link:

An Internal Google Play Android Build is now available for internal testing.



I’d love to jump in and give the Android build a test run if that’s OK. Seems my Google account needs to be given access first. Really excited about this!

1 Like

@CPacaud, @LLK, as of this morning, an Open Google Play Android Build is what looks like is almost available for open testing.

It appears that I can see the public link because I’m logged in, but others may not be able to because Google is still reviewing and we’re waiting for them to approve our request for open testing. I thought since they were showing me a public link that we were ready to go, but clearly not quite yet. In the meantime, if you’re on Android and would like to test, private message me your email and I will get you added to the Internal Testing list.

Just to give everyone visual, our internal testing looks like this:
Screen Shot 2022-02-22 at 10.35.16 AM

And our open testing track looks like this:
Screen Shot 2022-02-22 at 10.35.30 AM

It looks like it can take an average of a week to get approval for the Google Play Store. So we should be very close.


You’re incredible !


Hi all! Rich Jensen sent me a link to this forum so I could check out the iOS beta.

I wasn’t able to get past the launch screen because I’ll never toggle App Tracking on. Is there anyway around this in future builds? The stats for people keeping the toggle off are something like 96% last I looked.


I personally wouldn’t turn on App Tracking for a single or any app, even though only turning on the option for each app to individually ask permission, it just feels bad from a UX standpoint. I don’t like the idea of anyone having an “icky” feeling!


This is “just” a wrapper for the webapp, so you can say no to the actual tracking cookies on the next screen just like on the web app.

You can check out the code here GitHub - resonatecoop/stream-app: A mobile app for playing music on Resonate, an open source music streaming co-op. This is repository is in maintenance mode, with long-term goals of ejecting react-native-webview and developing this repository:
it’s not going to track you more than the website is.

But for the real issue - until a react native (or native-native) app is developed, it seems like this screen will have to continue to exist.


The problem is it’s impossible to get to the next screen?

1 Like

@piper do you think having a link to the code here would improve trust?


I think “to ensure you get the best esperience” might be misleading because “best” is a vague term and what’s better for someone might be worse for some other (and usually what startups think is “best” is absolute shit). I think you could skip that and only say something like “Resonate only uses cookies to garanty core functionalities, such as keeping you logged in for a while, or remembering your theme settings. No other type of activity is tracked” and here I 100% agree with @boopboop we could add a link to the codebase or something and add “if you want to make sure of it you can check our code here” or “if you don’t want to take our word for it you can check our code here” something like that.


I’d be happy to try to test it on my Apple devices. I’ve got business grade internet here so shouldn’t have any issues with connection etc. Just let me know what the turn around time is and I am happy to submit bug reports to whomever etc.

Hey Kallie,

Yes, we’d be happy to have you test! Here’s the TestFlight link. Feel free to post any bugs you find in this thread. Currently, it will only allow you to test if you enable Tracking for the app in Settings > Privacy > Tracking.

1 Like