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.
3 Likes
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
Hey @jonabechtolt, welcome! Thanks so much for giving this a test run. I totally, totally, understand your concerns. Before developing this app, I had this Allow Apps to Request to Track setting permanently switched off (like 96% of users do as you’ve described), and had never even looked at that prior to this work.
We’ve actually updated the language described here to better describe the situation and feel less “icky” - users can specifically enable permissions for Resonate without toggling on the entire Allow Apps to Request to Track setting. Here’s how it looks now, and everyone, please, if anyone has ideas for how to better describe this I’m more than happy to change the text on this page:
Just to provide more context and to add to what @boopboop has said above, this is the issue being addressed with this feature: Apple devices on iOS 14+ are required to ask users for this permission in this context because this app uses cookies for authentication and localstorage for remembering user logins and device theme preferences. However, even though there is a Cookie disclaimer when loading up the website for the first time (which you can still decline/configure), this wasn’t enough to satisfy Apple and allow us to publish the app on the Apple App Store. There are many kinds of cookies, some “good”, some “bad” (which is why FireFox’s Facebook Container is so great, for example), and Apple does not differentiate between them in this context.
Thus, users will see this screen unless they allow permissions (which is why it says Disallowing tracking permissions precludes the use of this app). Again, I attempted to summarize this situation in the second paragraph, but if there’s any way to improve what’s being said and explain better, I’m all ears! Since users can in fact decline/configure cookies after allowing the app permissions from the top level, maybe there is a better way to say explain this so users aren’t as alarmed.
Apple should approve our latest release sometime today, so this updated language should be live and available on TestFlight before the end of the day.
^ post I accidentally deleted above, reposting here for transparency.
Circling back to this important point raised by @jonabechtolt: I believe I may have worked out a solution to the Tracking settings situation. I’ll leave the technical jargon out, but I was able to put together a small component that allows a user’s Tracking preferences to be honored by the stream repository. We unfortunately won’t know whether or not it satisfies Apple’s criteria for sure until they approve the new build for use in their App Store. I will keep this thread up to date when I hear back.
Also, here are some other exciting updates and additions that I was able to implement as I was digging into the above issue that are helping things feel more “app-like”:
- Forward and back gestures are now functional for navigation and behaving as expected. This makes it easier, for example, if a user navigates to the forum by clicking
Join in on the discussionafter clicking a tag, they can get back to the player easily. It also seems to make navigation less clunky in general because before your only option was pressing the Resonate logo in the top left to go back to the home page to get out of whatever artist/playlist/tag etc you were on. - Pulling down on a page, if you’re at the top, reloads it.
These two features are pretty much standard among modern apps, so I’m very excited to get all of this out for testing ASAP. Keep in mind that every new build that is submitted has to go through the process of being reviewed and approved by Google/Apple, so I appreciate everyone’s patience on this! 
4 Likes
Hey @jonabechtolt,
Version 1.0.7 has been released on TestFlight, if you’d like to take a look. This update allows you to use the app without allowing cookies. You won’t be able to log in, as currently the only method of logging in is through cookies.
I believe we’re hoping to set up an alternate method of logging in for users that decline cookies for the stream (the website) repository, which would subsequently allow it for app users as well, but that isn’t in place yet.
2 Likes
@CPacaud @LLK, Google Play has finally approved our Android Open Testing Build! Give that a whirl and let me know if you have any access issues.
Other exciting news on the app front: per MDN’s MediaSessionAPI Browser Compatibility, iOS 15 is required for metadata to be seen in the Control Center/Lock Screen. I updated my phone to iOS 15 and voilà, we’re officially in business:
In other news, I’ve implemented a change to the player that should respect device color preferences on the first visit, even before a user logs in and has access to change their theme preferences! This will provide a far more sensible experience to users with their phones in Dark mode who use our app for the first time, because in that situation they had a dark status bar that correctly respected their theme preferences and a player that did not.
Last point - to update my phone I had to remove a bunch of apps to have enough space, and reinstalled Twitter post update. I noticed they have their “equivalent” to our Cookie Policy screen in the app functioning slightly differently, they show a screen detailing their policy with a Continue button at the bottom. Users can scroll through this and then press Continue, and then the app asks for permissions. As we currently have it, the Cookie Policy shows up behind the Allow/Deny Tracking prompt, and, while the user can still read the text below the prompt, it’s poor UX. Over the next couple of days, I will aim to make our app behave more like how Twitter manages it. I’ll also be adding links to our open source projects on GitHub (as others suggested above), so users can check out our code and be reassured that we aren’t up to any funny business.
7 Likes
Hey @piper, do you have a preferred method for receiving feedback/impressions/issues? Is anything fair game? I’ve got a fairly custom setup for my phone (/e/ OS on a Teracube 2e phone) so I may come upon some pretty device/os specific issues.
3 Likes
@CPacaud I’m happy to receive feedback in this thread! Curious to see how things fair on your custom setup 
1 Like
A few more updates are on the way.
We’ve added a GitHub link to the Cookie Disclaimer as others suggested above. We also now let the user press a button before being prompted after they’ve read the policy, which makes the feel app a bit politer to the user. Again, this screen will only ever be seen by iOS 14+ users who have Tracking toggled on (which is 4% of users per the resource posted above in this thread).
Screenshots of this in action are visible here:
The new build (1.0.9) with this, along with disabling the pull down to refresh the page feature (it interrupts playback in a way that a user would not expect, and shouldn’t be necessary) has been reviewed and released on both Android and iOS platforms in the links in the first post in this thread.
1 Like
Today, @brndnkng asked if the app was ready/usable enough to post to social media accounts, as it could act as a boon to fundraising efforts.
I know @auggod had some reservations with respect to taking the app official/public on the App store
(perhaps because the UI was very preliminary at the time or because the beta player https://stream.resonate.ninja is not live yet), so I wanted to raise this question in this thread and get everyone’s feedback. Because those changes are not on the main website (namely https://github.com/resonatecoop/stream/pull/182, which makes the player match device theme preference the same as the status bar does) users will not have access to the absolute latest and greatest just yet. Update: as of March 2, 2022, these UI fixes are live!
Outside of this, in my testing things seem to be working pretty much as expected, with the exception of back arrow icons appearing as tiny/invisible on iOS and the Learn dropdown is non-functional on iOS.
As of the time of writing this, here’s the current strength/limitations breakdown - The way in which we’re wrapping the React Native code using the Expo platform is providing features that the Progressive Web App (i.e Resonate’s stream website when viewed on mobile) lack:
• Downloadable app from Google Play/Apple App stores and automatically creates a shortcut to the app on the user’s Home Screen
• The feel of the user interaction is improved: buttons and scrolling respond to user input in a less clunky and more app-like manner
• A more immersive user experience as the additional screen space because there is no browser address bar.
• (iOS 15+ only) A functioning Now Playing control visible from when the phone was locked or the user swipes to use their Control Center. (This was already functioning for the Android Progressive Web App [the website on mobile].)
• (iOS only) Playback continues even when the phone is locked, background play functions as expected.
Current limitations we’re currently aware of (which are also impacting the Progressive Web App [the mobile website], and will need to be solved by fixing them there):
• The UX for a listener creating account isn’t as intuitive as we’d like.
• (iOS only) the Learn dropdown in the top center is non-functional, pressing it does nothing.
• (iOS only) Back icon is invisible or tiny.
Edit: It was also emphasized (and I agree) that this a preliminary alpha created by one user, not a full fledged app created by Resonate at a whole. We don’t want to give the false impression that Resonate has a large dev team and does not need funding.
5 Likes
Imo phrasing it as a call for beta testers might be the best option.
- sets expectations
- gives hope
- people will be happy with the app once they use it
- it shows real buy-in from resonate
Edit: Something else - it invites users in as members, as people with something to contribute - their friendly and valuable feedback and collaboration, as opposed to never-satisfied customers.
6 Likes
Imo this line of thinking should be extended to the web player as well (and it should have beta clearly displayed in its header), for exactly all the reasons you listed. Wholeheartedly agree.
4 Likes
A couple of notes after using the player a little bit on Android;
-
App name appears as “stream-app” in launcher (Unlauncher, Bliss Launcher (/e/'s default launcher).
-
I’m being automatically logged back in when I open the app after logging out and closing the app - was expecting to have go through log in again.
-
I don’t get music player controls in the system notification area during playback.
-
The “currently listening” bar in the lower area of the app allows for only a very small number of characters for Track and Artist names.
-
This part of the log in flow is a bit confusing -
there are two Log In button visible, the one at the bottom gets you to the Log In screen, the one in the middle actually logs you in. Pressing the bottom one while on the Log In screen does nothing. -
System “Back” button takes me out of the app back to the launcher when I’d expect it to back away from the current screen / stay inside the app.
-
Artists/Labels/Releases Browse pages would benefit from having a “list”-like view. If you’d ask me, I’d like having a view similar to what’s on the Track page for those, and an even lighter list view for the the Track page (e.g. group all tracks under a group as a Release, with its associated artwork/artist only shown/listed once for the whole group.)
-
The Track browser page’s performance feels sluggish on my phone - not a powerful beast, but usually handles anything OK.
-
On the UX/look and feel side of things, I’m feeling a lack of feedback on button/UI interaction. For example, I would expect buttons to light up as I touch them, indicating interaction has been made. Sometimes during the few moments between a button press and the action actually happening, without any feedback, I’ll be tempted to press the button again (“maybe I missed it?”). Likewise, I cannot know if I misclicked anything as the unwanted action will occur and I won’t know what I did wrong.
4 Likes
This is great feedback @CPacaud, thank you for taking the time to write this all out!
Yes, this is an interesting subject I’d like to hear folks’ opinions on. I didn’t call the app “Resonate” because I didn’t want it to seem like it was an official app put together by a team of people as opposed to merely a contribution from a member of the community. I called it stream-app as it essentially ports Resonate’s stream repository to mobile. I’d be happy to rename it since there aren’t currently any other apps existing yet.
I think I know what’s causing this. I’m going to release a new version of the app with this fixed, and hopefully this will make this behave as expected (should be as simple as changing a true to a false).
According to the current MediaSession Browser Compatibility, I’m suspecting your phone’s default browser may be using WebView Android or a browser that hasn’t implemented MediaSession support yet. @CPacaud, if you want to test the stream player in your phone’s default web browser and let me know whether or not those controls show up for you there, that would be helpful! If they don’t, then it’s definitely a lack of MediaSession support from the browser.
Also, I see that the tracks screen is laggy/sluggish for you. Please let me know if using that page in your phone’s default browser is a lot faster or about the same so we can compare, when you get the chance! The app should be at worst slightly slower than your browser, but shouldn’t be by much.
The rest of your points apply to the player viewed on mobile, and it’s all really good feedback in my opinion. I’m going to add these as issues in that repository so they can be addressed.
Speaking more generally, some improvements went live today to the website player that make the status bar and the app both match the device’s theme preferences, so the status bar should always be dark if a user’s phone is in dark mode and the rest of the app will follow, etc. 
3 Likes
I think the name of the app should 100% be “Resonate” once it’s live, if there is consensus amongst members on what we’re left with. For whatever that is worth. Anything else would just be confusing and inconsistent, in my humble opinion.
5 Likes
I agree. @piper you should just go with the confidence that the community validates your work to consider it “official”. We can decide about that through a vote if a formal process makes it feel more legitimate but I’m 100% confident we’re all ok calling it our own, it’s too critical of a feature to not have the official stamp and more basically it just looks good already.
4 Likes
Cool, I’ll test it on my iPad as my phone is too old to support it. But backwards compatibility is always nice? 
1 Like
Hi just testing on my iPad now. So far the “Learn” tab in the top left corner doesnt do anything… or is non responsive. There’s also, what I can only assume is a back button? Its a white square just under the resonate logo, once you’ve searched a style of music. Right now it just appears as a white square, but if I click on it it takes me back. However, when it takes me back, while it takes me to the previous page, it orients me to the bottom of the page.
I dont know if this is useful?
2 Likes
With respect to the app name: that’s great feedback everyone, I totally agree. As of the latest version out today, 1.1.0, the name is Resonate! 
I suspect the yellow dot next to the name just means it’s in Open Testing and not an official release in the App Store yet. Check it out:
Along with (hopefully) fixing @CPacaud’s session being persisted even after being logged out, this new version also seems to have fixed an issue where clicking the dropdown would turn the user’s status bar text the same color as the background (making the text almost completely invisible to the user). @CPacaud, when you get a second, could you please let me know if version 1.1.0 still keeps you logged in even after you’ve logged out?
As far as next steps for the app, one of the remaining things to fix that I want to target next is the user gets flashed the Cookie Policy for a brief second while the app checks the users Tracking preferences (i.e they’ve already been asked to accept or deny permissions and the app is checking which one they picked basically). It would be ideal to just keep the Resonate logo front and center here until the player loads, and only show the Cookie Policy if the user hasn’t made that decision yet.
After that, it will be a matter of addressing issues and UX problems inherent to the player itself. Thank you all so much for your ideas and feedback!
Interesting, @KallieMarie, what iOS version is your phone on? It might be Apple being snooty about only letting more recent OS versions use TestFlight. I was able to use it with iOS 14, so I’m guessing you’re on something earlier than that. Note that only iOS 15 supports the Now Playing widget.
Unfortunately, this is a known bug inherent to the player. I’ve been digging into the player code and my knowledge of it has improved in recent weeks, but I still have a long way to go with my understanding of everything. Hopefully we can figure out how to get this one fixed soon!
The functionality of this app is tethered to the functionality of the website player. If we have a bug or UX weakness in the website player’s code it will typically also affect the app. But this can also be a strength - when we fix bugs with the website player we also improve the app for everyone. So it can be bit of a double-edged sword. With the news this week I’m hoping we get a few more software developers keen on volunteering their time to help tackle some of these issues.
5 Likes
