Mein selbstgebauter Audio-Player

 (nexo.sh)
1 Punkte von GN⁺ 2025-05-24 | 1 Kommentare | Auf WhatsApp teilen
  • Ausgehend davon, dass es auch 2025 auf dem iPhone schwierig ist, eigene Musikdateien frei anzuhören und zu synchronisieren, wurde ein Local-first-Musikplayer in SwiftUI selbst umgesetzt
  • Wenn man das Apple-Music-Abo kündigt, stoppt die Synchronisierung der iCloud Music Library; iTunes Match ist mit 24,99 $ pro Jahr eine separate kostenpflichtige Option, die 256-kbps-AAC-Kopien online speichert
  • React Native/Expo scheiterte bei der Traversierung tief verschachtelter iCloud-Ordner und der Behandlung von Dateiberechtigungen häufig oder stürzte ab, weshalb eine SwiftUI-Implementierung mit nativen Apple-APIs die einfachere Wahl wurde
  • Die App durchsucht Dateinamen und Metadaten wie artist, album und title mit SQLite FTS5 und trennt iCloud-Import, Bibliotheksverwaltung und Wiedergabeansicht
  • Wegen Security-Scoped Bookmarks und Beschränkungen persönlicher Entwickler-Builds bleiben unter iOS selbst für eine langfristig stabile Nutzung selbst gebauter Apps Hürden bei Dateizugriff und Distribution bestehen

Warum ich selbst einen Musikplayer gebaut habe

  • Wer auf dem iPhone eigene Musikdateien abspielen will, muss Apple weiterhin bezahlen oder verschiedene Einschränkungen umgehen
  • Für Nutzer, die ihre lokale Musikbibliothek bereits organisiert haben, sind Streaming-Dienste eher eine Komfortfunktion als zwingend notwendig
  • Kündigt man Apple Music, endet die geräteübergreifende Synchronisierung auf Basis der iCloud Music Library
    • Diese Funktion steckt hinter dem Abo
    • Mit iTunes Match kann man sie für 24,99 $ pro Jahr wieder nutzen
    • Match speichert 256-kbps-AAC-Kopien online; die Originaldateien bleiben unverändert, solange der Nutzer sie nicht ändert
    • Ohne Abo verschwindet die Cloud-Synchronisierung, und man muss zurück zu Kabel-/Wi‑Fi-Synchronisierung
  • Ziel war es, einen einfachen Musikplayer selbst zu bauen, der Audiodateien importiert, organisiert und abspielt
  • Die fertige App bietet Volltextsuche, iCloud-Unterstützung und eine Local-first-Erfahrung und ist auf GitHub veröffentlicht

Warum die bestehenden Optionen nicht passten

  • Apples Standard-Apps

    • Mit der Dateien-App kann man Musikdateien in iCloud zwar direkt abspielen, sie ist aber nicht als App zum Musikhören konzipiert
    • Kernfunktionen wie Playlist-Verwaltung, Sortierung nach Metadaten und Wiedergabewarteschlange fehlen
    • Musik abspielen ist grundsätzlich möglich, die gesamte User Experience ist aber eingeschränkt; dazu gibt es auch Diskussionen in Apple-Communitys

  • Drittanbieter-Apps

    • Im App Store gibt es viele Apps für Offline-Musikwiedergabe, doch auch Apps zum Abspielen bereits eigener Dateien setzen häufig auf abo-basierte Preise
    • Doppler hatte den Vorteil eines Einmalkauf-Modells
    • Die UX war jedoch stark auf Albumverwaltung ausgerichtet, die Suchqualität war nicht zufriedenstellend, und der Import aus iCloud mit vielen verschachtelten Ordnern war langsam und schwer zu bedienen

Der Wechsel von React Native zu SwiftUI

  • Die anfängliche Wahl: React Native/Expo

    • Wegen früherer Swift-Erfahrungen wurde Swift zunächst vermieden; stattdessen fiel die Wahl zuerst auf React Native/Expo, um Webentwicklungs-Erfahrung wiederzuverwenden
    • Die Umsetzung der Wiedergabe-UI war einfach, und genutzt wurde Gionatha Sturbas music-player-Template, das die nötigen Funktionen zu haben schien
    • Die Probleme wurden beim Zugriff auf das Dateisystem und bei der Synchronisierung von Cloud-Dateien größer
    • Bibliotheken wie expo-filesystem unterstützten zwar einfache Dateiauswahl, scheiterten aber häufig bei der rekursiven Traversierung tief verschachtelter iCloud-Verzeichnisse oder brachten die App zum Absturz
    • Die iOS-Sandbox verhindert, dass Apps ohne explizite Nutzerberechtigung Dateien lesen
    • Am Ende wurde der JavaScript-basierte Ansatz komplizierter als der direkte Einsatz nativer Apple-APIs; mit einem Wechsel zu Swift ließen sich iCloud-Dateizugriff und Sandbox-Berechtigungen besser kontrollieren

  • Warum SwiftUI gewählt wurde

    • Statt UIKit oder Storyboards wurde SwiftUI gewählt, um eine deklarative UI-Schicht zu bauen und sich auf Domain-Logik und Datensynchronisierung zu konzentrieren
    • Swifts Integration von async/await und Swift Actors erleichterte Datenflüsse und Concurrency-Management
    • SwiftUI half dabei, die App in unabhängige ViewModel-Komponenten zu strukturieren
    • LLMs wie OpenAI o1 und DeepSeek erzeugten bei reinem UI-Code oder Data-Binding-Code weniger komplexe gegenseitige Abhängigkeiten

App-Struktur und Datenmodell

  • Drei zentrale Screens

    • Die App ist in die drei Flows Library import, Library management sowie Player and playback aufgeteilt
    • Library import fügt einen iCloud-Bibliotheksordner hinzu, scannt alle Ordner nach Audiodateien und schreibt die Pfade in eine SQLite-Datenbank
    • Library management verwaltet hinzugefügte Songs und erstellt Playlists
    • Player and playback übernimmt Wiederholen, Shuffle, Warteschlangenverwaltung sowie Wiedergabe, Pause und nächster Titel
    • Apples Standard-Dateiauswahl passt nicht zu einem Flow, in dem mehrere per Keyword gesuchte Verzeichnisse und mehrere Dateien auf einmal ausgewählt werden sollen
    • Startet man die App mit leerer Bibliothek, zeigt der Sync-Tab den Button „Add iCloud Source“
    • Nach Auswahl eines Ordners wird während der Baum-Traversierung ein Fortschrittsbalken angezeigt; nach Abschluss der Indexierung wechselt die App zum Library-Tab
    • Auf dem ersten Bildschirm erscheinen Playlists / Artists / Albums / Songs
    • Tippt man auf einen Track, erscheint unten ein Mini-Player; tippt man darauf, öffnet sich der Player im Vollbild
    • Der Vollbild-Player bietet Shuffle, Wiederholen, Neuordnung der Warteschlange und Lautstärke
    • Wählt man unter Sync über „+“ einen weiteren Ordner aus, werden neue Songs im Hintergrund zusammengeführt; ein Neustart ist nicht nötig

  • Serverartige Logikschicht

    • Obwohl es eine mobile App ist, wurde auf Basis von Web- und Cloud-Backend-Erfahrung eine backendartige Architektur angewendet
    • Domain- und Logikschicht wurden von View- und ViewModel-Schicht getrennt, um Cloud-Synchronisierung, Metadaten-Parsing und SQLite-Datenzugriff stabil zu handhaben
    • Die Schichtenstruktur sieht so aus
      • SQLite speichert ursprüngliche Song-Zeilen und den FTS-Index
      • Repository kapselt die Datenbank und stellt eine asynchrone API bereit
      • Domain Actor besitzt Business-Regeln wie Import, Suche und Warteschlangenlogik
      • ViewModel abonniert den Actor und wandelt Daten in UI-Strukturen um
      • SwiftUI View rendert die übergebenen Daten
    • Zustandsänderungen bleiben thread-safe, und iCloud-Synchronisierung, Wiedergabe und UI sind so getrennt, dass sie nicht direkt Schichten überspringen

Lokale Suche mit SQLite FTS5

  • Als persistenter Speicher wurde SQLite verwendet, nicht CoreData
  • CoreData wurde vermieden, weil Schema, rohe Queries und insbesondere Volltextsuche direkt kontrolliert werden sollten
  • Seit etwa iOS 11 kann SQLite mit FTS-Funktionen ohne zusätzliche Einrichtung genutzt werden
  • Für normale Queries wurde SQLite.swift verwendet, FTS-Queries wurden jedoch als normale SQL-Statements ausgeführt
  • SQLite FTS5 ermöglicht Abfragen über Dateinamen und Metadaten wie artist, album und title ohne separate Suchinfrastruktur

  • Aufbau der FTS-Tabellen

    • Es werden zwei FTS5-Tabellen verwendet
    • songs_fts: wird von SQLiteSongRepository verwendet und indexiert artist, title, album, albumArtist
    • source_paths_fts: wird von SQLiteSourcePathSearchRepository verwendet und indexiert fullPath, fileName
    • Beide FTS-Tabellen liegen neben den normalen B-Tree-Tabellen songs und source_paths
    • FTS ist in der UI read-only; alle Schreibvorgänge werden innerhalb des Repository verarbeitet
    • Ein Beispiel für die Erstellung von songs_fts lässt songId UNINDEXED und verwendet den unicode61-Tokenizer
    • unicode61 wurde gewählt, um unterschiedliche Zeichen zu verarbeiten
    • Nicht durchsuchte Schlüssel werden als UNINDEXED markiert, damit das Term-Wörterbuch nicht unnötig wächst

  • Teilsuche und Ranking

    • Gibt der Nutzer „lumine“ ein, wird intern ein Wildcard wie „lumine*“ angehängt, um sofort Ergebnisse für Teilsuchen zu finden
    • Für die Sortierung der Suchergebnisse wird SQLites bm25 genutzt
    • Dieser Ansatz bietet ein vorhersagbares Schema, Local-first-Zugriff und leistungsfähige Volltextsuche, ohne Netzwerkabhängigkeit oder externe Dienste hinzuzufügen

iOS-Dateizugriff und Bookmark-Einschränkungen

  • iOS-Apps können persistente Bookmarks speichern, um sich Dateipfade zu merken
  • Security-scoped bookmarks, die erweiterten Zugriff auf Dateien außerhalb der App-Sandbox geben, gibt es jedoch nur unter macOS
  • iOS-Apps können sich Dateipfade mit normalen Bookmarks merken und über den Dokumentauswähler erneut Zugriff anfordern; es gibt aber keine Garantie, dass dieser Zugriff stillschweigend dauerhaft erhalten bleibt
  • Relevante Informationen stehen in Apples Bookmark-Dokumentation
  • Zur Abmilderung wurde ein alternativer Mechanismus implementiert, der Dateien in den Sandbox-Container der App kopiert
    • Solange das Bookmark gültig ist, werden Dateien im Hintergrund proaktiv kopiert
    • Das senkt das Risiko, nach einem Zurücksetzen der Berechtigungen durch iOS auf ungültige Audiodatei-Referenzen zuzugreifen
  • Dieser Ansatz verbessert auch die Indexierungsgeschwindigkeit
    • Die Ordnerstruktur wird einmal gescannt, solange der Zugriff aktiv ist
    • Nur relevante Audiodateien werden importiert
    • Tief verschachtelte Verzeichnisse werden sicher traversiert
  • Das Problem, einzelne Audiodateien an externen Speicherorten auch nach einem Geräteneustart zuverlässig abzuspielen, wurde nicht gelöst
  • Selbst in nativen Apps wird dieser Use Case unter iOS nicht ausreichend unterstützt, und stabiler Dateizugriff bleibt kompliziert

Wiedergabe und UI-Implementierung

  • Metadaten-Parsing

    • Zum Parsen von Audiodatei-Metadaten wurde Apples AVFoundation-Framework mit AVURLAsset verwendet
    • AVURLAsset kann Metadaten von Mediendateien wie title und album artist auslesen
    • Einige Felder wie Tracknummern mussten direkt in ID3-Tags gesucht werden
    • Da die offizielle Dokumentation Edge Cases nicht ausreichend abdeckt, wurden Implementierungsbeispiele über die GitHub-Suche herangezogen

  • Audiowiedergabe

    • Nach der Bibliotheksindexierung wurde der Audioplayer umgesetzt, indem eine AVAudioPlayer-Instanz initialisiert und zur Wiedergabe genutzt wird
    • Um Musik über das Control Center zu steuern, muss das AVAudioPlayerDelegate-Protokoll implementiert und mit Apples MPRemoteCommandCenter verbunden werden
    • MPRemoteCommandCenter ermöglicht der App, auf systemweite Wiedergabesteuerung zu reagieren

Swift und die Apple-Entwicklungserfahrung

  • Was schwierig war

    • Xcodes Live-SwiftUI-Previews sind ein Fortschritt, aber die gesamte Entwicklungserfahrung erreicht nicht das Niveau, das Flutter schon vor fünf Jahren mit VSCode-Integration, Live-Simulator-Reload und vertrauten Debugging-Tools bot
    • Swifts LSP-Unterstützung für Neovim oder VSCode erfordert zusätzliche Tools wie xcode-build-server und entspricht nicht der Developer Experience webzentrierter Ökosysteme
    • Teile des Apple SDK bleiben weiterhin im Objective-C-Stil
    • Spotlight-Dateisuche wird nur über NSMetadataQuery verfügbar gemacht, und NSMetadataQuery verwendet KVO und String-Schlüssel
    • Einen Swift-freundlichen Wrapper gibt es noch nicht
    • SwiftUIs deklarative UI ist nützlich, aber das Gesamtverhalten einer App mit iCloud-Berechtigungen lässt sich in Previews nicht emulieren; Cloud-Interaktionen müssen direkt gemockt werden

  • Was gut war

    • Dank async/await ließ sich I/O-lastiger Concurrency-Code ohne Callbacks wie imperativer Code schreiben
    • Auch synchroner Code ließ sich einfach in Actors unterbringen und ähnlich wie im JavaScript-Ökosystem aufrufen
    • Native Apple-Bibliotheken konnten direkt genutzt werden, ohne durch Open-Source-Bindings von React Native oder Flutter eingeschränkt zu sein
    • Viele Apple-APIs haben Beispiele, die den Einstieg erleichtern
    • SwiftUIs React-artige Art, UIs zu komponieren, bietet Produktivität und Raum zum Ausprobieren

Warum persönliche Apps unter iOS langfristig schwer nutzbar sind

  • Nach etwa 1,5 Wochen Implementierung entstand ein lokaler/offline Musikplayer, der Audiodateien aus iCloud-Speicher importieren kann
  • Ohne Entwicklerzertifikat läuft die App jedoch nur 7 Tage und muss danach neu gebaut werden
  • Die Teilnahme am Apple Developer Program kostet 99 $
  • Auch nach dem DMA Act der EU ist Sideloading nicht vollständig geöffnet
    • EU-Nutzer können Drittanbieter-Marktplatz-Apps von Entwicklerseiten installieren
    • Entwickler müssen weiterhin an Apples Programm für 99 $ pro Jahr teilnehmen
    • Sie müssen außerdem Apples Alternative Terms zustimmen
    • Für persönliche und Hobby-Nutzung verschwindet die 7-Tage-Beschränkung für Entwickler-Builds nicht
  • Auch PWAs unter iOS bleiben eingeschränkt
    • Auch nach den Updates iOS 16 bis 18.x laufen PWAs in der Safari-Sandbox
    • WebGL2 und web-push sind nutzbar
    • Web Bluetooth, USB, NFC, Background Sync sowie garantierter Speicher von mehr als etwa 50 MB werden nicht bereitgestellt
    • WebGL läuft über einen Metal-Shim, weshalb die tatsächliche Framerate oft hinter nativen Metal-Apps zurückbleibt
  • AI hat die Komplexität der Softwareentwicklung reduziert, indem sie Wissen für den Umgang mit ungewohnten Technologien leichter zugänglich macht, doch iOS-Apps müssen weiterhin künstlichen Regeln folgen
  • Selbst wenn es sich um eine selbst gebaute persönliche App handelt, bleibt Apples letzte Hürde bestehen, wenn sie länger als eine Woche laufen soll; das beschränkt Entwicklung und Distribution persönlicher Apps

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-24
Meinungen auf Hacker News

  • Ich habe die Zeit erlebt, in der Winamp der Standard-Musikplayer war, und auch im Streaming-Zeitalter organisiere ich meine lokale Musikbibliothek immer noch in Ordnern.
    Wie andere hier in den Kommentaren habe ich als Hobbyprojekt einen altmodischen Musikplayer gebaut, um offline Musik zu hören; es ist eine einseitige HTML/JS-App mit vollständiger Tastaturbedienung und einer einfachen Warteschlangenfunktion.
    Man kann ihn sich hier ansehen: https://nobsutils.com/mp

    • Auch rund 27 Jahre später denke ich immer noch, dass die Winamp-UI ziemlich nah an der richtigen Lösung war.
      Mir gefiel diese Einfachheit: eine Sammlung von Dateien in einem Verzeichnis, die gesamte Sammlung im Shuffle, oder nur ein bestimmtes Verzeichnis abspielen.
    • Genau so einen einfachen Musikplayer habe ich gesucht, gefällt mir.
      Hinweis: Das heute übliche Lesezeichen-Kürzel cmd + d ändert hier das Theme, statt die Website zu bookmarken.
    • Für mich war der Standard-Musikplayer immer foobar2000; inzwischen nutze ich stattdessen die App Cog.

  • Ich habe 25 Jahre lang eine Musiksammlung im FLAC-Format aufgebaut und mir letztes Jahr ein Android-Smartphone plus eine 1-TB-MicroSD-Karte gekauft, sodass endlich meine gesamte Musik darauf passt.
    Es war ein langes Projekt, bis die Technik aufgeholt hat, aber jetzt kann ich alles in die Tasche stecken, und das macht mich ziemlich zufrieden.
    Ich bin sicher nicht der Einzige, der nicht zum Mieter werden will, der die Kontrolle abgibt, streamt, was die Branche ihm vorsetzt, und Werbung hinnimmt; und es ist schön zu sehen, dass manche Leute sogar ihre eigene App dafür bauen.

    • Die Technik hat schon vor langer Zeit aufgeholt; es ist eher so, dass du an einem Format festhältst, das für diesen Zweck nicht passend ist.
      Wenn man gut neu encodiert, bekommt man transparenten Klang, bei dem man keinen Unterschied hört, und kann die gesamte Musik auf eine viel kleinere Karte packen; als Backup kann man FLACs auf dem Desktop behalten.
    • Du hast deine Sammlung wirklich sehr gut kuratiert.
      In meiner Sammlung machen FLAC/APE/ALAC/WavePack nur etwa 25 % aus, trotzdem ist sie über 3 TB groß, und deshalb ist es schwierig, unterwegs Musik zu hören.
      Ich kann nicht im Voraus auswählen, was ich auf ein mobiles Gerät packen soll.
    • Bei mir sind es zwar deutlich weniger als 25 Jahre, aber auch ich baue mir eine persönliche Sammlung nur mit FLAC auf, und sie ist schon über 1 TB groß.
      Als Server hat sich https://www.navidrome.org und als Client https://symfonium.app als sehr gute Kombination erwiesen.
      Jetzt gibt es auch 2-TB-SD-Karten; wenn der Preis fällt, kaufe ich mir wahrscheinlich eine.
    • Unter Android hatte ich immer wieder instabile Probleme mit Coverbildern und Titeln.
      Änderungen wurden entweder nicht übernommen, oder sie wurden übernommen und sprangen dann plötzlich auf irgendein falsches Cover um; für mich sah das wie ein Android-Bug aus.
      Mich würde interessieren, ob du solche Probleme auch hattest.

  • Ich habe selbst eine Web-App gebaut, damit ich ganze Alben hören kann, aber zwischendurch pausieren oder das Gerät wechseln kann.
    Ich höre Alben gern von Anfang bis Ende, aber zumindest YouTube Music merkt sich die Wiedergabeposition nicht, und auf einem anderen Gerät muss man das Album wieder öffnen und die Stelle suchen, an der man aufgehört hat – das war lästig.
    In meiner Web-App fügt man eine URL ein, der Server lädt sie mit yt-dlp herunter, und von dort kann man streamen; die Wiedergabeposition wird immer gespeichert, sodass ich im Auto auf dem Smartphone hören und im Büro auf dem Laptop fortsetzen kann.
    Das passt auch gut, wenn man Mixes aus anderen Quellen wie NTS Radio hinzufügen will.

    • Genau die speicherbare Warteschlange und ein reibungsloserer Gerätewechsel waren für mich die frustrierendsten Punkte bei YouTube Music.
      Falls die Web-App öffentlich ist, würde ich sie mir gern einmal ansehen.

  • Ich habe noch nicht alles gelesen, aber es ist ein guter Artikel, und ich lese gern, wie Entwickler detailliertere Entscheidungen getroffen haben und warum.
    Ich kann nachvollziehen, dass die ausprobierten Audioplayer nicht gefallen haben.
    In der Welt der Musik-Apps scheinen Layout und UI fast universell geworden zu sein, aber mir gefällt das nicht, und ich verstehe es auch nicht wirklich.
    Es fühlt sich an, als würde man mit jeder Musik-App kämpfen; deshalb freue ich mich über Leute, die versuchen, etwas Neues zu bauen.

  • Ich nutze die Apple-Music-App weiterhin mit meinen lokalen Dateien.
    Den Apple-Music-Streamingdienst habe ich deaktiviert, alles in die Apple-Music-App unter macOS importiert und dann, wie 2007, das Smartphone an den Laptop gesteckt und wie einen iPod synchronisiert.
    Alles funktioniert wie erwartet, und da sich meine Musik nicht häufig ändert, ist auch die Synchronisierung kein Problem.
    Das Synchronisieren per Kabel hat auch eine seltsam nostalgische Note.

    • Soweit ich weiß, funktioniert auch die automatische Wi‑Fi-Synchronisierung mit iTunes immer noch gut.

  • Der Aussage, dass sich Concurrency-Code in Swift vor async/await im Vergleich zu Go oder JS/TS unbeholfener und boilerplate-lastiger angefühlt habe, kann ich schwer zustimmen.
    Asynchrone Verarbeitung kann es zwar einfacher machen, nebenläufigen Code zu schreiben, aber je größer die Codebasis wird, desto weniger einfach kann das Reasoning darüber werden.
    In komplexen asynchronen Codebasen ist es schwieriger, den Codefluss und die Nebenläufigkeit zu verstehen.
    Wenn das Ziel darin besteht, die Ausführungskosten von Thread-Code zu senken, gibt es die Lösung leichtgewichtiger Green Threads; wenn das Ziel darin besteht, die Wartungskosten von Thread-Code zu senken, dürfte Async langfristig eher mehr Aufwand erfordern.

    • Gute Nebenläufigkeit sollte Verständnis und Reasoning einfacher machen, je größer der Code wird.
      Schon eine prozess- oder servicebasierte Kapselung bringt große Vorteile.
      Ich sehe das weniger als ein Scheitern von Nebenläufigkeit an sich, sondern eher als Grenze der async/await-Abstraktion.
    • In diesem Fall ist das Ziel ein einfacher Audioplayer, daher wird es vermutlich kein großes Problem sein.

  • Ich hatte erwartet, dass der Artikel nicht nur von Software zum Verwalten und Abspielen von Songs handelt, sondern auch von einem physischen Gerät.
    Vor ein paar Jahren wollte ich meinem 10-jährigen Sohn, der sehr gern Musik hörte, aber noch nicht bereit für ein Smartphone war, einen MP3-Player kaufen – und war überrascht, wie trostlos die Auswahl war.
    Ich finde, Apple hat mit der Einstellung des iPod eine große Lücke hinterlassen, die niemand gefüllt hat.
    Der iPod shuffle im Format eines USB-Sticks war der beste MP3-Player, den ich je benutzt habe: klein, ohne separates Kabel einsteckbar, und der Akku hielt lange.
    Es gab keinen Bildschirm zum Durchsuchen der Musik, aber das war Absicht; man überließ es einfach dem Shuffle.
    Schade, dass selbst ein so vergleichsweise einfaches Konzept auf dem Hardwaremarkt nie richtig kopiert wurde.
    Man wird sagen, es sei kein Hardware-, sondern ein Software-/DRM-Problem, aber es ist wirklich bedauerlich, dass es keine guten, günstigen tragbaren Geräte zur Musikwiedergabe gibt.

    • Ich glaube, die eigentliche Veränderung hier war nicht das Verschwinden des iPod.
      Spotify und Smartphones haben den MP3-Player getötet; zusammen haben sie dem Markt so viel Luft genommen, dass alles andere erstickt ist.
    • Fiio stellt ziemlich viele Produkte in dieser Kategorie her.
      Beispiele sind https://www.fiio.com/cp13 und https://www.fiio.com/jm21.
    • Es gibt viele gebrauchte iPods, und viele der alten Festplattenmodelle lassen sich recht einfach auf Flash-Speicher umbauen; das kann also eine Option sein.
      Als kleines Lernprojekt zu Elektronik und zur Wiederverwendung „alter“ Geräte ist das ebenfalls ganz gut.
      Es gibt viele Möglichkeiten zur optischen Anpassung, und auch tiefere Modifikationen wie das Hinzufügen von Bluetooth oder USB‑C sind möglich.
      Wie andere schon gesagt haben, funktioniert auch die Softwareseite weiterhin gut – mit iTunes unter Windows und der Finder-/Music-Integration unter macOS.
    • Ich glaube, es ist weniger ein Hardware- oder Softwareproblem als vielmehr ein Nachfrageproblem.
      Chinesische Hersteller verkaufen Geräte für 50–100 Dollar, die aussehen wie ein Mini iPhone 16 oder Mini S24, Musik abspielen können und auch Smartphone-Funktionen haben.
      Eltern kaufen ihren Kindern wahrscheinlich eher so ein ähnliches Gerät als einen MP3-Player.
      Einem 14-jährigen Sohn kein Smartphone zu geben, ist ein unkonventioneller Erziehungsstil, den ich respektiere, aber mir scheint nicht, dass diese Nachfrage größer ist als das derzeit mögliche Angebot.
    • Sony baut unter der Marke Walkman immer noch ziemlich gute Player: https://electronics.sony.com/audio/walkman-digital-recorders...
      Für ein 10-jähriges Kind sind sie vielleicht teuer, aber auf eBay findet man eventuell gebrauchte Geräte.

  • Die Kombination aus Music.app zum Verwalten lokaler Musik und der iPhone-Synchronisierung über den Finder funktioniert für mich immer noch gut.
    Allerdings wirkt die Music.app seit dem furchtbaren Rewrite in Big Sur seit Jahren ungepflegt, und es gibt nervige Bugs.
    Trotz ihrer Schwächen ist diese Kombination die beste Lösung für Musikbibliotheksverwaltung + mobile Synchronisierung, die ich gesehen habe; da die Software aber nicht gepflegt wird und nicht plattformübergreifend ist, werde ich am Ende wohl mein eigenes System schreiben müssen.

    • Ein Teil des Problems beim „Rewrite“ von Music ist, dass es weniger ein echter Rewrite war als vielmehr etwas, das aus iTunes kopiert und eingefügt wurde.
      Es sind viele iTunes-typische Merkwürdigkeiten geblieben, etwa das modale Einstellungs-/Preferences-Fenster als Relikt aus OS-9-Zeiten.
      Ein Einstellungsfenster unter OS X sollte nicht modal sein.
      Ich vermute, dass intern an einer von Grund auf neu gebauten Version gearbeitet wird, ähnlich wie bei der komplett neu erstellten, WinUI-basierten Music-App für Windows.
    • Auf meinem iPod Video der 5. Generation ist die eingebaute Finder-Synchronisierung immer noch ziemlich kaputt.
      Am nervigsten war die Podcast-Synchronisierung: Als iTunes noch dafür zuständig war, funktionierte sie gut, aber in der Finder-Synchronisierung von Big Sur gibt es einen Bug, durch den die Wiedergabeposition nicht gespeichert wird, wenn man zu einem anderen Track oder Podcast wechselt und zurückkommt.
      Damit werden Podcasts, die länger als ein paar Minuten sind, auf dem Gerät praktisch unbrauchbar.
    • Du kannst auch meine App ausprobieren: https://www.plastaq.com/minimoon

  • Statt zu Android zu wechseln, bauen die Leute wirklich ihre eigene Musik-App.
    Ich frage mich, ob es an den blauen Sprechblasen liegt oder daran, dass alles „einfach funktioniert“ – außer der Offline-Musikwiedergabe.

    • Würdest du wirklich in ein anderes Land ziehen, nur weil das Brot dort besser schmeckt?
      Ich sehe nicht, was daran falsch sein soll, es selbst zu backen.
    • Ich habe einen Prototyp eines Musik-Players für iOS gebaut.
      Der Grund war, dass die VLC-App die Metadaten der FLAC-Dateien auf meinem Fileserver nicht zuverlässig parsen konnte und ich wegen Speicherplatzbeschränkungen nicht meine gesamte Musiksammlung auf dem Gerät speichern konnte.
      Meine App ist insofern ein Prototyp, als ich mir mehr Funktionen wünsche, aber sie kann Audio abspielen, auf entfernte Dateien zugreifen und FLAC-Metadaten parsen – sie funktioniert also gut genug, dass mir die Motivation fehlt, die Zusatzfunktionen umzusetzen.
      Wie der Autor wollte ich anfangs React Native verwenden, weil ich Erfahrung damit habe und ein paar Apps damit pflege, aber ich wollte keine anderen Plattformen anvisieren oder debuggen.
      Also beschloss ich, SwiftUI auszuprobieren, und habe mit einem speziellen Tool[1] etwas Hot-Reload-Ähnliches gebaut.
      Es ist ein ziemlich schmutziger Hack, bei dem man Xcode eigene Linker-Flags hinzufügen muss, aber es funktioniert gut genug, dass ich die Developer Experience von TypeScript und React Native nicht vermisse.
      [1] https://github.com/johnno1962/InjectionIII
    • Leute schreiben tatsächlich Code, nur um Android zu vermeiden.
    • foobar2000 ist schon seit langer Zeit im App Store.
      Ehrlich gesagt finde ich es etwas seltsam, dass der Autor keine kostenlose Musik-App gefunden hat, die ihm gefällt.
      Andererseits braucht man nicht unbedingt eine Ausrede, um etwas zu bauen; vielleicht war es nur die Erzählung, um die Geschichte ins Rollen zu bringen.
    • Ich nutze unter iOS die Kombination aus navidrome/substreamer-App, und sie funktioniert gut.
      Ausgewählte Musik kann man auch auf dem Gerät behalten.

  • Wenn du eine Offline-Musiksammlung hast, kann ich https://play.google.com/store/apps/details?id=in.krosbits.mu... wirklich empfehlen
    Funktioniert problemlos sehr gut

    • Symfonium ist ebenfalls hervorragend
      Unterstützt auch Plex, Jellyfin, WebDAV, SMB usw.