Convertify iOS
In college, Convertify was my first major personal project.
The goal of Convertify was to convert Spotify Playlists to Apple Music and vice versa.
It ended up receiving tens of thousands of downloads on the App Store which was exciting, but was ultimately shut down due to the effort required to maintain an iOS app.
Architecture
Convertify was designed as a local-only system to keep cost at a minimum. The $99 Apple Developer fee was already more than I wanted to spend as a college student.
Get playlist tracks from source
For the playlist source, Convertify made an API call to retrieve the tracks. Each track from Apple Music or Spotify comes with a unique ID, and those IDs don't match between services.
Search for similar tracks in destination
To figure out which track ID to add to the destination playlist, Convertify called the destination's search API. A search request similar to this was made:
{
"track": "Keep Moving",
"artist": "Jungle"
}After repeating this for every track in the source playlist, we had the track IDs we wanted to add to the destination playlist.
Populate destination with tracks
Once all on-destination IDs were collected, Convertify would call the destination's API (batched when supported) to append the tracks.
Benefits of local-only architecture
The local-only architecture had these major benefits:
- $0 infrastructure cost (because there was no infrastructure)
- User privacy (because I had nowhere to log anything)
Drawbacks of local-only architecture
The local-only architecture, while cheap, was almost certainly the wrong decision to make.
- Each patch required a new App Store release
- Users had to keep the app open while converting Playlists
- Unnecessary battery drain with hundreds of network calls
- No insight into system health
Struggles I had
Convertify was the first piece of software I made that people actually used. It was a much larger undertaking than I originally expected!
So many edge cases
Apple Music and Spotify are constantly in an arms race to see who can add the most features, and it consistently broke Convertify.
Music videos, podcasts, "radio stations", and more edge cases kept popping up as new features rolled out.
It was like playing whack-a-mole but instead of moles I was wacking new bugs that came up with Spotify added grocery shopping functionality.
App Store woes
Submiting an app the the App Store was a surprisingly large pain. New revisions have a lengthy review process, and each review requires a lot of work.
API abstraction
Rather than using a slick library like Moya to wrap the Apple Music and Spotify APIs, I spread the networking layer around the codebase. This was simply because I didn't know any better at the time. Oops.
What if I built it today?
If I built Convertify today, I would make use of an workflow orchestration system like Logic Apps in Azure or Step Functions in AWS.
That way I could:
- Make small fixes to edge cases without having to update the client App(s) as well
- Allow users to close Convertify while converting
- Retry and back-off more easily
- Gain insights into Convertify's health