Der Audio-Player, den ich selbst gebaut habe

 (nexo.sh)
1 Punkte von GN⁺ 2025-05-24 | 1 Kommentare | Auf WhatsApp teilen
  • Auch 2025 gibt es noch viele Einschränkungen beim freien Abspielen von MP3-Musik auf dem iPhone
  • Apple- und Drittanbieter-Apps sind meist kostenpflichtige Dienste oder bieten nur geringe Benutzerfreundlichkeit
  • Die selbst entwickelte App bietet Volltextsuche, iCloud-Unterstützung und eine Local-First-Umgebung
  • Cross-Platform-Ansätze wie React Native stießen wegen Dateisystembeschränkungen und Stabilitätsproblemen an Grenzen
  • Mit SwiftUI und einem SQLite-basierten Design wurde eine unabhängige und hoch skalierbare Musikverwaltung umgesetzt

Überblick

Der Beitrag stellt den Prozess und das Ergebnis vor, wie der Entwickler aus dem Unbehagen heraus selbst eine Musik-Player-App gebaut hat, weil es selbst 2025 auf dem iPhone noch schwierig ist, selbst besessene MP3-Dateien frei abzuspielen. Während sowohl Apples Musikdienste als auch externe Apps verschiedene Einschränkungen und Bezahlmodelle haben, bietet die Eigenentwicklung eine auf Verwaltung und Wiedergabe eigener Musikdateien optimierte Nutzererfahrung.

Warum ich den Musik-Player selbst gebaut habe

  • Cloud-basierte Synchronisierungsfunktionen wie Apple Music und die iCloud Music Library funktionieren nur mit einem kostenpflichtigen Abonnement
  • Wird das Abo beendet, werden automatische Synchronisierung und der Zugriff auf Musikordner vollständig blockiert
  • Es wurde spürbar, dass bei bestehender Integration in Musikbibliotheken und der allgemeinen Nutzbarkeit über Geräte hinweg die Rechte des Eigentümers fehlen
  • Es sollte die Selbstbestimmung umgesetzt werden, dass man „mit einem gekauften Smartphone notwendige Funktionen auch selbst bauen kann“

Analyse der Musiklösungen von Apple und Drittanbietern

Apples Standard-Apps

  • Über die Files-App lassen sich Musikdateien aus iCloud-Ordnern abspielen, aber Playlist-Verwaltung, Sortierung nach Metadaten und Queue-Steuerung sind nur unzureichend vorhanden
  • Die Nutzererfahrung ist nicht für Musikhören optimiert

Drittanbieter-Apps

  • Im App Store gibt es verschiedene externe Apps, aber viele setzen auf Abo-basierte Bezahlmodelle, und der Funktionsumfang unterscheidet sich stark
  • Es gibt auch einige kostenpflichtige Apps mit Einmalkauf wie Doppler, doch die Such- und Importerfahrung in großen iCloud-Ordnern ist nicht reibungslos

Der technische Weg in den „Builder Mode“

  • Es fiel die Entscheidung, selbst eine Musik-Player-App zu bauen
  • Gewünschte Funktionen: schnelle Volltextsuche über komplette iCloud-Ordner, Musikverwaltungsfunktionen auf dem Niveau offizieller Musik-Apps (Queue, Playlists, Sortierung usw.) sowie eine intuitive Oberfläche

Erster Versuch mit React Native

  • Wegen früherer Unannehmlichkeiten mit Swift (früher etwa ohne async/await-Unterstützung) wurde React Native/Expo bevorzugt
  • Mit Open-Source-Templates ließ sich die UI problemlos umsetzen, aber bei Dateisystemzugriff und Synchronisierung von iCloud-Ordnern traten App-Abstürze und funktionale Grenzen auf
  • Wegen der iOS-Sandbox-Regeln wurde klar, dass ohne explizite Berechtigung kein Zugriff auf externe Ordner möglich ist, daher erfolgte der Wechsel zu Swift

Warum SwiftUI gewählt wurde

  • Nutzung des deklarativen UI-Paradigmas von SwiftUI sowie von modernem async/await und Swift Actor-Support
  • Durch die strikte Trennung von UI und Datenlogik konnten ein sauberer Datenfluss und Domänen-Parallelität umgesetzt werden
  • Außerdem half es bei der Optimierung der Nutzung von LLMs (OpenAI o1, DeepSeek usw.) und verringerte Abhängigkeiten im erzeugten UI-Code

App-Architektur und Datenmodell

  • Als Datenspeicher wurde SQLite verwendet; weil sich Volltextsuche (FTS5) direkt nutzen ließ, wurde es statt CoreData gewählt

  • Die App hat 3 Hauptbildschirme bzw. Modi:

    1. Bibliotheksimport: Audio-Dateipfade aus iCloud-Ordnern werden gesammelt in der DB gespeichert, um flexible Suche und Verwaltung zu unterstützen
    2. Bibliotheksverwaltung: Playlists, Kategorisierung von Songs, Bearbeitung usw.
    3. Musikwiedergabe: Queue-Verwaltung (Wiederholen, Shuffle usw.) und grundlegende Song-Steuerung

  • Nutzerfluss beim Bibliotheksimport:

    • Im anfänglich leeren Zustand wird über „Add iCloud Source“ ein Ordner gewählt und der Verzeichnisbaum gescannt
    • Sobald die Indizierung abgeschlossen ist, wechselt man zum Bibliotheks-Tab, wo keywordbasierte Listen und ein Mini-Player bereitstehen
    • Werden neue Songs hinzugefügt, werden sie im Hintergrund automatisch zusammengeführt

Backend-artige Logikschicht

  • Basierend auf Entwicklungserfahrung in Web-/Cloud-basierten Startups wurden Logikschicht und UI/ViewModel strikt getrennt
  • Die Domänenschicht (Swift actors) enthält die zentrale Business-Logik (Import, Suche, Queue usw.) und sorgt für Thread-Sicherheit
  • UI-Updates werden über ViewModels sauber aufgeteilt, wodurch Abhängigkeiten zwischen Dateisynchronisierung, Wiedergabe und UI minimiert und die Wartbarkeit verbessert werden

Volltextsuche mit SQLite implementieren

  • Ab iOS 11 kann SQLite mit FTS5-Unterstützung ohne zusätzliche Konfiguration verwendet werden
  • Dadurch ist schnelle Suche ohne externen Suchindex oder Server möglich
  • Für normale Queries wurde die Bibliothek SQLite.swift genutzt, für FTS-Abfragen direkt SQL

Struktur der FTS-Tabellen

  • songs_fts: indexiert artist, title, album, albumArtist usw.
  • source_paths_fts: indexiert Dateipfade und Dateinamen
  • Sie existieren parallel zu den Haupttabellen und werden in der UI nur für die Suche (READ) verwendet
  • Index-Updates werden über DB-Transaktionen verarbeitet, um Datenkonsistenz zu gewährleisten

Fuzzy Search und Ranking

  • Hinter Eingaben wird automatisch ein Wildcard angehängt, sortiert wird nach Relevanz auf Basis von BM25
  • Insgesamt entstand so eine vorhersagbare Datenstruktur ohne Netzwerkabhängigkeit und eine leistungsfähige lokale Suchumgebung

iOS-Dateisystem und Nutzung von Bookmarks

  • Anders als macOS unterstützt iOS keine security-scoped bookmarks, weshalb die dauerhafte Erweiterung des Zugriffs auf externe Dateien fehlt
  • Da nur Pfadinformationen gespeichert werden, muss der Nutzer beim erneuten Zugriff die Berechtigung erneut erteilen
  • Als Lösung wird die Datei selbst zum Zeitpunkt der Zugriffsfreigabe in die App-Sandbox kopiert
  • Die automatische Kopie im Hintergrund verbessert die Geschwindigkeit der Dateiindizierung
  • Auch nach einem Geräte-Neustart bleibt direktes Abspielen externer Dateien schwierig, was zeigt, wie stark die Dateizugriffsbeschränkungen von iOS sind

Wiedergabe auf Basis von AVFoundation und Interface-Design

  • Mit dem AVFoundation-Framework und AVURLAsset werden Metadaten von Audiodateien analysiert
  • Einige Felder wie die Track-Nummer werden manuell geparst (unter Nutzung von ID3-Tags)
  • Für die Audiowiedergabe wird AVAudioPlayer verwendet, und für die Anbindung an das Control Center werden MPRemoteCommandCenter und Delegate-Protokolle implementiert

Eindrücke nach der Entwicklung und Gedanken zu Apples Richtlinien

Was unbequem war

  • Die eingeschränkte Umgebung von Xcode: SwiftUI-Live-Previews sind zwar fortschrittlich, reichen aber nicht an den Komfort von VSCode oder Flutter heran
  • Mangelnde Flexibilität des Editors: Wer Swift LSP in Neovim oder VSCode nutzen will, braucht zusätzliche Einrichtung, und die Umsetzung ist noch unausgereift
  • Einige Ecken des SDK sind noch stark Objective-C-zentriert: etwa bei der Metadatensuche fehlen moderne, Swift-freundliche APIs
  • Umständliches Debugging der iCloud-Integration: In SwiftUI-Previews lassen sich Cloud-Funktionen nicht vollständig umsetzen, daher mussten Mocks direkt gebaut werden

Positive Aspekte

  • Mit async/await lässt sich I/O-gebundener nebenläufiger Code deutlich einfacher schreiben
  • Reichhaltige native Bibliotheken: Dadurch sind vielfältigere Funktionen möglich als mit den Grenzen von Open-Source-Bindings
  • Deklaratives UI-Design in SwiftUI: Die Stärken des React-Ansatzes und die hohe Produktivität waren deutlich spürbar

Fazit: Sollte Entwicklung nicht einfacher sein?

  • In 1,5 Wochen wurde das Ziel eines lokalen/offline Musik-Players erreicht
  • In der Praxis gibt es jedoch sogar bei der Verteilung der App selbst Einschränkungen: Ohne Entwicklerzertifikat ist sie nach 7 Tagen nicht mehr nutzbar, außerdem ist eine jährliche Entwicklerregistrierung für 99 US-Dollar nötig
  • Auch nach dem EU DMA Act ist Sideloading nicht vollständig geöffnet, und für Einzelentwickler und Hobbyentwickler bestehen weiterhin Hürden
  • Auch PWAs sind unter iOS eingeschränkt, etwa durch fehlende Unterstützung wichtiger APIs (Web Bluetooth/USB/NFC, Background Sync usw.)
  • AI hat zwar die Entwicklungshürden gesenkt, aber gerade iOS hält sie durch künstliche Vorgaben hoch
  • Einschränkungen für unabhängige Entwickler und Nutzerrechte bestehen weiter, und die Geschlossenheit von iOS bleibt ein Hindernis für Innovation

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-24
Hacker-News-Kommentare
  • Ich baue seit 25 Jahren meine Musiksammlung im FLAC-Format auf und war letztes Jahr sehr zufrieden, als ich mir ein Android-Handy und eine 1-TB-microSD-Karte gekauft habe und damit meine komplette Musik in die Tasche stecken konnte. Ich bin sicher nicht der Einzige, der keine Musik mieten, die Kontrolle verlieren, vom Markt gepushte Songs streamen oder sich mit Werbung herumschlagen will. Es ist großartig zu sehen, wenn jemand dafür seine eigene App entwickelt.
    • Die Technik ist dafür schon seit Jahren weit genug, nur ich halte wohl an einem für mich ungeeigneten Format fest. Mit gutem Re-Encoding bekommt man die gesamte Musik in deutlich kleinerer Größe unter, bei einer so transparenten Klangqualität, dass man praktisch keinen Unterschied hört. Ich würde empfehlen, die FLAC-Dateien als Backup auf dem Desktop zu behalten.
    • Respekt, du scheinst wirklich jemand zu sein, der ernsthaft sammelt. In meiner Musiksammlung sind etwa 25 % verlustfreie Formate wie FLAC/APE/ALAC/WavePack, und sie ist inzwischen über 3 TB groß. Deshalb ist es schwierig, unterwegs Musik zu hören — ich kann kaum im Voraus auswählen, was ich auf ein mobiles Gerät kopieren soll.
    • Unter Android habe ich ständig Probleme damit, dass Albumcover oder Titeldaten nicht korrekt übernommen werden oder sich zufällig ändern. Das wirkt auf mich wie ein Android-Bug — hat jemand dafür eine Lösung gefunden?
    • Ich sammle meine private Kollektion ebenfalls nur in FLAC, wenn auch noch keine 25 Jahre lang. Ich bin inzwischen über 1 TB und sehr zufrieden mit einem Navidrome-Server und dem Symfonium-Client. 2-TB-microSD-Karten kommen ja inzwischen auf den Markt, und wenn die Preise noch etwas sinken, werde ich mir vermutlich eine zulegen.
  • Ich höre seit den alten Winamp-Zeiten Musik und organisiere meine lokale Musikbibliothek auch im Streaming-Zeitalter noch ordnerweise. Wie einige andere hier habe ich mir aus Spaß ebenfalls einen Oldschool-Musikplayer für Offline-Musik gebaut: eine einseitige HTML/JS-App mit vollständiger Tastatursteuerung und einfacher Queue-Funktion. Wer mag, kann sich https://nobsutils.com/mp anschauen.
    • Ich gehöre auch zu den Leuten, die schon vor 27 Jahren fanden, dass die Winamp-Oberfläche wirklich großartig war. Die Einfachheit von Dateisammlungen nach Ordnern, globalem Shuffle und dem Abspielen nur bestimmter Verzeichnisse war ihre größte Stärke.
    • Feedback: Die selbst entwickelte App funktioniert wirklich gut.
    • Für mich war foobar2000 immer der beste Musikplayer, inzwischen nutze ich stattdessen die App Cog.
  • Ich habe selbst eine Web-App entwickelt, mit der ich ganze Alben hören und beim Gerätewechsel an der unterbrochenen Stelle weitermachen kann. Wenn man ein Album von Anfang bis Ende hört, merken sich Dienste wie YouTube Music die Position oft nicht ordentlich, und der Gerätewechsel ist umständlich. In meiner Web-App reicht es, eine URL einzufügen; dann lädt yt-dlp sie auf den Server herunter und man kann sie von dort streamen. Die App merkt sich immer die Wiedergabeposition, sodass ich die Stelle aus dem Auto nahtlos am Arbeitslaptop fortsetzen kann. Auch das Hinzufügen von Mixes aus anderen Quellen wie NTS Radio funktioniert sehr gut.
    • Stimme völlig zu, dass YouTube Music weder Queues speichert noch einen nahtlosen Wechsel zwischen Geräten hinbekommt. Ich würde die Web-App des Entwicklers gern einmal selbst ausprobieren.
  • Ich wünschte, der Artikel hätte nicht nur über physische Geräte gesprochen, sondern auch über die Software zum Verwalten und Abspielen. Vor ein paar Jahren wollte ich meinem zehnjährigen Sohn einen MP3-Player kaufen und war schockiert, wie wenig Geeignetes es gab. Apple hat mit dem Ende des iPods eine große Lücke hinterlassen, aber bisher hat sie niemand wirklich geschlossen. Der iPod shuffle in USB-Stick-Form war der beste MP3-Player, den ich je hatte: klein, direkt einsteckbar und mit langer Akkulaufzeit. Dass er keinen Bildschirm hatte und nur Shuffle konnte, war eher ein Vorteil. Solch einfache Geräte werden heute im Hardwaremarkt nicht mehr nachgebaut. Manche sehen darin ein Software-/DRM-Problem, aber ich finde es einfach schade und wünschte, es gäbe wieder günstige, portable Geräte, die einfach nur Musik abspielen.
    • Ich glaube, der Hauptgrund ist nicht das Verschwinden des iPods, sondern die Verbreitung von Spotify und Smartphones. Diese beiden haben den Großteil des Marktes besetzt und alle anderen Optionen verdrängt.
    • Fiio bringt in dieser Kategorie mehrere Produkte heraus, nur als Hinweis: Beispiel 1 Beispiel 2
    • Ich denke, es ist weder ein Hardware- noch ein Softwareproblem, sondern ein Nachfrageproblem. Chinesische Hersteller verkaufen Mini-Geräte mit Smartphone-Funktionen und Musikwiedergabe für 50 bis 100 Dollar, gewissermaßen wie ein Mini iPhone 16 oder Mini S24. Die meisten Eltern kaufen ihren Kindern eher so etwas als einen MP3-Player, und es gibt nicht viele Eltern, die bis zum 14. Lebensjahr gar kein Handy geben wollen. Entsprechend bildet sich die Marktnachfrage.
    • Sony bringt unter der Marke "walkman" immer noch gute Player heraus: offizieller Link. Für ein zehnjähriges Kind sind sie vielleicht etwas teuer, daher wäre gebraucht bei eBay eine Option.
    • Allein die Erwähnung eines MP3-Players wie des SanDisk Clip hat nostalgische Erinnerungen geweckt — irgendwo im Haus müsste noch einer herumliegen.
  • Ich lese den Artikel mit Vergnügen und bin noch nicht ganz durch. Besonders gefällt mir, über die kleinen, feinen Entscheidungen des Entwicklers und ihre Hintergründe zu lesen. Fast alle Musik-Apps sehen bei UX und Layout ähnlich aus, und ich habe immer das Gefühl, mit all diesen Musik-Apps zu "boxen". Deshalb viel Zuspruch an Leute, die neue Wege ausprobieren.
  • Ich nutze in der Apple-Music-App immer noch ausschließlich lokale Dateien. Den Apple-Music-Streamingdienst habe ich deaktiviert, alle Musik in die Apple-Music-App unter macOS geladen und synchronisiere mein Handy per Kabel mit dem Laptop wie 2007. Da sich meine Musiksammlung nicht oft ändert, funktioniert das für mich problemlos, und gleichzeitig steckt darin eine gewisse Nostalgie.
    • Auch die automatische Wi-Fi-Synchronisierung über iTunes funktioniert weiterhin gut.
  • Zur Frage, warum ein "innovatives IT-Unternehmen der demokratischen App-Entwicklung eher Hindernisse in den Weg legt": Mit einem Zitat des früheren Disney-CEO Michael Eisner lässt sich das gut erklären — Unternehmen streben letztlich nach Profit. Apple ist kein innovatives oder demokratisches Unternehmen, sondern gewinnorientiert. Solange eine niedrigere Eintrittshürde für Entwickler oder mehr demokratische Offenheit keinen höheren Gewinn verspricht, würde Apple damit nur die goldene Gans des offiziellen Stores opfern. Am Ende zählt der Profit.
  • Android-Nutzern mit einer Offline-Musikbibliothek kann ich Musicolet sehr empfehlen. Es funktioniert perfekt.
    • Auch Symfonium ist hervorragend, mit breiter Unterstützung für Plex, Jellyfin, WebDAV, SMB und mehr.
  • Die tiefgehende technische Analyse hat Spaß gemacht. Beim Wechsel von React Native zu SwiftUI merkt man wirklich, wie viel einfacher nativer Code den Zugriff auf iCloud und die Optimierung macht. Auch die SQLite-FTS5-Suchtricks fand ich beeindruckend und möchte sie für meine eigene Bibliotheks-App im Hinterkopf behalten.
  • Ich habe Swift anfangs gemieden, weil ich es schwierig fand, aber ich stimme nicht zu, dass mit der Einführung von async/await das Schreiben von nebenläufigem Code leichter geworden sei. async macht das Schreiben zwar bequemer, aber mit wachsender Größe wird es viel schwieriger, den Codefluss und die Nebenläufigkeit zu überblicken. Wenn Probleme ungelöst bleiben, gibt es aus meiner Sicht Alternativen wie green lightweight threads. Langfristig könnte ein async-basierter Ansatz die Wartungskosten sogar erhöhen.
    • Ich glaube, das Problem liegt weniger im Konzept der Nebenläufigkeit selbst als in den Grenzen der async/await-Abstraktion. Gute Nebenläufigkeit sollte Code beim Skalieren leichter verständlich und besser beherrschbar machen, und eine auf Prozesse/Services ausgerichtete Kapselung hat dabei große Vorteile.
    • Für den Zweck eines einfachen Musikplayers dürfte die zusätzliche Komplexität durch async allerdings kaum ins Gewicht fallen.