Pacejam Alpha
Designing and coding the first iteration of my Graduate Capstone Project:
Fall 2025
Role: Lead developer and System Architect
Project Overview
Pacejam is an iOS app that syncs the music you listen to to the speed of your footfalls while you are running. It makes use of the Spotify API, a secondary supporting api hosted on Rapid, the Swift programming language, the Core Motion and Health Kit frameworks from Apple, and Xcode as the IDE for the project. Over the course of the semester, I was able to take Pacejam from just an idea to a functioning IOS app with working core functionality.
The Problem
Since the advent of portable music technology like the Walkman in the 70s and 80s, music and running have gone hand in hand as complimentary experiences. Although Streaming apps like Spotify and Apple Music have made access to music easier than ever, there still remains one big issue: sometimes the vibe of the song is just wrong for exercise. We purport, that a big reason for this feeling is that the tempo (in Beats Per Minute) of the music music does not match the running cadence (in Steps Per Minute) of the user.
Imagine you are running through a wooded area, the dappled green light of the trees illuminating the area around you, and a gentle breeze moving the canopy above. You are running along a forest trail, listing to music, breathing heavily as you begin to ascend the hill in front of you. You’ve been listening to your “Liked Songs” playlist and so far, banger after banger has fueled you with the energy to keep going. You reach the base of the hill and begin the climb, muscles burning, each step taxing, but the music keeps you going… and then tragedy strikes. Spotify chooses a seldom listened to song that is a crushing reminder of your last failed relationship, and your momentum crashes. The hill which seemed so doable before, now feels like an insurmountable mountain, and you stop.
The Solution
Pacejam was the solution that me and my group members dreamed up to solve this problem back during the summer of 2025, and when it came time to begin developing it, I shouldered the burden of being our primary developer. This article will focus solely on the technical aspects of developing this application, as that was where my primary focus was for the fall semester.
I started this project by doing some research into whether it was technically feasible to create an application with the capablilty to do the following:
- Control a user’s Spotify Playback from another application
- Gather tempo, genre, runtime, and other data on individual tracks in the spotify catalogue of tracks.
- Gather a user’s cadence in SPM in real time
These, I reasoned, were the core technical hurdles I needed to overcome in order to make the core feature of Pacejam, Tempo Matched Music, a possibility. I started with what I thought would be the most difficult challenge: Spotify playback.
Get Ryan Alford’s stories in your inbox
Join Medium for free to get updates from this writer.
With a fresh Xcode Project, I began to experement, first attempting to learn the basics of coding in Swift, rather than Swift UI, the UI framework. I quickly discovered that unlike Java, Python, or SQL, I couldn’t just write a function and test it on the console within the IDE. Every function, if wanted to test it, needed to be connected to some piece of UI, or put within the convoluted unit testing framework that Xcode requires.
After several weeks of learning how to create an OAuth 2.0 flow, and setting up the backend of my application on the Spotify side, I eventually cracked music playback, having implemented basic play, pause, skip forward, and skip backward functionality. With my crappy iPod clone, I had now completed the first of my major challenges.
The next task I set myself to was tracking my cadence. This process was simpler than I thought it would be. Apple made it very easy to import the packages necessary to access my phone’s onboard pedometer, and within a few hours of setting out, I had successfully implemented a cadence tracking function that could update at a rate that I set.
For the last goal, I opted to delay a bit. My original Xcode project was a bit like an artists sketchbook. It was full of drafts, references, and ideas, but the architecture needed an overhaul in order to be usefull for me going forward. This was the impetus for me to rebuild the applciation from scratch, implementing the features I had previously developed in a much more elegant way, in keeping with the design work that my group members, Kylie and Mel were doing on Figma.
With the app successfully rebuilt, with functioning music playback, and cadence tracking, as well as authentication into my Spotify library, I set about gathering tempo data on the songs that I was playing in the hopes that I could write a function that combines all of the basic features together, and really match the music to the pace in real time.
I encountered my first wall early on. Spotify had actually depricated the api endpoint I needed to get track data. Not to be deterred, I looked for alternatives. First I attempted to use a track recommendation API called “ReccoBeats”, but after sinking 2 weeks into trying to get it to work, I was unable to make a single call anywhere other than in the search bar of my browser. I then opted to pivot and look online for other alternatives. I eventually found a paid track analysis API on Rapid, an API hosting plaform owned by Nokia, and began working with it. Rapid worked much better, and within the afternoon, I had officially spent my first bit of development money on this project, and had made a successful track data function within Xcode.
With the ability to independently play music, get track data, and get the currrent running pace, I then drafted the first iteration of the tempo matching function, attempting to search the user’s library for a song live. I quickly hit another wall. The rate limits of the API’s I was using would not allow for such an action to take place with any degree of quickness.
My second attempt proved to be exactly what I needed. Rather than trying to process all of the data live, I decided to try caching my library ahead time and using a data table to power the music matching function. This approach worked much better, and meant that me and my group members now had the ability to demo the core functionality of our app live.
A quick UI update from my designer friends later, our app now has the core of its functionalty working, but the work is not yet done.
Results
Pacejam is working, and it now runs on iPhone successfully. I honestly got further this semester than I thought was initially possible, and have a strong idea of what needs to be done next. First, I cannot proceed any further without implementing a database. The problems I am encountering with a limit to the amount of songs I can cache, as well as the need to retain information between sessions and installations means that it is time to deep dive into the world of PostGre SQL. Luckily my experience in the MIS program at UGA has prepared me for the next steps of this project. Secondly, our algorithms for selecting music, and our running features are primitive right now. Implementing code to show user pace (mile time) and distance are on the horizon, as well as creating logic for guided workouts, a goal set forth by group members.
In conclusion, Pacejam has become more than I thought possible for this short first few months of development, and I am very excited to see how far I can take it.
