It’s easy for the service to know if the user account has listened to the podcast, and equally easy to track listens in a webapp. The line between webapp and app is very thin these days anyway.
The line between webapp and app is very thin these days anyway.
While the user experience may be similar (and in many cases is identical) access to device information is different. For instance, a webapp can not determine the devices volume whereas an Android app can. Device APIs can provide much more confidence that an activity has occurred. I doubt this was an arbitrary decision or gate-keeping by the developers.
More likely it’s to ensure that you’ve actually listened to the podcast you’re rating
edit: Can someone explain the downvotes, what am I missing here?
It’s easy for the service to know if the user account has listened to the podcast, and equally easy to track listens in a webapp. The line between webapp and app is very thin these days anyway.
While the user experience may be similar (and in many cases is identical) access to device information is different. For instance, a webapp can not determine the devices volume whereas an Android app can. Device APIs can provide much more confidence that an activity has occurred. I doubt this was an arbitrary decision or gate-keeping by the developers.
I’d say you’re getting downvotes because it’s not a design standard to block rating access based on confirming someone’s consumed content.