Is MusicKit JS supported or permitted in headless Chromium on embedded Linux?

Media Technologies General
Erickli OP
Created
Replies 2
Boosts 0
Views 470
Participants 3

Hi,
We are building a network audio device running embedded Linux (headless — no display, no user-facing browser UI). I'd like to clarify whether MusicKit JS can be used in this environment, both technically and from a licensing standpoint.

Our setup
Embedded Linux on ARM, no screen
Headless Chromium running as a background service
MusicKit JS loaded in a page to authenticate the user and play Apple Music

Questions

  1. Is MusicKit JS supported in a headless browser context, or is it intended only for interactive, user-facing browser sessions?
  2. MusicKit JS requires a Developer Token with an origin claim, and a valid web origin. If the page is served locally on the device (e.g. http://127.0.0.1) with no public domain, what origin should be used? Is a local origin acceptable?
  3. Is embedding MusicKit JS inside device firmware — where the browser is never visible to the user and playback is not initiated through a normal browsing session — within the MusicKit terms of use?
  4. I want to confirm whether running MusicKit JS in headless Chromium would be considered an acceptable implementation。

For context: we are already MFi licensees with AirPlay 2 integrated. We simply want to be certain any additional work stays within the authorized scope.
Any guidance — including a pointer to the relevant section of the MusicKit terms — would be much appreciated.
Thanks in advance

Answered by DTS Engineer in 912478022

Thanks for laying out your setup and questions so clearly.

The origin claim is optional. Generating Developer Tokens lists it as "Optional, but recommended for web clients," and says the token is used only if the request's origin header matches one of the values you list. The documentation doesn't say whether a local or IP-address origin is acceptable when you do include one.

The MusicKit on the Web documentation doesn't describe supported browsers or environments, headless or otherwise. One documented detail matters for your design. Full-length playback and library access require user authorization, and the MusicKit JS User Authorization article says the authorize method "will open the sign-in and authorization flow."

The MusicKit terms are in section 3.3.6(D), "MusicKit," of the Apple Developer Program License Agreement. Among other requirements, it says that "users must initiate playback and be able to navigate playback using standard media controls such as 'play,' 'pause,' and 'skip.'" It also says you "may use MusicKit JS only as a stand-alone library in Your Application, website, or web application." I can't tell you whether a particular design meets those terms.

If you'd like the documentation to describe the environments MusicKit on the Web supports, please file an enhancement request using Feedback Assistant and describe your device. Please note that filing an enhancement request does not guarantee Apple will add any requested functionality to Apple products in the future. However, with that said, filing an enhancement request is a good way to get your ideas in front of the folks who make decisions about that sort of thing. Bug Reporting: How and Why? has tips on filing one.

Replies  2
Boosts 0
Views  470
Participants  3
Pokpong OP

I would be cautious about using MusicKit JS this way. Apple's public MusicKit pages describe playback on the web in terms of users streaming from a website, but I couldn't find a statement that headless Chromium on embedded Linux is a supported environment. The docs also don't answer whether a loopback origin is acceptable for the developer token's origin claim.

Since this is going into a product, I'd get confirmation from Apple Developer Support about the headless use case and the MusicKit terms before building around it. Include the exact origin, how the user authorizes the device, and how playback is presented or controlled. Also check whether the target Chromium build supports the playback and DRM requirements; MFi and AirPlay 2 approval alone may not cover this separate MusicKit JS use.

DTS Engineer OP
Apple
Recommended

Thanks for laying out your setup and questions so clearly.

The origin claim is optional. Generating Developer Tokens lists it as "Optional, but recommended for web clients," and says the token is used only if the request's origin header matches one of the values you list. The documentation doesn't say whether a local or IP-address origin is acceptable when you do include one.

The MusicKit on the Web documentation doesn't describe supported browsers or environments, headless or otherwise. One documented detail matters for your design. Full-length playback and library access require user authorization, and the MusicKit JS User Authorization article says the authorize method "will open the sign-in and authorization flow."

The MusicKit terms are in section 3.3.6(D), "MusicKit," of the Apple Developer Program License Agreement. Among other requirements, it says that "users must initiate playback and be able to navigate playback using standard media controls such as 'play,' 'pause,' and 'skip.'" It also says you "may use MusicKit JS only as a stand-alone library in Your Application, website, or web application." I can't tell you whether a particular design meets those terms.

If you'd like the documentation to describe the environments MusicKit on the Web supports, please file an enhancement request using Feedback Assistant and describe your device. Please note that filing an enhancement request does not guarantee Apple will add any requested functionality to Apple products in the future. However, with that said, filing an enhancement request is a good way to get your ideas in front of the folks who make decisions about that sort of thing. Bug Reporting: How and Why? has tips on filing one.