Saltar al contenido
Development

La lista de reproducción que ya tenía el nombre correcto

Por Victor Da Luz
iosswiftmusickitdev-logdeep-cut-atlas

Deep Cut Atlas antes se llamaba Discoverer. Después del cambio de nombre, quedó un artefacto visible: la propia lista “To Check Out” de la app en Apple Music seguía mostrando a “Discoverer” como su creador.

Antes de tocar código, revisé qué hace realmente la app al crear una lista de reproducción. El servicio llama directamente a MusicLibrary.shared.createPlaylist(name:), sin parámetro de autor, sin descripción. Un grep en todo el repo buscando authorDisplayName o curator no encontró nada. MusicKit no expone ninguna forma de asignar la etiqueta de “creador” de una lista, por eso la app lleva sus propias listas en un conjunto local en vez de depender de algún campo de la API.

Eso descartó de inmediato una posible solución: no hay parámetro de autor para actualizar. La pregunta que quedaba era si la etiqueta “Discoverer” venía de otro lado, y la respuesta más probable era la más simple: la lista es anterior al cambio de marca, y Apple Music simplemente congeló el string de creador en el momento de la creación.

MusicKit no corre en el simulador de iOS, así que probarlo significaba usar un dispositivo real. Compilé la rama actual, la instalé en mi iPhone, y usé un flag de debug temporal para llamar al propio código de creación de listas de la app y generar una lista nueva. Apareció en Apple Music como “Deep Cut Atlas.” El cambio de marca por sí solo ya había arreglado esto para cualquier cosa creada de ahí en adelante, no había ningún error que corregir.

Las dos listas reales creadas antes del cambio de marca todavía muestran “Discoverer,” y no hay API para editar eso después del hecho. Recrearlas implicaría mover manualmente canciones reales de la biblioteca a listas nuevas solo para arreglar una etiqueta que únicamente yo voy a ver. No valía la pena, se cerró como aceptar tal cual.

La lección útil acá no tenía tanto que ver con MusicKit. Tiene que ver con que “investigar primero, programar después” resultó ser lo correcto: el issue, tal como se registró, proponía una posible solución de código, y si la hubiera implementado sin revisar antes, habría publicado un cambio en un camino de la API que nunca estuvo roto.

Lecturas relacionadas