#6: Launch Party 🚀

Music Library Tracker v2.0 finally goes live... and then v2.0.1 goes live 🤦🏻‍♂️

Feb 15, 2023

Dear Reader,

The big news this week is that Music Library Tracker v2.0 has finally launched on the App Store complete with support for Spatial Audio scanning and notifications. I’d like to thank all of you that took part in the TestFlight beta and provided feedback, especially Steve Martin who was a huge help in fixing a number of issues. The TestFlight version will remain working until Monday 20th February at which point you’ll need to migrate to the App Store version (there are a number of changes since the last beta build which I’ll dive into shortly).

Unfortunately the launch was marred slightly by a rare issue that was affecting a handful of users. The scanning engine would pause half way through the Spatial Audio matching process meaning the app would need to be force quit (which did not necessarily stop the issue from happening again on the next launch); not a great look, especially as the reports came in just as I’d finished sending out emails to potential reviewers. It turns out it was a threading issue; the code that runs when you have songs missing from my database was not returning back in the same thread so there was a random chance the app would just stop execution at that point. The fix was quick and luckily Apple were able to approve v2.0.1 within a few hours so hopefully no lasting damage done.

Speaking of reviews, it would be a huge help to me if you were able to leave a review on the App Store or recommend the app to anybody you know who may find it of interest. It’s currently on a 25% discount for the next week (so $2.99 or thereabouts) and is a free update if you’ve already purchased it, even if that was 7 years ago when the app first launched. My thanks in advance!

Leave a Review on the App Store

I’m going to take a short break and skip the next scheduled issue as, completely by chance, I’m away on holiday. The next issue will be on the 15th March.

— Ben

Redesigning the Music Library Tracker UI

As I mentioned last issue, I wasn’t particularly happy with the interface of Music Library Tracker. There were three key areas I wanted to improve:

The onboarding process
The settings page
The experience on iPad

I was able to get all of these done along with some general tidying up around the app to make it look a little better such as changing the old salmon colour for a brighter pink that is present in the app icon.

Onboarding

For those of you that aren’t familiar, “onboarding” is the process in which you get a user set up on the first launch of an app. This can take the form of tutorials, registration, and so on but for Music Library Tracker the only reason was to gain access to your music library. Here’s how the old process looked:

Yup, that salmon background has really stood the test of time 🤢

There are a lot of problems here. The design is obviously horrible, there’s no softening you up for the media library access prompt (which happens when you press “Get Started”), and the scanning process didn’t really need to be here. The only good part was the notifications prompt which correctly details why the permission is needed and presents a “you really should allow this” alert if you chose not to enable it.

With v2.0, I wanted to make the process much smoother as there are a few extra things I wanted to ask permission for:

Media Library access: this is a hard requirement as the app can’t do anything at all if it doesn’t have permission to access your library1.
Spatial Audio scanning: I made this an opt-in feature as it requires sending data to my server.
Spatial Audio playlist: if they opted-in to the Spatial Audio feature then do they want the automatic Apple Music playlist?
Notifications: there are two types of notification now (although the Spatial Audio one isn’t shown as an option if Spatial Audio wasn’t turned on) but I also always want to prompt for notification access so I can send silent push notifications in order to do background scanning of the library.

Initially I was going to do something similar to the previous design; a straightforward left-to-right navigation with each button prompt taking you to the next page. I’d likely stick this in a single view with a paging indicator to show how far through the process you were but then that would cause problems as you can skip step 3.

Instead, I decided I wanted to try an interface where text would rise and fade from the bottom of the screen with the various options. It would work somewhat like an automated chat as the response could be dictated by the choices you make so the user doesn’t need to see they’ve missed something. I’m very pleased with the result:

The process is far smoother and the design looks much, much better. Each section has text that clearly outlines why the permission is needed and then gives the user the option to accept or not. Once the decision is made, the button turns grey (with an optional ✅ if accepted), the text above fades out, and the next section fades up into view.

It’s not shown in the video, but if a user turns down the media library access then a prompt is shown that takes them to the Settings app to turn this on; they can’t proceed into the app unless that is enabled. Similarly, if the user turns off the toggle for both types of notifications, an extra prompt is shown pointing out that permissions will still be asked for in order to serve silent notifications.

One element I particularly like about this flow is that I’m able to drop a user in part way. For example, somebody upgrading from the previous version of the app does not need to enable library access as it is likely already enabled. In that instance, the first thing they are shown is the second section regarding Spatial Audio. This will also work well in the future should I add any additional prompts.

The entire onboarding prompt was built in SwiftUI as I wanted to make a quick prototype to test whether or not such an interface would actually work the way I envisioned. As I’ve said a few times before, SwiftUI is perfect for fast experimentation. In particular, the animation of the splash screen icon from the centre of the screen to the title bar is something that would have been very time consuming in UIKit but was an absolute doddle with matchedGeometryEffect().

Settings

I didn’t have any particular issues with the previous settings page in terms of the design, but I wasn’t happy with the layout of the new Spatial Audio section:

The issue is that the “Monitor changes to Spatial Audio” toggle will hide the playlist section entirely if turned off as that setting would no longer be relevant. However they don’t look linked together as there is a gap between the two sections (necessary as the playlist piece is distinct with it’s own footer text).

This was further compounded by the addition of a new feature, the ability to get a notification when tracks are upgraded to Spatial Audio. This section would similarly need to be hidden if the whole Spatial Audio piece was disabled and I’d also need to rework how to display the current notification permission status.

From a coding point of view, the settings page used a static table in a UITableViewController which is why hiding sections became quite difficult. I can’t just hide a section in the middle of the screen so have to instead give the cells a 0.1pt height and hide the content which is a very hacky solution. This also means that animations didn’t work so changes are fairly jarring. I did not want to make this worse with the extra toggles that could show and hide content so my options were either a) rebuild it with dynamic cells or b) rewrite it in SwiftUI. I chose the latter!

The new version looks similar but a lot cleaner:

Each section is now distinct with both a title and footer. They also all make use of SF Symbols to make the settings page look a little bit more modern. Thanks to SwiftUI, the state of the page is driven by the variables so it’s trivial to show or hide a section with a simple boolean wrapped in an animation block.

The previous version would show the status of the system notification permissions with a simple “Enabled” or “Disabled” label at the top of the page. If permissions had been denied, tapping on this label would show an alert that could take you to the Settings app. I didn’t want to take up extra real estate to show you notifications were enabled but I did still want to show something if the system permissions weren’t granted:

If a notification type is enabled but system permissions have been denied, I tint the field red and add an exclamation icon. When tapped, you get the same prompt that can take you to the Settings app to grant permission2. This works a lot better and, again, was a breeze to put together with SwiftUI along with seamless animating of colour and icon with barely any code.

Updating the settings page isn’t a big flashy feature but it should make the app far more usable for those who need it whilst also making it far more maintainable for me in future. It also just looks a lot more professional than what came before.

iPad Improvements

The final area I wanted to improve was the experience on iPad. Whilst the app has always been a Universal binary rather than a blown up iPhone app, it has still always looked a bit silly on the larger iPads as there just isn’t that much content to show.

I’ve improved this by ensuring that all views conform to the readable content guide which essentially adds some white space to the sides depending on how large the device is.

It can still feel a little blown up but I think it’ll do as a stopgap solution for now. There has been support for split views in the app since day one and I suspect that is how most people on iPad will use it.

I’ve also added some keyboard shortcuts to the iPad version and support for trackpads with the interaction pointer:

Buttons in the app will now capture the interaction pointer; on the activity page, a highlight is added as you move around the interface.

With these three improvements I think the app is looking in much better shape whilst also being a lot more maintainable from a code standpoint thanks to a gradual transition to using SwiftUI.

Unless there are any major issues I’m planning on taking a break from this project for a while as I feel a little burnt out after working on it for so many months. That said, I am very happy to see the Spatial Audio feature out in the wild and hope that you’ll find it to be a useful feature.

Download Music Library Tracker v2.0.1

Dolby Audio

Last issue I mentioned that I was only marking Dolby Atmos tracks as Spatial Audio yet Dolby Audio tracks should also qualify for that moniker as they support Fixed Spatial Audio:

So, at the moment Music Library Tracker and the Spatial Audio Finder only treat Dolby Atmos tracks as being Spatial Audio. I do have a record of which tracks are in Dolby Audio so it should be relatively easy to add that as a feature but it will likely be for a later version!

I have now made a change to the server code so Dolby Audio tracks will now show up as “Spatial Audio” within Music Library Tracker, the Spatial Audio Finder, and @NewSpatialAudio on Twitter.

It will likely be a few days until the existing tracks in the database are updated as new tracks take priority for my scanning engine; as of right now, there are just under 2 million tracks that have been added thanks to the new app update 😅

Station Artwork

I received a request on Mastodon last week regarding Radio Show artwork on Apple Music:

This type of artwork was supported in my Apple Music Artwork Finder but it would return an image in a 4:1 aspect ratio with a solid colour background:

Sidenote: Before I carry on with this there is something that really bugs me about Apple Music radio shows. The show itself (i.e. “Elton John’s Rocket Hour”) is actually known as an “Apple Curator” internally whereas an episode of a show is known as a “Station”.

For some reason the Apple Music API is returning these images in this 4:1 banner format even though I don’t believe they are used this way anywhere within the app (whereas the show itself does have a banner image which is shown on it’s page). I’ve fixed this within the artwork finder so it will now return a high resolution square image (usually 4320x4320px) but also return the 4:1 banner version just in case it does show something different.

Darkest Dungeon Prototype

I’ve been playing a lot of the Darkest Dungeon boardgame recently but have been running into issues with table space. As is very common with these huge co-operative games, it can scale from 1-4 players by changing how many characters you control. There are always 4 characters so if you’re playing solo you need to make space for each of their boards whereas if you had a full complement of players you’d have a single character each in front of you.

Here’s an example from the rulebook showing how a standard setup should look:

That’s a lot of pieces for a solo player 🤣

As you can see, there is rather a lot to manage there! I won’t go into the mechanics of the game in detail as it’s not relevant but suffice to say most of the action takes place in the top part of this image with combat between characters and enemies as well as navigation through a dungeon. There’s also an area called the Hamlet which you visit and upgrade between quests that is not shown here so you actually need even more space.

To make it easier for me to play on my own I’m proposing to digitise the entirety of the bottom half of that image. I’m imagining a companion app where you would put which characters you are using and choose their relevant skills. I could then add status effects and tokens to the app and have it track their health and all those other cards such as diseases, curios, virtues, etc. That would significantly reduce the amount of stuff that needs to be on the table and make it a much better experience for solo play.

Whilst I often start prototyping an idea directly in code, sometimes I like to draw a basic mockup on my iPad using an Apple Pencil. These mockups are crude at best:

I’ll be impressed if you can read my writing

You’re likely not going to be able to make heads nor tails of what that means so why am I sharing it? The point is that I know what it means and it’s all I need to have before diving into the actual coding. Too many people get hung up with having the perfect prototyping systems; I’ve seen many people build pixel perfect wireframes that take days to put together and offer no additional benefit beyond a quick sketch. A prototype should be something to quickly iron out “will this work”, it should not be a cast in stone blueprint for an app.

I don’t have anything else to say about this app for the time being but it’s going to be a fun diversion for me over the next couple of weeks, a palate cleanser before I dive back into some proper apps for release later in the year.

Roadmap

The roadmap is my way of committing to what I’m going to do before the next issue:

2nd February - 15th February

Release Music Library Tracker v2.0 ✅
Start prototyping an app for the Darkest Dungeon board game ✅

After pushing the launch back by 2 weeks I’m glad I was able to get it released this time around! Definitely looking forward to working on something else for a little while 🤣

16th February - 15th March (Issue #7)

Complete the Darkest Dungeon app
I started working on an app a few months ago called Board Game Lists that will let you create lists of the games you own and export a PDF with some notes attached. The use case for this is that I was arranging a board game night with some neighbours and wanted a way to show what games I had that would be suitable (i.e. the right number of players, difficulty, etc). I’d like to get back into that as I’d got an integration with BoardGameGeek working so just needed to build out some of the other functionality.

That wraps it up for this issue. I hope you found something of interest and that you’ll be able to recommend the newsletter to your friends, family, and colleagues. You can always comment on this issue or by emailing me directly via ben@bendodson.com

The Dodo Developer

Discussion about this post