Le lecteur audio que j’ai créé moi-même

• Parti du constat qu’en 2025, il reste difficile sur iPhone d’écouter librement et de synchroniser les fichiers musicaux que l’on possède, l’auteur a implémenté lui-même un lecteur musical local-first en SwiftUI
• Si l’on résilie son abonnement Apple Music, la synchronisation via iCloud Music Library s’arrête, et iTunes Match constitue une option payante distincte à 24,99 $/an pour stocker en ligne des copies AAC 256 kbps
• React Native/Expo échouait souvent ou provoquait des crashs lors de l’exploration de dossiers iCloud profondément imbriqués et de la gestion des autorisations de fichiers, ce qui a fait d’une implémentation SwiftUI utilisant les API natives d’Apple un choix plus simple
• L’application utilise SQLite FTS5 pour rechercher les noms de fichiers et les métadonnées comme artist, album et title, et sépare l’import iCloud, la gestion de bibliothèque et l’écran de lecture
• Sur iOS, les signets à portée de sécurité et les limites des builds de développement personnels signifient qu’il subsiste des barrières d’accès aux fichiers et de distribution, même pour utiliser durablement une application développée pour soi-même

---

Pourquoi créer soi-même un lecteur musical

• Sur iPhone, lire les fichiers musicaux que l’on possède implique encore de payer Apple ou de contourner diverses limitations
• Pour les utilisateurs qui ont déjà organisé leur bibliothèque musicale locale, les services de streaming relèvent davantage du confort que d’une nécessité
• Si l’on met fin à son abonnement Apple Music, la synchronisation entre appareils fondée sur iCloud Music Library s’interrompt
  • Cette fonctionnalité est liée à l’abonnement
  • On peut la récupérer avec iTunes Match pour 24,99 $ par an
  • Match stocke en ligne des copies AAC 256 kbps, tandis que les fichiers d’origine restent inchangés tant que l’utilisateur ne les modifie pas
  • Sans abonnement, la synchronisation cloud disparaît et il faut revenir à une synchro par câble/Wi‑Fi
• L’objectif était de créer soi-même un lecteur musical de base permettant d’importer, d’organiser et de lire des fichiers audio
• L’application terminée propose une recherche en texte intégral, la prise en charge d’iCloud et une expérience local-first, et elle est publiée sur GitHub

Pourquoi les options existantes ne convenaient pas

• Les apps Apple par défaut

  • L’app Fichiers permet bien de lire directement des fichiers musicaux depuis iCloud, mais elle n’a pas été conçue pour l’écoute musicale
  • Il lui manque des fonctions essentielles comme la gestion de playlists, le tri par métadonnées ou une file de lecture
  • Même si la lecture de musique est possible, l’expérience utilisateur globale reste limitée, comme le montrent aussi les discussions dans la communauté Apple

• Les apps tierces

  • L’App Store regorge d’applications de lecture musicale hors ligne, mais beaucoup appliquent une tarification par abonnement, même pour lire des fichiers déjà possédés par l’utilisateur
  • Doppler avait l’avantage d’un paiement unique
  • Mais son UX était centrée sur la gestion des albums, la qualité de recherche n’était pas satisfaisante, et l’import iCloud avec de nombreux dossiers imbriqués était lent et difficile à utiliser

Le passage de React Native à SwiftUI

• Le choix initial : React Native/Expo

  • Pour éviter Swift à cause d’une ancienne expérience, et pour réutiliser une expérience de développement web, le premier choix s’est porté sur React Native/Expo
  • L’implémentation de l’interface de lecture a été facile, et le template music-player de Gionatha Sturba, qui semblait fournir les fonctions nécessaires, a été utilisé
  • Les problèmes se sont accentués avec l’accès au système de fichiers et la synchronisation des fichiers cloud
  • Des bibliothèques comme expo-filesystem prenaient en charge la sélection de fichiers de base, mais l’exploration récursive de répertoires iCloud profondément imbriqués échouait souvent ou faisait planter l’application
  • Le sandboxing iOS empêche une app de lire des fichiers sans autorisation explicite de l’utilisateur
  • Au final, l’approche fondée sur JavaScript s’est révélée plus complexe que l’usage direct des API natives d’Apple, et passer à Swift permettait de mieux contrôler l’accès aux fichiers iCloud et les autorisations du sandbox

• Pourquoi SwiftUI

  • Au lieu d’UIKit ou des storyboards, le choix s’est porté sur SwiftUI afin de construire une couche d’interface déclarative et de se concentrer sur la logique métier et la synchronisation des données
  • L’intégration de async/await et des Swift Actors a facilité les flux de données et la gestion de la concurrence
  • SwiftUI aide à structurer l’application en composants ViewModel indépendants
  • Des LLM comme OpenAI o1 et DeepSeek créaient moins d’interdépendances complexes lors de la génération de code d’interface pur ou de data binding

Architecture de l’application et modèle de données

• Trois écrans principaux

  • L’application se divise en trois flux : Library import, Library management et Player and playback
  • Library import ajoute un dossier de bibliothèque iCloud, scanne les fichiers audio dans tous les dossiers et insère leurs chemins dans une base SQLite
  • Library management sert à gérer les morceaux ajoutés et à composer des playlists
  • Player and playback gère la répétition, le shuffle, la gestion de la file d’attente, ainsi que la lecture, la pause et le passage au morceau suivant
  • Le sélecteur de fichiers par défaut d’Apple ne correspond pas à un flux où l’on souhaite sélectionner en une fois plusieurs répertoires et plusieurs fichiers recherchés par mot-clé
  • Si l’application démarre avec une bibliothèque vide, l’onglet Sync affiche un bouton « Add iCloud Source »
  • Lorsqu’un dossier est sélectionné, une barre de progression s’affiche pendant l’exploration de l’arborescence, puis l’app bascule vers l’onglet Library une fois l’indexation terminée
  • Le premier écran affiche Playlists / Artists / Albums / Songs
  • En touchant une piste, un mini-lecteur apparaît en bas ; en le touchant, on passe au Player plein écran
  • Le Player plein écran propose shuffle, répétition, réorganisation de la file d’attente et volume
  • En appuyant sur « + » dans Sync pour sélectionner un autre dossier, les nouveaux morceaux sont fusionnés en arrière-plan sans redémarrage nécessaire

• Une couche logique inspirée du serveur

  • Bien qu’il s’agisse d’une application mobile, une architecture de type backend a été adoptée à partir d’une expérience en backend web et cloud
  • La couche domaine/logique est séparée des couches View et ViewModel afin de traiter de manière fiable la synchronisation cloud, le parsing des métadonnées et l’accès aux données SQLite
  • La structure en couches est la suivante
    • SQLite stocke les lignes sources des morceaux et l’index FTS
    • Les Repository encapsulent la base et exposent des API asynchrones
    • Les Actor du domaine portent les règles métier comme l’import, la recherche et la logique de file d’attente
    • Les ViewModel s’abonnent aux Actor et convertissent les données en structures pour l’UI
    • Les View SwiftUI affichent les données reçues
  • Les changements d’état restent thread-safe, et la synchronisation iCloud, la lecture et l’UI sont séparées pour éviter de traverser directement les couches

Recherche locale avec SQLite FTS5

• Le stockage persistant repose sur SQLite, sans utiliser CoreData
• CoreData a été évité parce qu’il fallait contrôler directement le schéma, les requêtes brutes et surtout la recherche en texte intégral
• Depuis iOS 11 environ, SQLite avec les fonctionnalités FTS est disponible sans configuration supplémentaire
• SQLite.swift a été utilisé pour les requêtes générales, mais les requêtes FTS sont traitées avec du SQL classique
• SQLite FTS5 permet d’interroger les noms de fichiers et les métadonnées comme artist, album et title sans infrastructure de recherche séparée

• Structure des tables FTS

  • Deux tables FTS5 sont utilisées
  • songs_fts : utilisée par SQLiteSongRepository, elle indexe artist, title, album, albumArtist
  • source_paths_fts : utilisée par SQLiteSourcePathSearchRepository, elle indexe fullPath, fileName
  • Les deux tables FTS se trouvent à côté des tables B-tree classiques songs et source_paths
  • Le FTS est en lecture seule côté UI ; toutes les écritures sont gérées dans les Repository
  • Dans l’exemple de création de songs_fts, songId est défini comme UNINDEXED et le tokenizer unicode61 est utilisé
  • unicode61 a été choisi pour mieux gérer divers caractères
  • Les clés non recherchées sont marquées UNINDEXED afin d’éviter une croissance inutile du dictionnaire de termes

• Recherche partielle et classement

  • Quand l’utilisateur saisit « lumine », un wildcard est ajouté en interne, comme « lumine* », afin de trouver immédiatement des résultats de recherche partielle
  • Le tri des résultats s’appuie sur bm25 de SQLite
  • Cette approche offre un schéma prévisible, une stratégie local-first et une recherche plein texte puissante, sans dépendance réseau ni service externe supplémentaire

Accès aux fichiers sur iOS et limites des signets

• Les applications iOS peuvent enregistrer des signets persistants pour mémoriser l’emplacement des fichiers
• Mais les security-scoped bookmarks, qui accordent un accès étendu à des fichiers hors du sandbox de l’app, ne sont disponibles que sur macOS
• Une app iOS peut mémoriser les chemins avec des signets ordinaires et redemander l’accès via le sélecteur de documents, mais rien ne garantit que cet accès sera maintenu silencieusement dans le temps
• Apple en parle dans sa documentation sur les bookmarks
• Pour atténuer ce problème, un mécanisme alternatif a été implémenté : copier les fichiers dans le conteneur sandbox de l’application
  • Les fichiers sont copiés de manière préventive en arrière-plan tant que les signets restent valides
  • Cela réduit le risque d’accéder à des références de fichiers audio devenues invalides si iOS réinitialise les autorisations
• Cette approche améliore aussi la vitesse d’indexation
  • L’arborescence des dossiers est scannée une seule fois pendant que l’accès est actif
  • Seuls les fichiers audio pertinents sont importés
  • Les répertoires profondément imbriqués sont parcourus en toute sécurité
• Le problème de la lecture fiable de fichiers audio individuels situés dans des emplacements externes après redémarrage de l’appareil n’a pas été résolu
• Même avec une app native, ce cas d’usage reste insuffisamment pris en charge sur iOS, et gérer l’accès aux fichiers de façon fiable demeure complexe

Lecture audio et implémentation de l’UI

• Parsing des métadonnées

  • Le parsing des métadonnées des fichiers audio utilise AVURLAsset du framework Apple AVFoundation
  • AVURLAsset permet d’inspecter des métadonnées de fichiers média comme title ou album artist
  • Certains champs, comme le numéro de piste, ont dû être récupérés directement depuis les tags ID3
  • Comme la documentation officielle ne couvre pas suffisamment les cas limites, des exemples d’implémentation ont été recherchés sur GitHub

• Lecture audio

  • Une fois la bibliothèque indexée, le lecteur audio a été implémenté en initialisant une instance AVAudioPlayer pour lancer la lecture
  • Pour contrôler la musique depuis le Control Center, il a fallu implémenter le protocole AVAudioPlayerDelegate et connecter l’application à MPRemoteCommandCenter d’Apple
  • MPRemoteCommandCenter permet à l’application de répondre aux contrôles de lecture au niveau système

Expérience avec Swift et le développement Apple

• Ce qui a été difficile

  • Les prévisualisations SwiftUI en temps réel dans Xcode représentent un progrès, mais l’expérience globale de développement n’atteignait pas le niveau d’intégration VSCode, de rechargement instantané du simulateur et d’outils de débogage familiers que Flutter offrait déjà il y a 5 ans
  • Le support LSP de Swift pour Neovim ou VSCode exige des outils additionnels comme xcode-build-server et ne retrouve pas l’expérience des écosystèmes centrés sur le web
  • Une partie des SDK Apple reste encore marquée par un style Objective-C
  • La recherche de fichiers façon Spotlight n’est exposée qu’à travers NSMetadataQuery, et NSMetadataQuery utilise KVO ainsi que des clés sous forme de chaînes
  • Il n’existe pas encore de wrapper véritablement idiomatique pour Swift
  • L’UI déclarative de SwiftUI est utile, mais le comportement complet d’une application impliquant des autorisations iCloud ne peut pas être émulé dans les previews ; il faut donc mocker directement les interactions cloud

• Ce qui a été positif

  • Grâce à async/await, du code concurrent centré sur les E/S a pu être écrit comme du code impératif, sans callbacks
  • Il a été facile d’intégrer du code synchrone dans des Actor et de l’appeler comme dans l’écosystème JavaScript
  • Il a été possible d’utiliser directement les bibliothèques natives d’Apple, sans être limité par les bindings open source de React Native ou Flutter
  • De nombreuses API Apple disposent d’exemples, ce qui facilite la prise en main
  • La façon dont SwiftUI compose l’UI à la manière de React offre productivité et liberté d’exploration

Sur iOS, il est difficile d’utiliser longtemps une app personnelle

• Après environ une semaine et demie de travail, un lecteur musical local/hors ligne capable d’importer des fichiers audio depuis un stockage iCloud a été créé
• Mais sans certificat développeur, l’application ne peut s’exécuter que 7 jours, après quoi il faut la recompiler
• L’inscription à l’Apple Developer Program coûte 99 $
• Même après le DMA Act dans l’UE, le sideloading n’est pas totalement ouvert
  • Les utilisateurs européens peuvent installer des applications de marketplaces tierces via le site développeur
  • Les développeurs doivent toujours adhérer au programme Apple à 99 $/an
  • Ils doivent aussi accepter les Alternative Terms d’Apple
  • Pour un usage personnel ou de loisir, la limite de 7 jours des builds de développement ne disparaît pas
• Les PWA sur iOS restent également limitées
  • Même après les mises à jour iOS 16 à 18.x, les PWA s’exécutent toujours dans le sandbox de Safari
  • WebGL2 et web-push sont disponibles
  • En revanche, Web Bluetooth, USB, NFC, Background Sync et un stockage garanti au-delà d’environ 50 Mo ne sont pas fournis
  • WebGL passe par une couche d’adaptation Metal, ce qui fait souvent que le framerate réel reste inférieur à celui d’une application native Metal
• L’IA a facilité l’accès aux connaissances nécessaires pour travailler avec des technologies moins familières et réduit la complexité du développement logiciel, mais les applications iOS doivent toujours se conformer à des règles artificielles
• Même pour une application créée pour soi-même, il subsiste l’ultime barrière d’Apple si l’on veut l’exécuter plus d’une semaine, ce qui restreint le développement et la distribution d’applications personnelles

[GN⁺]

Avis de Hacker News

• J’ai connu l’époque où Winamp était le lecteur de musique par défaut, et même à l’ère du streaming, je garde toujours une bibliothèque musicale locale organisée en dossiers
  Comme d’autres personnes dans les commentaires ici, j’ai créé comme projet perso un lecteur de musique à l’ancienne pour écouter de la musique hors ligne ; c’est une appli HTML/JS d’une seule page, avec toute la navigation au clavier et une fonction simple de file d’attente
  Vous pouvez l’essayer ici : https://nobsutils.com/mp

  • Environ 27 ans plus tard, je pense toujours que l’UI de Winamp était proche de la bonne réponse
    J’aimais cette simplicité : un ensemble de fichiers dans un répertoire, lecture aléatoire de toute la collection, ou lecture d’un répertoire précis
  • J’aime bien, je cherchais justement ce genre de lecteur de musique simple
    À noter que le raccourci de favori standard actuel, cmd + d, change le thème au lieu d’ajouter le site aux favoris
  • Pour moi, le lecteur de musique par défaut a toujours été foobar2000, et aujourd’hui je l’ai remplacé par l’app Cog

• J’ai constitué ma collection musicale en format FLAC pendant 25 ans, et l’an dernier j’ai acheté un téléphone Android avec une carte MicroSD de 1 To, ce qui m’a permis d’y mettre toute ma musique
  Ça a été un long projet, le temps que la technologie rattrape mon besoin, mais maintenant que je peux tout avoir dans ma poche, j’en suis plutôt content
  Je ne dois pas être le seul à ne pas vouloir devenir un locataire qui abandonne le contrôle, streame ce que l’industrie pousse et supporte la publicité ; et c’est chouette de voir des gens aller jusqu’à créer leur propre appli

  • La technologie avait déjà rattrapé ce besoin depuis longtemps ; c’est plutôt le fait d’insister sur un format pas adapté à l’usage
    Avec un bon réencodage, on peut mettre toute sa musique sur une carte bien plus petite avec une qualité transparente, impossible à distinguer à l’écoute, tout en gardant les FLAC sur un ordinateur de bureau comme sauvegarde
  • Ta sélection de collection est vraiment bien maîtrisée
    Ma collection dépasse les 3 To alors que les FLAC/APE/ALAC/WavePack n’en représentent qu’environ 25 %, donc il est difficile pour moi d’écouter de la musique en déplacement
    Je n’arrive pas à décider à l’avance quoi mettre sur un appareil mobile
  • Moi aussi, même si c’est sur une période bien plus courte que 25 ans, je construis une collection personnelle uniquement en FLAC, et elle dépasse déjà 1 To
    Le combo serveur https://www.navidrome.org et client https://symfonium.app a très bien fonctionné pour moi
    Maintenant qu’il existe aussi des cartes SD de 2 To, j’en achèterai probablement une quand les prix baisseront
  • Sur Android, il y a toujours eu des problèmes instables avec les images de pochette et les titres
    Même après modification, ça ne s’appliquait pas, ou bien ça s’appliquait puis basculait soudain vers une mauvaise pochette ; à première vue, ça ressemblait à un bug Android
    Je me demande si tu as rencontré ce genre de problème

• J’ai créé ma propre web app pour écouter des albums entiers tout en pouvant faire une pause au milieu ou changer d’appareil
  J’aime écouter les albums du début à la fin, mais au moins YouTube Music ne mémorise pas la position de lecture, et il faut rouvrir l’album sur un autre appareil puis retrouver l’endroit où l’on s’était arrêté, ce qui est pénible
  Dans ma web app, on colle une URL, le serveur la télécharge avec yt-dlp, puis on peut la streamer depuis là ; elle mémorise toujours la position de lecture, ce qui me permet d’écouter sur mon téléphone dans la voiture puis de reprendre sur mon ordinateur portable au travail
  Ça marche aussi bien pour ajouter des mixes venant d’autres sources, comme NTS Radio

  • Ce qui me frustrait le plus dans YouTube Music, c’était justement l’absence d’une file d’attente enregistrable et d’une transition plus fluide entre appareils
    Si cette web app est publique, j’aimerais bien y jeter un œil

• Je n’ai pas encore tout lu, mais c’est un bon article, et j’aime lire comment les développeurs prennent des décisions plus détaillées et pourquoi
  Je partage l’idée que les lecteurs audio essayés ne sont pas satisfaisants
  Dans le monde des apps de musique, la mise en page et l’UI semblent s’être presque généralisées, mais ça ne me plaît pas et je ne le comprends pas vraiment
  J’ai l’impression de me battre contre toutes les apps de musique, donc je suis content de voir quelqu’un tenter de créer quelque chose de nouveau

• J’utilise toujours l’app Apple Music avec mes fichiers locaux
  J’ai désactivé le service de streaming Apple Music, j’importe tout dans l’app Apple Music de macOS, puis, comme en 2007, je branche mon téléphone à mon ordinateur portable et je synchronise comme avec un iPod
  Tout fonctionne comme prévu, et comme ma musique ne change pas souvent, la synchronisation ne pose pas de problème
  Il y a aussi une étrange nostalgie à synchroniser en filaire

  • À ma connaissance, la synchronisation Wi‑Fi automatique avec iTunes fonctionne toujours très bien

• J’ai du mal à être d’accord avec l’idée selon laquelle, à l’époque où async/await n’existait pas, le code de concurrence en Swift paraissait plus lourd et plus rempli de boilerplate qu’en Go ou en JS/TS
  L’asynchrone peut faciliter l’écriture de code concurrent, mais à mesure que la base de code grossit, le raisonnement peut devenir moins simple
  Dans une base de code asynchrone complexe, il est plus difficile de comprendre le flux du code et la concurrence
  Si l’objectif est de réduire le coût d’exécution du code en threads, il existe la solution des green threads légers ; si l’objectif est de réduire le coût de maintenance du code en threads, l’asynchrone risque de demander davantage d’efforts à long terme

  • Une bonne concurrence devrait rendre la compréhension et le raisonnement plus simples à mesure que le code grossit
    L’encapsulation fondée uniquement sur des processus ou des services apporte déjà de gros avantages
    Je vois cela moins comme un échec de la concurrence elle-même que comme une limite de l’abstraction async/await
  • Dans ce cas, l’objectif est un lecteur audio simple, donc ce ne sera probablement pas un gros problème

• Je m’attendais à ce que l’article parle non seulement d’un logiciel pour gérer et lire de la musique, mais aussi d’un appareil physique.
  Il y a quelques années, j’ai voulu acheter un lecteur MP3 à mon fils de 10 ans, qui adorait vraiment écouter de la musique mais n’était pas encore prêt à avoir un téléphone, et j’ai été surpris de voir à quel point les options étaient désastreuses.
  À mon avis, en arrêtant l’iPod, Apple a laissé un grand vide que personne n’a su combler.
  L’iPod shuffle au format clé USB a été le meilleur lecteur MP3 que j’aie jamais utilisé : il était petit, se branchait sans câble séparé, et la batterie tenait longtemps.
  Il n’y avait pas d’écran pour parcourir la musique, mais c’était le but : on laissait faire le shuffle.
  C’est dommage qu’un concept relativement simple comme celui-ci n’ait même pas été correctement reproduit sur le marché du hardware.
  Certains diront que le problème n’est pas le hardware mais le logiciel/DRM, mais l’absence de bon appareil portable bon marché pour écouter de la musique est vraiment regrettable.

  • Je pense que le vrai changement, ici, n’est pas la disparition de l’iPod.
    C’est l’existence de Spotify et des smartphones qui a tué les lecteurs MP3, et les deux ont pris tellement d’air sur le marché qu’ils ont étouffé tout le reste.
  • Fiio fabrique pas mal de produits dans cette catégorie.
    Par exemple https://www.fiio.com/cp13 et https://www.fiio.com/jm21.
  • Il y a beaucoup d’iPod d’occasion, et bon nombre des anciens modèles à disque dur sont assez faciles à modifier pour y mettre du stockage flash, ce qui peut en faire une option.
    C’est aussi un petit projet pédagogique sympa pour apprendre l’électronique et la remise en service de « vieux » appareils.
    Il existe beaucoup d’options pour personnaliser l’apparence, et des modifications plus poussées sont aussi possibles, comme l’ajout du Bluetooth ou de l’USB‑C.
    Comme d’autres l’ont dit, côté logiciel aussi, cela fonctionne encore très bien avec iTunes sous Windows et l’intégration Finder/Music sous macOS.
  • Je pense que ce n’est pas vraiment un problème de hardware ou de logiciel, mais plutôt de demande.
    Des fabricants chinois vendent pour 50 à 100 dollars des appareils comme des Mini iPhone 16 ou Mini S24, jolis, capables de lire de la musique et dotés de fonctions de smartphone.
    Les parents sont plus susceptibles d’acheter ce genre d’appareil à leurs enfants plutôt qu’un lecteur MP3.
    Ne pas donner de téléphone à son fils de 14 ans est une approche éducative peu conventionnelle, que je respecte, mais cette demande ne semble pas dépasser l’offre actuellement disponible.
  • Sony fabrique encore de très bons lecteurs sous la marque Walkman : https://electronics.sony.com/audio/walkman-digital-recorders...
    Cela peut être cher pour un enfant de 10 ans, mais on peut peut-être en trouver d’occasion sur eBay.

• La combinaison Music.app pour gérer la musique locale et la synchronisation iPhone via Finder fonctionne encore bien pour moi.
  Cela dit, Music.app semble ne plus être maintenue depuis des années après la réécriture catastrophique de Big Sur, et elle a aussi des bugs agaçants.
  Malgré ses défauts, cette combinaison reste la meilleure solution de gestion de bibliothèque musicale + synchronisation mobile que j’aie vue, mais comme le logiciel n’est pas maintenu et n’est pas cross-platform, je pense que je finirai par devoir écrire mon propre système.

  • Une partie du problème de la « réécriture » de Music vient du fait qu’il ne s’agit pas tant d’une vraie réécriture que d’un copier-coller depuis iTunes.
    Il reste beaucoup de bizarreries propres à iTunes, comme les fenêtres modales de réglages/préférences héritées de l’époque d’OS 9.
    Les fenêtres de réglages d’OS X ne devraient pas être modales.
    J’imagine qu’ils travaillent en interne sur une version réécrite de zéro, comme Music pour Windows basé sur WinUI.
  • Sur mon iPod Video de 5e génération, la synchronisation intégrée au Finder est encore très cassée.
    Le plus agaçant, c’était la synchronisation des podcasts : à l’époque où iTunes s’en chargeait, cela fonctionnait bien, mais dans la synchronisation Finder de Big Sur, il y a un bug qui fait que si l’on passe à une autre piste ou à un autre podcast puis qu’on revient, la position de lecture n’est pas mémorisée.
    Résultat, les podcasts de plus de quelques minutes deviennent pratiquement inutilisables sur l’appareil.
  • Vous pouvez aussi essayer mon app : https://www.plastaq.com/minimoon

• Les gens vont jusqu’à créer leur propre app musicale plutôt que de passer à Android.
  Je me demande si c’est à cause des bulles bleues, ou parce que tout « fonctionne tout simplement », sauf la lecture de musique hors ligne.

  • Est-ce que vous déménageriez vraiment dans un autre pays uniquement parce que le pain y est meilleur ?
    Je ne vois pas le problème à le faire soi-même.
  • J’ai créé un prototype de lecteur de musique pour iOS.
    C’est parce que l’app VLC ne parvenait pas à parser de façon fiable les métadonnées des FLAC présents sur mon serveur de fichiers, et qu’à cause des limites de stockage, je ne pouvais pas non plus conserver toute ma collection musicale sur l’appareil.
    Mon app reste un prototype dans le sens où je voudrais davantage de fonctionnalités, mais elle lit l’audio, accède aux fichiers distants et parse les métadonnées FLAC, donc elle fonctionne suffisamment pour que je manque de motivation à implémenter le reste.
    Comme l’auteur, au départ, je voulais utiliser React Native, puisque j’avais de l’expérience et quelques apps encore maintenues avec, mais je ne voulais pas cibler ni déboguer d’autres plateformes.
    J’ai donc décidé d’essayer SwiftUI, et avec un outil spécial[1], j’ai créé quelque chose qui ressemble à du hot reload.
    C’est un hack assez sale qui nécessite d’ajouter des flags de linker personnalisés dans Xcode, mais cela fonctionne suffisamment bien pour que l’expérience développeur de TypeScript et React Native ne me manque pas.
    [1] https://github.com/johnno1962/InjectionIII
  • Les gens écrivent vraiment du code pour éviter Android.
  • foobar2000 est disponible depuis longtemps sur l’App Store.
    En fait, je trouve un peu étrange que l’auteur n’ait pas trouvé d’app musicale gratuite qui lui plaise.
    Cela dit, on n’a pas forcément besoin d’une excuse pour créer quelque chose ; c’était peut-être juste une narration pour lancer l’histoire.
  • J’utilise la combinaison navidrome/substreamer sur iOS, et ça fonctionne bien.
    On peut aussi conserver la musique sélectionnée sur l’appareil.

• Si vous avez une collection de musique hors ligne, je recommande vraiment https://play.google.com/store/apps/details?id=in.krosbits.mu...
  Ça fonctionne très bien, sans problème

  • Symfonium est également excellent
    Il prend aussi en charge Plex, Jellyfin, WebDAV, SMB, etc.