Creating an Apple Music plugin using `MusicKit`

[lgarron]

iTunes is long defunct, and so is its API: #2495

The official way to interact with the music library on macOS is MusicKit: https://developer.apple.com/documentation/applemusicapi/

I have the absolute barest version of a plugin at https://github.com/lgarron/AppleMusic-qsplugin

It:

• Indexes all songs in the library and places them in the catalog.
• Has a "Play" action that can be used to play a song.

This works!

However, it does nothing else useful and still contains boilerplate. In addition:

• This requires adding NSAppleMusicUsageDescription to Info.plist in Quicksilver itself:

  Quicksilver/Quicksilver/PropertyLists/Quicksilver-Info.plist

  Lines 183 to 192 in 5779b38

  	<key>NSAppleEventsUsageDescription</key>
  	<string>Quicksilver requires this access to run certain actions and update your catalog.</string>
  	<key>NSAppleScriptEnabled</key>
  	<true/>
  	<key>NSCalendarsUsageDescription</key>
  	<string>Create events directly from Quicksilver (only used when the &apos;Calendar&apos; plugin is enabled)</string>
  	<key>NSContactsUsageDescription</key>
  	<string>View, copy and paste information from your contacts in Quicksilver (only used when the &apos;Contacts&apos; plugin is enabled)</string>
  	<key>NSRemindersUsageDescription</key>
  	<string>Create reminders directly from Quicksilver (only used when the &apos;Calendar&apos; plugin is enabled)</string>

  . This is probably simple.
• Building with the MusicKit API requires targeting macOS 14 or above. I do not know if it's possible to build the plugin like this without also increasing the target for Quicksilver itself.
• The MusicKit API is asynchronous, and interfaces inside Quicksilver are not. I was able to hack around this using a very unadvisable workaround to make synchronous code block on a Task: https://forums.swift.org/t/using-async-functions-from-synchronous-functions-and-breaking-all-the-rules/59782/4
  • Given that it takes several seconds to index a music library, it is probably a good idea to have an async API for indexing. But I think that's a much larger architectural change. I don't know the best compromise.
• The song (queue) stops playing when Quicksilver exits. It seems this may be a limitation of the MusicKit API. Given Quicksilver's propensity for crashing I'd really like a workaround, but it seems the only other one is effectively to use AppleScript.

Anyhow, I don't know how much time I can dedicate to this but hopefully my repo shows that it's at least possible to rebuild the functionality of the old iTunes plugin from scratch.

[lgarron]

Ooh, it seems I'm actually able to use my built plugin¹ with the stable version of Quicksilver. This shows that it's at least possible to build without requiring a higher target for Quicksilver itself.

Footnotes

1. The debug version, at least. I haven't tried to build a release version. ↩

[pjrobertson]

Great work lgarron!

To answer a few questions:

• It should be possible to make this plugin only target macOS 14+ (you can edit that in the plugin's settings – see here, that should do away with the need to recompile Quicksilver/do a new release. I don't think that NSAppleMusicUsageDescription is strictly necessary, is it? If so, you can make a PR to add that to Quicksilver, shouldn't be a problem :)
• Indexing is synchronous, but is done on a background thread so it shouldn't affect the user. I don't think there's really anything wrong with what you're doing (even if that page says it's 'hacky' and bad.
• I'm sure this is still WIP, but it might make more sense to add artists and albums to the catalog as opposed to songs (or both) - I can't remember what the old plugin did but that can be used as a reference
  Let us know if you have any further questions.

[lgarron]

Thanks!

• It should be possible to make this plugin only target macOS 14+ (you can edit that in the plugin's settings – see here, that should do away with the need to recompile Quicksilver/do a new release. I don't think that NSAppleMusicUsageDescription is strictly necessary, is it? If so, you can make a PR to add that to Quicksilver, shouldn't be a problem :)

I certainly had issues compiling/using the plugin without Xcode for these changes. But given that the plugin is working with stable Quicksilver hopefully we can avoid that!

• Indexing is synchronous, but is done on a background thread so it shouldn't affect the user. I don't think there's really anything wrong with what you're doing (even if that page says it's 'hacky' and bad.

Sounds good!

• I'm sure this is still WIP, but it might make more sense to add artists and albums to the catalog as opposed to songs (or both) - I can't remember what the old plugin did but that can be used as a reference
  Let us know if you have any further questions.

Yeah, there are quite a few features from the old plugin I wouldn't be satisfied without! Hopefully porting each of them will be incrementally simpler than it took to get started.

[lgarron]

• The song (queue) stops playing when Quicksilver exits. It seems this may be a limitation of the MusicKit API. Given Quicksilver's propensity for crashing I'd really like a workaround, but it seems the only other one is effectively to use AppleScript.

Okay, it seems that this is because the playback is completely disconnected from the Music app, because I had to use ApplicationMusicPlayer.

The reason I had to use this is because SystemMusicPlayer is not possible to use on macOS. Thanks, Tim Apple. 🙁

Speaking for myself, a large point of the iTunes plugin was that it made my life significantly easier as a DJ specifically because it controlled the iTunes app. Given that the macOS Music app has become ludicrously buggy for everyday tasks, this is even more valuable than it was back then.

I can imagine that some people are okay with separate playback from the built-in app and might even find it useful at times. But I would have zero motivation to work on this plugin if that was the only way to use it.

It seems that the AppleScript dictionary is still somewhat powerful, e.g. able to reveal individual tracks in a playlist¹, so I'll probably be looking at that for the actual playback and app interaction actions.

Footnotes

1. Although this is been implemented in a garbage way that changes the playlist to "View as Playlist" every single time even if you're viewing "as Songs". ↩

[pjrobertson]

Great progress. Feel free to continue to ask for any pointers/help as you work through this. Working with buggy apps can be really annoying!

It seems that the AppleScript dictionary is still somewhat powerful, e.g. able to reveal individual tracks in a playlist

I agree that applescript (or JSX) is more maintainable and tend to work pretty well. There is a well-followed path for working with scriptingbridge if you want to do it directly in the Swift code (see here ) or you could of course just run AppleScripts directly.