deeje.com/musings: Differentiating Apple Music
This post will review the history of music APIs in iOS, and discuss some of its advantages for developer+affiliate opportunities, as they relate to competing “Music as a Service” (MaaS) providers and their developer “Terms of Service” (TOS).
And at the end, I have a simple ask.
Music APIs in iOS
Let’s start at the beginning, with the release of the MPMusicPlayer** SDK in iOS 2. It allows a developer to access the system music player object, find and iterate song objects in the user’s music library, control their playback, and access various rich metadata (e.g. duration, BPM, album art).
One of the most significant benefits of MPMusicPlayer is that developers can use this in their paid apps.
Why is this significant? Every other MaaS forbids developers from generating revenue. Why bother trying to innovate if there’s no way to pay the bills?
But Apple has taken a different approach, seemingly making it a point to enable their users to access their music in a variety of scenarios. For instance, even with FairPlay on iTunes-purchased songs, iMovie specifically let users add songs from their music library to their home movies, regardless of their origin, and then export the resulting movie. Apple wouldn’t let DRM get in the way of personal use, which seems very fair.
Magic of My Music
When Apple Music arrived, something magical happened for subscribers. Any song you add from their catalog to your music library becomes available to MPMusicPlayer. From a developer perspective, the streaming songs mix seamlessly with iTunes-purchased songs and other imported song files.
I’d like to call this “Apple’s MaaS”, in that apps that use MPMusicPlayer just work, as a user would expect. For instance, tappr.tv creates a social, visual “dance floor” for your fingers, building on top of MPMusicPlayer. You can dance to any song in your music library, regardless of how you added it (imported, purchased, or via subscription). When you create and publish a dance, only the song metadata is stored, and the song is found and played only thru the user’s music library at playback time.
In other words, tappr.tv is an Apple MaaS app. Pretty cool! So far, 80,000 users have spent almost 300,000 minutes producing over 5,000 dances, which have subsequently been performed over 90,000 times for other users. tappr.tv has achieved this, in part, by analyzing the user’s music library and creating engaging and immersive experiences around their most favorite songs, as determined by combining ratings, play counts, and recency metadata.
And, tappr.tv can make money (by helping users discover new music, and offering tools for dancers). This is something that tappr.tv can’t do thru Spotify or Rdio (RIP) or even Rhapsody. Each of their TOS stipulates that developers CANNOT earn revenue.
There’s one more pro feature of Apple MaaS that I want to highlight: Zero Login.
All the other MaaS competitors have clunky user mobile login experiences, and use expiring session tokens, which means, users effectively have to suffer thru logging in every day.
OTOH, MPMusicPlayer leverages iCloud, which the user signs into and configures globally in Settings. From an app’s perspective, no need to bother the user, just go find and play songs. All the subscription logic, and inherent DRM, is handled automatically. Simple.
The seamless music library, the ability to create value, and zero login give Apple’s MaaS the advantage here. In the race to dominate the music market, Apple MaaS looks like a winner!
Except… MPMusicPlayer is missing two key features found in MaaS competitors: Search and Playlists.
Didn’t I say “find” above? Yes, but it is different from “search”. Find is “exact match”, whereas search can be much more fuzzy. For instance, when tappr.tv searches for a song to match a dance, Spotify MaaS can return a Muzak version of a song if the original is no longer available (a frequent occurrence in subscription services, unfortunately). And it can exact match on fuzzy inputs, too, which helps developers tremendously in a world full of users still importing songs with little-to-no metadata. Apple MaaS currently can’t do either, and the user experience suffers.
And social playlists are something I want as a user in tappr.tv, but it seems ridiculous for me as a developer to have to re-invent the wheel here. Why can’t developers leverage the playlist management that is already implemented by Apple?
Apple introduced the iTunes Affiliate program and iTunes Search API*** soon after iTunes the Store first appeared. It is chock full of song metadata, and is searchable for iTunes Affiliate members. It even includes 30-sec previews and ways to drive sales or subscriptions with affiliate commissions. Note, again, that this is in stark contrast to the other MaaS, which offer no mobile affiliate opportunities.
What I really want, as a developer and a user, is iTunes Search to be rolled *into* MPMusicPlayer, such that previews would be replaced with full songs for Apple Music subscribers. iTunes Search becomes search the “catalog” metadata, and MPMusicPlayer becomes search the “user’s” metadata, and it all becomes search with “catalog” and/or “user” as predicates. Seamless. As a user, apps that find and play music from my library could also search and play music via my Apple Music subscription.
Differentiating Apple Music
Let’s recap the various pieces of Apple MaaS.
iTunes lets users buy songs, which go into their music library.
Apple Music allows subscribers to add songs to their music library.
MPMusicPlayer lets developers access a user’s music library to add value.
iTunes Search lets developers search for songs available in iTunes or Apple Music and drive affiliate sales.
Apple Music 2.0 = iTunes + Apple Music + MPMusicPlayer + iTunes Search API, all rolled into one
This would very clearly differentiate Apple Music from all the others: user-centric, developer+affiliate friendly, and win/win for all.
How can you help?
OK, here’s the ask: who else should read this?
Can you forward this to others who might grok what I’m suggesting, perhaps even to someone who might have some insight or influence in these matters over at Apple?
** For the sake of brevity, I’ve shortened the name of the class; it is actually MPMusicPlayerController, part of the Media Player Framework https://developer.apple.com/library/ios/documentation/MediaPlayer/Reference/MediaPlayer_Framework/index.html
Originally published at blog.deeje.tv on January 8, 2016.