मैंने खुद बनाया हुआ ऑडियो प्लेयर

• 2025 में भी iPhone पर MP3 संगीत को आज़ादी से चलाने पर कई सीमाएँ हैं
• Apple और third-party apps ज़्यादातर paid services हैं या user convenience के मामले में कमज़ोर हैं
• खुद बनाए गए app में full-text search, iCloud support, local-first environment जैसी सुविधाएँ हैं
• React Native जैसी cross-platform approach में file system restrictions और stability issues की वजह से सीमाएँ थीं
• SwiftUI और SQLite-आधारित design के साथ स्वतंत्र और highly extensible music management अनुभव बनाया गया

---

अवलोकन

2025 में भी iPhone पर उपयोगकर्ता के अपने MP3 files को स्वतंत्र रूप से चलाना मुश्किल है। इसी असुविधा को सीधे हल करने के लिए डेवलपर ने खुद एक music player app बनाया, और यह लेख उसी प्रक्रिया और उसके परिणाम को बताता है। Apple की music services और बाहरी apps, दोनों में तरह-तरह की सीमाएँ और paid models हैं, जबकि खुद बनाए गए app में user music files के management और playback के लिए optimized experience दिया गया है।

खुद music player बनाने की वजह

• Apple Music और iCloud Music Library जैसे cloud-based sync features केवल paid subscription services में काम करते हैं
• subscription बंद होते ही automatic sync और music folders access पूरी तरह बंद हो जाता है
• मौजूदा music library integration और general device usability में owner rights की कमी महसूस हुई
• "जो feature मेरे लिए ज़रूरी है, उसे खरीदे गए smartphone पर मैं खुद भी बना सकता हूँ" — इस self-determination को साकार करना उद्देश्य था

Apple और third-party music playback solutions का विश्लेषण

Apple का default app

• Files app से iCloud folder के music files चलाए जा सकते हैं, लेकिन playlist management, metadata sorting, queue handling जैसी बुनियादी सुविधाएँ बहुत कमज़ोर हैं
• यह music listening के लिए optimized user experience नहीं देता

Third-party apps

• App Store में कई बाहरी apps हैं, लेकिन उनमें subscription-based billing models बहुत आम हैं और हर app का feature level अलग है
• Doppler जैसे कुछ paid one-time purchase apps भी हैं, लेकिन बड़े iCloud folders में search और import experience पर्याप्त रूप से smooth नहीं है

“Builder mode” की ओर तकनीकी यात्रा

• खुद music player app बनाने का फैसला किया गया
• ज़रूरी features: पूरे iCloud folder पर fast full-text search, official music app के स्तर के music management features (queue, playlist, sorting आदि) और intuitive interface

React Native के साथ पहली कोशिश

• Swift के पिछले अनुभव में असुविधा (जैसे पहले async/await का support न होना) की वजह से React Native/Expo को प्राथमिकता दी गई
• open source templates की मदद से UI बनाना आसान रहा, लेकिन file system (iCloud folder) access और sync handling में app crashes और functional limitations सामने आईं
• iOS sandbox policy के कारण explicit permission के बिना external folders access नहीं किया जा सकता — यह समझ आने पर Swift पर switch किया गया

SwiftUI चुनने की वजह

• SwiftUI के declarative UI paradigm, modern async/await, और Swift Actor support का उपयोग किया गया
• UI और data logic को सख्ती से अलग रखकर साफ data flow और domain concurrency handling लागू की गई
• LLMs (OpenAI o1, DeepSeek आदि) के उपयोग को optimize करने में मदद मिली, और generated UI code की dependencies भी कम रहीं

App architecture और data model

• data store के रूप में SQLite का उपयोग किया गया; full-text search (FTS5) तुरंत उपलब्ध होने के कारण CoreData की जगह इसे चुना गया

• app के 3 मुख्य screens/modes:

  1. Library import: iCloud folders के audio file paths को bulk में DB में store करना, ताकि flexible search/management हो सके
  2. Library management: playlists, song categorization, editing आदि
  3. Music playback: queue management (repeat, shuffle आदि) और बुनियादी song controls

• library import के दौरान user flow:

  • शुरुआती empty state में "Add iCloud Source" से folder चुना जाता है और tree scan किया जाता है
  • indexing पूरी होने पर library tab में ले जाया जाता है, जहाँ keyword-based lists और mini player मिलता है
  • नए songs जुड़ने पर वे background में automatically merge हो जाते हैं

Backend-style logic layer

• web/cloud startup development experience के आधार पर logic layer और UI/ViewModel को सख्ती से अलग किया गया
• domain layer (Swift actors) में मुख्य business logic (import, search, queue आदि) रखा गया, जिससे thread safety सुनिश्चित हुई
• UI updates को ViewModel के माध्यम से साफ तौर पर विभाजित किया गया, जिससे file sync, playback और UI के बीच dependencies कम हुईं और maintainability बेहतर हुई

SQLite के साथ full-text search लागू करना

• iOS 11 और उसके बाद से बिना अलग configuration के FTS5-supported SQLite इस्तेमाल किया जा सकता है
• बाहरी search index या server के बिना fast search उपलब्ध है
• सामान्य queries के लिए SQLite.swift library का उपयोग किया गया, जबकि FTS queries के लिए direct SQL statements लिखे गए

FTS table structure

• songs_fts: songs के artist, title, album, albumArtist आदि को index करता है
• source_paths_fts: file paths और file names को index करता है
• ये main tables के साथ-साथ मौजूद रहते हैं और UI में केवल search (READ) purpose के लिए इस्तेमाल होते हैं
• index updates DB transactions से किए जाते हैं ताकि data consistency बनी रहे

Fuzzy search और ranking

• input value के अंत में wildcard अपने-आप जोड़ा जाता है, और BM25-आधारित relevance order में sorting होती है
• कुल मिलाकर, network dependency के बिना predictable data structure और शक्तिशाली local search environment हासिल किया गया

iOS file system और bookmarks का उपयोग

• macOS के विपरीत iOS में security-scoped bookmarks support नहीं है, इसलिए external file access persistence कमज़ोर है
• सिर्फ path information store होती है, इसलिए दोबारा access पर user को permission फिर से देनी पड़ती है
• समाधान: access की अनुमति मिलने पर file को app sandbox में copy करके store किया गया
• background में automatic copy के ज़रिए file indexing speed बेहतर हुई
• device reboot के बाद external files को सीधे चलाना अब भी कठिन है, और इससे iOS की file access restrictions की गंभीरता साफ दिखती है

AVFoundation-आधारित playback और interface design

• audio file metadata analysis के लिए AVFoundation framework और AVURLAsset का उपयोग किया गया
• track number जैसे कुछ fields को manually parse किया गया (ID3 tags का उपयोग करके)
• audio playback के लिए AVAudioPlayer इस्तेमाल किया गया, और Control Center integration के लिए MPRemoteCommandCenter और Delegate protocols लागू किए गए

विकास के बाद के विचार और Apple policies पर नजर

क्या असुविधाजनक रहा

• Xcode का restrictive environment: SwiftUI live preview में सुधार हुआ है, लेकिन VSCode या Flutter जैसी सुविधा अभी नहीं मिलती
• editor flexibility की कमी: Neovim या VSCode में Swift LSP इस्तेमाल करने के लिए अतिरिक्त setup चाहिए और वह भी पूरी तरह polished नहीं है
• SDK के कुछ हिस्से अब भी Objective-C केंद्रित हैं: metadata search जैसी जगहों पर modern Swift-friendly APIs की कमी महसूस हुई
• iCloud integration debugging झंझटभरी है: SwiftUI preview में cloud features पूरी तरह लागू नहीं किए जा सकते, इसलिए direct mock setup बनाना पड़ता है

क्या अच्छा लगा

• Async/await की मदद से I/O-bound concurrency code लिखना काफ़ी आसान हो गया
• समृद्ध native libraries: open source bindings की सीमाओं से बाहर निकलकर ज्यादा विविध features बनाए जा सकते हैं
• SwiftUI का declarative UI design: React-style strengths और high productivity दोनों का अनुभव मिला

निष्कर्ष: क्या development और आसान नहीं होना चाहिए?

• 1.5 हफ्ते के development में local/offline music player का लक्ष्य हासिल कर लिया गया
• व्यवहार में app distribution पर भी restrictions हैं: developer certificate के बिना 7 दिन बाद app चलना बंद हो जाता है, और सालाना $99 developer registration चाहिए
• EU DMA Act के बाद भी sideloading पूरी तरह खुला नहीं है, इसलिए व्यक्तिगत और hobby developers के लिए सीमाएँ बनी हुई हैं
• PWAs भी iOS पर सीमित हैं: कई प्रमुख APIs supported नहीं हैं (Web Bluetooth/USB/NFC, Background Sync आदि)
• AI ने development barriers कम किए हैं, लेकिन iOS अब भी artificial rules की वजह से entry barrier ऊँचा रखता है
• independent developers और user rights पर restrictions अब भी कायम हैं, और iOS की closed nature आज भी innovation में बाधा है

[GN⁺]

Hacker News राय

• 25 साल से FLAC फ़ॉर्मैट में अपना म्यूज़िक कलेक्शन बना रहा हूँ, पिछले साल Android फ़ोन और 1TB MicroSD कार्ड खरीदा और इससे बहुत संतोष मिला कि अब अपना पूरा संगीत जेब में रख सकता हूँ, जो लोग संगीत किराये पर नहीं लेना चाहते, नियंत्रण नहीं खोना चाहते, इंडस्ट्री द्वारा धकेले जा रहे गाने स्ट्रीम नहीं करना चाहते या विज्ञापनों से नहीं जूझना चाहते, वे निश्चित ही सिर्फ मैं अकेला नहीं हूँ, और ऐसे लोगों को खुद ऐप्लिकेशन बनाते देखना बहुत शानदार लगता है
  • मेरा मानना है कि टेक्नोलॉजी तो कई साल पहले ही वहाँ पहुँच चुकी थी, बस मैं ही ऐसे फ़ॉर्मैट पर अड़ा हूँ जो मेरे लिए उपयुक्त नहीं है, अच्छी re-encoding का इस्तेमाल करें तो पूरी म्यूज़िक लाइब्रेरी को बहुत कम जगह में रखा जा सकता है और साउंड क्वालिटी इतनी transparent रहती है कि फर्क महसूस नहीं होगा, डेस्कटॉप पर FLAC फ़ाइलें बैकअप के लिए रखना बेहतर है
  • आप वाकई बहुत अच्छे संग्राहक हैं, मेरे अपने कलेक्शन में FLAC/APE/ALAC/WavePack जैसे lossless फ़ॉर्मैट लगभग 25% हैं और कुल आकार 3TB से ज़्यादा है, इसलिए चलते-फिरते संगीत सुनना मुश्किल हो जाता है — पहले से तय करना कठिन होता है कि मोबाइल डिवाइस में कौन-सा संगीत ले जाऊँ
  • Android पर मुझे लगातार यह समस्या होती है कि album cover या title जानकारी सही तरह से नहीं दिखती या रैंडम तरीके से बदल जाती है, यह Android bug जैसा लगता है, क्या किसी ने इसका समाधान देखा है?
  • मैं भी सिर्फ FLAC में अपना निजी कलेक्शन बना रहा हूँ, हालांकि अभी 25 साल नहीं हुए, यह 1TB से ऊपर जा चुका है, और Navidrome server तथा Symfonium client के साथ मैं बहुत संतुष्ट हूँ, आजकल 2TB microSD कार्ड आने लगे हैं, कीमत थोड़ी और गिरे तो शायद मैं भी एक ले लूँ
• मैं पुराने winamp दिनों से संगीत सुनता आया हूँ, और आज भी streaming के दौर में अपनी local music library को फ़ोल्डर के हिसाब से व्यवस्थित करके इस्तेमाल करता हूँ, यहाँ दूसरे commenters की तरह मैंने भी offline music listening के लिए शौकिया तौर पर एक old-school music player बनाया है, यह एक single-page html/js app है और इसमें पूरा keyboard control तथा साधारण queue (playlist) फीचर है, https://nobsutils.com/mp देख सकते हैं
  • मैं भी उन लोगों में हूँ जिन्हें 27 साल पहले से winamp UI सचमुच बेहतरीन लगता था, फ़ोल्डर-आधारित फ़ाइल संग्रह, full random play, और सिर्फ किसी खास directory को चलाने की सादगी ही इसकी सबसे बड़ी ताकत है
  • आपके बनाए ऐप पर प्रतिक्रिया: यह सचमुच बहुत अच्छा काम करता है
  • मेरे लिए foobar2000 सबसे पसंदीदा music player था, अब उसकी जगह Cog app इस्तेमाल करता हूँ
• मैंने खुद एक web app बनाया है जिसमें पूरे album सुनते हुए डिवाइस बदलने पर भी जहाँ छोड़ा था वहीं से आगे सुन सकता हूँ, लेकिन YouTube Music जैसी सेवाएँ playback position ठीक से याद नहीं रख पातीं या डिवाइस बदलना असुविधाजनक बनाती हैं, मेरे web app में बस URL paste करना होता है, फिर वह yt-dlp से server पर डाउनलोड हो जाता है और वहीं से stream किया जा सकता है, यह हमेशा playback position याद रखता है, इसलिए कार में जहाँ सुनना छोड़ा था वहीं से ऑफिस के laptop पर जारी रख सकता हूँ, और NTS Radio जैसे दूसरे source mix जोड़ना भी बहुत बढ़िया काम करता है
  • YouTube Music में queue save न होने और डिवाइसों के बीच सहज switch न हो पाने की बात से सहमत हूँ, developer का यह web app मैं खुद एक बार ज़रूर आज़माना चाहूँगा
• काश लेख में सिर्फ physical device ही नहीं बल्कि उन्हें manage और play करने वाले software की भी चर्चा होती, कुछ साल पहले मैं अपने 10 साल के बेटे के लिए mp3 player खरीदना चाहता था और यह देखकर हैरान रह गया कि उपयुक्त उत्पाद लगभग थे ही नहीं, Apple ने iPod बंद करके बाज़ार में एक बड़ी खाली जगह छोड़ दी लेकिन अभी तक किसी ने उसे ठीक से नहीं भरा, iPod shuffle (USB stick जैसा रूप) मेरे इस्तेमाल का सबसे अच्छा mp3 player था — छोटा, plug-in, और लंबी battery life वाला, बिना स्क्रीन के सिर्फ shuffle वाला उसका concept भी मेरे लिए उल्टा एक फ़ायदा था, लेकिन आज ऐसा simple device hardware market में दोबारा नहीं दिखता, कुछ लोग इसे software/DRM समस्या मानते हैं, पर मुझे अफ़सोस है और इच्छा है कि ऐसा सस्ता और portable device हो जो सिर्फ संगीत चलाए
  • मेरे हिसाब से मुख्य बदलाव का कारण iPod का गायब होना नहीं, बल्कि Spotify और smartphones का प्रसार है, इन्हीं दोनों ने बाज़ार का ज़्यादातर हिस्सा ले लिया और बाकी सारे विकल्पों को हटा दिया
  • जानकारी के लिए, Fiio इस category में कई products बेच रहा है, उदाहरण1 उदाहरण2
  • मुझे यह hardware या software की नहीं बल्कि demand की समस्या लगती है, Chinese manufacturers Mini iPhone 16, Mini S24 जैसे छोटे devices $50~$100 में बेच रहे हैं जिनमें smartphone जैसी क्षमताएँ हैं और music playback भी हो जाता है, ज़्यादातर parents अपने बच्चों के लिए mp3 player के बजाय ऐसे device खरीदने की ज़्यादा संभावना रखते हैं, और 14 साल की उम्र तक फ़ोन न देने वाले parents बहुत कम हैं, इसलिए बाज़ार की demand उसी अनुसार बनी है
  • Sony अभी भी "walkman" brand के तहत अच्छे players निकाल रहा है, official link लेकिन 10 साल के बच्चे के लिए यह थोड़ा महंगा हो सकता है, इसलिए eBay पर used खरीदना बेहतर हो सकता है
  • SanDisk Clip जैसे mp3 player की याद अचानक ताज़ा हो गई — शायद घर में कहीं अब भी पड़ा हो
• यह लेख पढ़कर मज़ा आया, अभी पूरा नहीं पढ़ा है, लेकिन developer के छोटे-छोटे और सूक्ष्म फ़ैसले कैसे बनते हैं और उनके पीछे क्या सोच होती है, यह पढ़ना बहुत अच्छा लगा, लगभग हर music app का UX और layout मुझे एक जैसा लगता है इसलिए मुझे हमेशा ऐसा महसूस होता है जैसे मैं इन सभी music apps के साथ 'मुक्केबाज़ी' कर रहा हूँ, जो लोग कुछ नया करने की कोशिश कर रहे हैं उन्हें मेरा समर्थन
• मैं आज भी Apple Music app में सिर्फ local files ही इस्तेमाल करता हूँ, Apple Music streaming service बंद रखता हूँ, macOS के Apple Music app में अपनी सारी audio files लोड करता हूँ, फिर फ़ोन को laptop से जोड़कर 2007 की तरह sync करता हूँ, मेरा संगीत बहुत बार नहीं बदलता इसलिए यह तरीका मेरे लिए ठीक है, और wired sync से एक तरह की nostalgia भी मिलती है
  • iTunes के जरिए automatic wi-fi sync अब भी अच्छी तरह काम करता है
• "आख़िर innovative IT companies democratic application development में बाधाएँ क्यों डालती हैं" इस सवाल पर, Disney के पूर्व CEO Michael Eisner का हवाला देकर कहा गया कि आख़िरकार कंपनियों का स्वभाव मुनाफ़ा कमाना है, Apple कोई innovative या democratic company नहीं बल्कि profit-seeking company है, जब तक ज़्यादा revenue की गारंटी न हो, developers के लिए barriers कम करना या लोकतांत्रिक openness देना उसके official store नाम की 'सोने के अंडे देने वाली मुर्गी' की कमाई छोड़ने जैसा है — यानी लाभ को सर्वोच्च रखने का तर्क
• offline music library रखने वाले Android users के लिए Musicolet की ज़ोरदार सिफारिश, यह बिल्कुल सही काम करता है
  • Plex, Jellyfin, WebDAV, SMB आदि के व्यापक support वाला Symfonium भी बेहद शानदार है
• यह गहरा technical analysis पढ़कर बहुत अच्छा लगा, React Native से SwiftUI पर जाते हुए साफ़ महसूस हुआ कि native code में iCloud access और optimization कितने आसान हो जाते हैं, SQLite FTS5 search trick भी प्रभावशाली लगी और मैं इसे अपनी library app में अपनाने का सोच रहा हूँ
• मैंने भी शुरुआत में Swift से इसलिए दूरी बनाई क्योंकि वह कठिन लगा, लेकिन बाद में async/await जुड़ने से concurrency code लिखना आसान हो गया — इस दावे से मैं सहमत नहीं हूँ, async लिखते समय सुविधा देता है, लेकिन system बड़ा होने पर code flow और concurrency को समझना कहीं ज़्यादा मुश्किल हो जाता है, जब समस्या अनसुलझी हो तो green lightweight threads जैसे विकल्प बेहतर लगते हैं, और लंबे समय में async-आधारित तरीका maintenance cost बढ़ा सकता है, यह चिंता है
  • मुझे लगता है समस्या concurrency concept में कम और async/await abstraction की सीमाओं में ज़्यादा है, अच्छी concurrency ऐसी होनी चाहिए कि code scale होने पर उसे समझना और manage करना आसान हो, और process/service-केंद्रित encapsulation यहाँ बड़ा लाभ देता है
  • अगर मकसद सिर्फ एक simple music player बनाना है, तो async से बढ़ने वाली complexity शायद लगभग कोई समस्या नहीं बनेगी