เครื่องเล่นเสียงที่ฉันสร้างขึ้นเอง

• แม้ในปี 2025 ก็ยังมีข้อจำกัดมากในการ เล่นเพลง MP3 บน iPhone ได้อย่างอิสระ
• แอปของ Apple และแอปจากผู้พัฒนาภายนอก ส่วนใหญ่เป็นบริการแบบเสียเงินหรือใช้งานไม่สะดวกนัก
• แอปที่สร้างเองมี การค้นหาแบบข้อความเต็ม, รองรับ iCloud และ สภาพแวดล้อมที่เน้นการทำงานแบบ local ก่อน
• แนวทางแบบ cross-platform อย่าง React Native มีข้อจำกัดจากระบบไฟล์และปัญหาด้านเสถียรภาพ
• ด้วย SwiftUI และสถาปัตยกรรมบน SQLite จึงสร้างประสบการณ์ จัดการเพลงที่เป็นอิสระและขยายต่อได้สูง

---

ภาพรวม

บทความนี้แนะนำทั้งกระบวนการและผลลัพธ์ของการที่ผู้พัฒนาสร้างแอปเครื่องเล่นเพลงขึ้นมาเอง เพื่อแก้ปัญหาความ ไม่สะดวก ที่แม้แต่ในปี 2025 ผู้ใช้ก็ยังเล่นไฟล์ MP3 ที่ตนเป็นเจ้าของบน iPhone ได้อย่างอิสระยากอยู่ดี ขณะที่ทั้งบริการเพลงของ Apple และแอปภายนอกต่างก็มีข้อจำกัดและโมเดลเก็บเงินหลายแบบ แอปที่สร้างขึ้นเองกลับมอบ ประสบการณ์ที่เหมาะกับการจัดการและเล่นไฟล์เพลงของผู้ใช้โดยเฉพาะ

เหตุผลที่สร้างเครื่องเล่นเพลงขึ้นมาเอง

• ฟังก์ชันซิงก์บนคลาวด์อย่าง Apple Music และ iCloud Music Library จะใช้งานได้ก็ต่อเมื่อสมัคร บริการแบบเสียเงิน
• หากยกเลิกการสมัคร การซิงก์อัตโนมัติและการเข้าถึงโฟลเดอร์เพลง จะถูกปิดกั้นทั้งหมด
• ทำให้รู้สึกได้ถึงการขาด สิทธิ์ความเป็นเจ้าของ ในการผสานคลังเพลงเดิมและใช้งานข้ามอุปกรณ์ทั่วไป
• ต้องการทำให้เกิด การตัดสินใจด้วยตนเอง ตามแนวคิดว่า “เมื่อซื้อสมาร์ตโฟนมาแล้ว ฟังก์ชันที่จำเป็นจริง ๆ ก็ควรสร้างใช้เองได้”

วิเคราะห์โซลูชันเล่นเพลงของ Apple และผู้ให้บริการรายอื่น

แอปพื้นฐานของ Apple

• แม้จะใช้แอป Files เล่นไฟล์เพลงจากโฟลเดอร์ iCloud ได้ แต่ฟังก์ชันพื้นฐานอย่าง การจัดการเพลย์ลิสต์ การเรียงข้อมูลเมตา และการจัดการคิว ยังอ่อนมาก
• มอบ ประสบการณ์ผู้ใช้ที่ไม่ได้ออกแบบมาเพื่อการฟังเพลงโดยเฉพาะ

แอปจากผู้พัฒนาภายนอก

• ใน App Store มีแอปภายนอกหลากหลาย แต่จำนวนมากใช้ โมเดลเก็บเงินแบบสมัครสมาชิก และความสามารถของแต่ละแอปก็แตกต่างกันมาก
• แม้จะมีแอปเสียเงินแบบซื้อขาดบางตัว เช่น Doppler แต่ ประสบการณ์การค้นหาและนำเข้าข้อมูล จากโฟลเดอร์ iCloud ขนาดใหญ่ก็ยังไม่ลื่นไหลนัก

เส้นทางทางเทคนิคสู่ “โหมดผู้สร้าง”

• ตัดสินใจว่าต้องสร้างแอปเครื่องเล่นเพลงขึ้นมาเอง
• ฟังก์ชันที่ต้องการ: การค้นหาแบบข้อความเต็มที่รวดเร็วทั่วทั้งโฟลเดอร์ iCloud, ความสามารถจัดการเพลง ระดับแอปเพลงทางการ (คิว เพลย์ลิสต์ การเรียงลำดับ ฯลฯ) และ อินเทอร์เฟซที่เข้าใจง่าย

ความพยายามครั้งแรกด้วย React Native

• เนื่องจากเคยรู้สึกไม่สะดวกกับการใช้ Swift มาก่อน (เช่น ในอดีตยังไม่รองรับ async/await) จึงเอนเอียงไปทาง React Native/Expo
• การทำ UI ค่อนข้างราบรื่นด้วยการใช้เทมเพลตโอเพนซอร์ส แต่เมื่อจัดการ การเข้าถึงระบบไฟล์ (โฟลเดอร์ iCloud) และการซิงก์ ก็พบทั้งแอปแครชและข้อจำกัดด้านฟังก์ชัน
• เมื่อเข้าใจว่านโยบาย sandbox ของ iOS ไม่อนุญาตให้เข้าถึงโฟลเดอร์ภายนอกโดยไม่มีสิทธิ์อย่างชัดเจน จึง เปลี่ยนไปใช้ Swift

การเลือก SwiftUI และเหตุผล

• ใช้ประโยชน์จาก กระบวนทัศน์ UI แบบ declarative ของ SwiftUI รวมถึง async/await และ Swift Actor แบบสมัยใหม่
• แยก UI ออกจากตรรกะข้อมูลอย่างเด็ดขาด เพื่อสร้าง data flow ที่สะอาดและการจัดการ concurrency ในระดับโดเมน
• ยังช่วยให้ใช้ LLM (เช่น OpenAI o1, DeepSeek) ได้อย่างเหมาะสม และลดการพึ่งพาของโค้ด UI ที่สร้างขึ้น

สถาปัตยกรรมแอปและโมเดลข้อมูล

• ใช้ SQLite เป็นที่เก็บข้อมูล และเลือกแทน CoreData เพราะสามารถใช้ การค้นหาแบบข้อความเต็ม (FTS5) ได้ทันที

• แอปมี 3 หน้าจอ/โหมดหลัก:

  1. นำเข้าคลังเพลง: บันทึกพาธไฟล์เสียงจากแต่ละโฟลเดอร์ iCloud ลง DB แบบชุดเดียว เพื่อรองรับการค้นหา/จัดการที่ยืดหยุ่น
  2. จัดการคลังเพลง: เพลย์ลิสต์ การจัดหมวดหมู่เพลง การแก้ไข ฯลฯ
  3. เล่นเพลง: จัดการคิว (เล่นซ้ำ สุ่มเพลง ฯลฯ) และการควบคุมเพลงพื้นฐาน

• ลำดับการใช้งานของผู้ใช้เมื่อ import คลังเพลง:

  • จากสถานะเริ่มต้นที่ว่าง เลือกโฟลเดอร์และสแกนโครงสร้างผ่าน "Add iCloud Source"
  • เมื่อทำดัชนีเสร็จ จะย้ายไปยังแท็บไลบรารี พร้อมลิสต์ตามคีย์เวิร์ดและมินิเพลเยอร์
  • เมื่อมีการเพิ่มเพลงใหม่ ระบบจะรวมเข้ามาให้อัตโนมัติในเบื้องหลัง

ชั้นตรรกะแบบสไตล์แบ็กเอนด์

• อิงจากประสบการณ์พัฒนาเว็บ/สตาร์ตอัปสายคลาวด์ จึงแยกชั้นตรรกะออกจาก UI/ViewModel อย่างชัดเจน
• ชั้นโดเมน (Swift actors) รับผิดชอบตรรกะธุรกิจหลัก (import, search, queue ฯลฯ) เพื่อให้ได้ ความปลอดภัยด้านเธรด
• การอัปเดต UI ถูกแยกอย่างเป็นระเบียบผ่าน ViewModel และลดการพึ่งพากันระหว่างการซิงก์ไฟล์ การเล่นเพลง และ UI เพื่อให้ดูแลรักษาได้ง่ายขึ้น

การทำ Full-text search ด้วย SQLite

• ตั้งแต่ iOS 11 ขึ้นไป สามารถใช้ SQLite ที่รองรับ FTS5 ได้โดยไม่ต้องตั้งค่าเพิ่ม
• รองรับ การค้นหาที่รวดเร็วโดยไม่ต้องมีดัชนีค้นหาภายนอกหรือเซิร์ฟเวอร์
• ใช้ไลบรารี SQLite.swift สำหรับ query ทั่วไป และใช้คำสั่ง SQL โดยตรงสำหรับ FTS query

โครงสร้างตาราง FTS

• songs_fts: ทำดัชนี artist, title, album, albumArtist ของเพลง
• source_paths_fts: ทำดัชนีพาธไฟล์และชื่อไฟล์
• อยู่คู่กับตารางหลัก และใน UI ใช้สำหรับ การค้นหา (READ) เท่านั้น
• การอัปเดตดัชนีจัดการผ่าน DB transaction เพื่อ รักษาความสอดคล้องของข้อมูล

การค้นหาแบบ Fuzzy และการจัดอันดับ

• เติม wildcard อัตโนมัติ ต่อท้ายค่าที่ป้อนเข้า และจัดเรียงตาม ความเกี่ยวข้องด้วย BM25
• โดยรวมแล้วทำให้เกิดทั้ง โครงสร้างข้อมูลที่คาดเดาได้โดยไม่พึ่งพาเครือข่าย และสภาพแวดล้อมการค้นหาแบบ local ที่ทรงพลัง

ระบบไฟล์ของ iOS และการใช้ Bookmarks

• iOS ต่างจาก macOS ตรงที่ไม่รองรับ security-scoped bookmarks จึงขาดความต่อเนื่องในการเข้าถึงไฟล์ภายนอกแบบขยายสิทธิ์
• มีเพียงข้อมูลพาธที่ถูกบันทึกไว้ และเมื่อจะเข้าถึงอีกครั้งผู้ใช้ต้องอนุมัติสิทธิ์ใหม่
• วิธีแก้คือ: เมื่ออนุญาตให้เข้าถึงแล้ว ให้ คัดลอกไฟล์นั้นมาเก็บไว้ใน sandbox ของแอป
• คัดลอกอัตโนมัติในเบื้องหลังเพื่อเพิ่มความเร็วในการทำดัชนีไฟล์
• แม้หลังรีบูตเครื่องก็ยังเล่นไฟล์ภายนอกโดยตรงได้ยาก แต่สิ่งนี้สะท้อนว่า ข้อจำกัดการเข้าถึงไฟล์ของ iOS นั้นรุนแรงมาก

การเล่นเพลงด้วย AVFoundation และการออกแบบอินเทอร์เฟซ

• ใช้ เฟรมเวิร์ก AVFoundation และ AVURLAsset เพื่อวิเคราะห์ metadata ของไฟล์เสียง
• ฟิลด์บางส่วน เช่น track number ต้อง parse เองด้วยมือ (อาศัย ID3 tag)
• สำหรับการเล่นเสียงใช้ AVAudioPlayer และเพื่อเชื่อมกับ Control Center จึงมีการ implement MPRemoteCommandCenter และ Delegate protocol

สิ่งที่รู้สึกหลังพัฒนา และข้อคิดต่อแนวนโยบายของ Apple

สิ่งที่ไม่สะดวก

• สภาพแวดล้อมที่จำกัดของ Xcode: แม้ SwiftUI live preview จะพัฒนาไปมาก แต่ยังไม่สะดวกเท่า VSCode หรือ Flutter
• ความยืดหยุ่นของเอดิเตอร์ต่ำ: หากจะใช้ Swift LSP บน Neovim หรือ VSCode ต้องตั้งค่าเพิ่มและคุณภาพยังไม่สมบูรณ์นัก
• บางมุมของ SDK ยังเน้น Objective-C: เช่น งานค้นหา metadata ที่ยังขาด API สมัยใหม่ที่เป็นมิตรกับ Swift
• การดีบัก iCloud ยุ่งยาก: ไม่สามารถทำฟีเจอร์คลาวด์ให้สมบูรณ์ใน SwiftUI preview ได้ ต้องทำ mock ขึ้นมาเองโดยตรง

สิ่งที่เป็นบวก

• Async/await ทำให้การเขียนโค้ด concurrency ที่เป็น I/O-bound ง่ายขึ้นอย่างชัดเจน
• ไลบรารีเนทีฟที่หลากหลาย: หลุดพ้นจากข้อจำกัดของ open-source bindings ทำให้พัฒนาฟังก์ชันได้กว้างขึ้น
• การออกแบบ UI แบบ declarative ของ SwiftUI: สัมผัสได้ถึงข้อดีแบบ React และประสิทธิภาพการพัฒนาที่สูง

บทสรุป: การพัฒนาไม่น่าจะง่ายกว่านี้หรือ

• ใช้เวลา 1.5 สัปดาห์ก็ทำเป้าหมายของ เครื่องเล่นเพลงแบบ local/offline ได้สำเร็จ
• แต่ในความเป็นจริง แม้แต่ การแจกจ่ายตัวแอปเองก็ยังมีข้อจำกัด: หากไม่มี developer certificate จะใช้งานไม่ได้หลัง 7 วัน และต้องสมัครนักพัฒนารายปี $99
• แม้หลัง EU DMA Act ก็ยัง ไม่ได้เปิด sideloading อย่างสมบูรณ์ และข้อจำกัดยังคงอยู่สำหรับนักพัฒนารายบุคคลและสายงานอดิเรก
• PWA บน iOS ก็ยังมีข้อจำกัด เช่น API สำคัญหลายตัวไม่รองรับ (Web Bluetooth/USB/NFC, Background Sync ฯลฯ)
• แม้ AI จะลดกำแพงในการพัฒนา แต่เฉพาะ iOS กลับยังมีข้อกำหนดเชิงประดิษฐ์ที่ทำให้ต้นทุนการเริ่มต้นสูง
• ข้อจำกัดต่อสิทธิ์ของนักพัฒนาอิสระและผู้ใช้ ยังคงอยู่ และความปิดของ iOS ก็ยังเป็นอุปสรรคต่อการสร้างนวัตกรรม

[GN⁺]

ความคิดเห็นจาก Hacker News

• เป็นคนที่สร้างคอลเลกชันเพลงของตัวเองในฟอร์แมต FLAC มาตลอด 25 ปี และพอปีที่แล้วซื้อโทรศัพท์ Android กับการ์ด MicroSD 1TB ก็รู้สึกพอใจมากที่สามารถพกเพลงทั้งหมดใส่กระเป๋าไปได้ คิดว่าคงไม่ได้มีแค่ตัวเองคนเดียวที่ไม่อยากเช่าเพลง ไม่อยากเสียสิทธิ์ควบคุม ไม่อยากสตรีมเพลงที่อุตสาหกรรมดันขึ้นมา หรือคอยรับมือกับโฆษณา พอเห็นคนลงมือพัฒนาแอปเองก็รู้สึกว่าเจ๋งมาก
  • มองว่าเทคโนโลยีพร้อมมาหลายปีแล้ว มีแต่ตัวเองที่ยังยึดติดกับฟอร์แมตที่ไม่เหมาะ หากใช้การ re-encode ที่ดี ก็สามารถเก็บเพลงทั้งหมดในขนาดเล็กลงมากโดยแทบฟังไม่ออกว่าคุณภาพต่างกัน แนะนำให้เก็บไฟล์ FLAC ไว้บนเดสก์ท็อปสำหรับสำรองข้อมูล
  • ขอยกย่องว่าเป็นคนที่สะสมได้จริงจังมาก คอลเลกชันเพลงของตัวเองมีไฟล์แบบ lossless อย่าง FLAC/APE/ALAC/WavePack ราว 25% และขนาดรวมเกิน 3TB แล้ว เลยทำให้ฟังเพลงระหว่างเดินทางลำบาก เพราะเลือกยากว่าจะย้ายเพลงไหนลงอุปกรณ์พกพาล่วงหน้า
  • เจอปัญหาบน Android มาตลอดว่าอัลบั้มคัฟเวอร์หรือข้อมูลชื่อเพลงแสดงไม่ถูกต้อง หรือเปลี่ยนแบบสุ่ม ดูเหมือนเป็นบั๊กของ Android เลยอยากรู้ว่ามีใครเคยแก้ได้ไหม
  • ฉันก็สะสมคอลเลกชันส่วนตัวด้วย FLAC ล้วนเหมือนกัน แม้จะยังไม่ถึง 25 ปี ตอนนี้เกิน 1TB แล้ว และพอใช้เซิร์ฟเวอร์ Navidrome กับไคลเอนต์ Symfonium ก็พอใจมาก ช่วงนี้เริ่มมี microSD 2TB ออกมาแล้ว ถ้าราคาลงอีกหน่อยก็น่าจะซื้อ
• ฟังเพลงมาตั้งแต่ยุค winamp และทุกวันนี้แม้จะอยู่ในยุคสตรีมมิง ก็ยังจัดการคลังเพลงแบบโลคัลเป็นโฟลเดอร์อยู่เหมือนเดิม ฉันเองก็เหมือนคนคอมเมนต์คนอื่น ๆ ที่ทำเครื่องเล่นเพลง old-school ขึ้นมาเองเป็นงานอดิเรกสำหรับฟังเพลงออฟไลน์ เป็นแอป html/js หน้าเดียว มีการควบคุมด้วยคีย์บอร์ดครบ และมีฟังก์ชันคิวอย่างง่าย แนะนำให้ลองดู https://nobsutils.com/mp
  • ฉันก็เป็นอีกคนที่คิดว่า UI ของ winamp เมื่อ 27 ปีก่อนนั้นยอดเยี่ยมจริง ๆ จุดแข็งสำคัญคือความเรียบง่ายของการรวมไฟล์ตามโฟลเดอร์ การสุ่มเล่นทั้งหมด และการเล่นเฉพาะบางไดเรกทอรี
  • มีคนให้ฟีดแบ็กว่าแอปที่ทำเองใช้งานได้ดีมาก
  • สำหรับฉัน foobar2000 คือเครื่องเล่นเพลงที่ชอบที่สุด ตอนนี้เปลี่ยนไปใช้แอป Cog แทน
• ฉันพัฒนาเว็บแอปขึ้นมาเองเพื่อให้ฟังอัลบั้มเต็ม ๆ แล้วสลับอุปกรณ์ไปมาโดยฟังต่อจากจุดที่ค้างไว้ได้ เวลาฟังอัลบั้มตั้งแต่ต้นจนจบ บริการอย่าง YouTube Music มักจำตำแหน่งเล่นไม่ได้ดีพอ หรือสลับอุปกรณ์ได้ไม่สะดวก เว็บแอปที่ฉันทำ แค่แปะ URL ก็ให้ yt-dlp ดาวน์โหลดลงเซิร์ฟเวอร์แล้วสตรีมจากตรงนั้นได้ และมันจำตำแหน่งเล่นไว้เสมอ ทำให้ฟังต่อจากในรถไปยังโน้ตบุ๊กที่ทำงานได้ทันที อีกทั้งยังเพิ่มมิกซ์จากแหล่งอื่นอย่าง NTS Radio ได้ดีมากด้วย
  • เห็นด้วยว่า YouTube Music ไม่สามารถบันทึกคิวและสลับข้ามอุปกรณ์ได้ลื่นไหล เลยอยากลองใช้เว็บแอปที่ผู้พัฒนาทำเองดูสักครั้ง
• อยากให้บทความพูดถึงไม่ใช่แค่อุปกรณ์จริง แต่รวมถึงซอฟต์แวร์ที่ใช้จัดการและเล่นมันด้วย เมื่อไม่กี่ปีก่อนอยากซื้อเครื่องเล่น mp3 ให้ลูกชายวัย 10 ขวบ แต่ตกใจที่แทบไม่มีสินค้าที่เหมาะเลย Apple เลิกผลิต iPod ไปทำให้เกิดช่องว่างใหญ่ในตลาด แต่จนถึงตอนนี้ก็ยังไม่มีใครมาเติมเต็มได้จริง ๆ iPod shuffle (แบบ USB stick) เป็นเครื่องเล่น mp3 ที่ดีที่สุดที่ฉันเคยใช้ เพราะเล็ก เสียบใช้ง่าย และแบตอยู่นาน แนวคิดที่ไม่มีหน้าจอและเล่นแบบสุ่มอย่างเดียวกลับกลายเป็นข้อดีด้วยซ้ำ อุปกรณ์เรียบง่ายแบบนี้ตอนนี้ก็ยังไม่มีใครทำซ้ำในตลาดฮาร์ดแวร์ แม้บางคนจะมองว่าเป็นปัญหาด้านซอฟต์แวร์/DRM แต่ก็ยังน่าเสียดาย และอยากให้มีอุปกรณ์ราคาถูก พกพาง่าย ที่มีไว้เล่นเพลงอย่างเดียว
  • คิดว่าสาเหตุหลักของการเปลี่ยนแปลงไม่ใช่การหายไปของ iPod แต่เป็นการแพร่หลายของ Spotify และสมาร์ตโฟน ซึ่งยึดตลาดส่วนใหญ่ไปและเบียดตัวเลือกอื่น ๆ ออกหมด
  • มีข้อมูลว่า Fiio ยังออกสินค้าหลายรุ่นในหมวดนี้อยู่ ตัวอย่าง1 ตัวอย่าง2
  • คิดว่าไม่ใช่ปัญหาฮาร์ดแวร์หรือซอฟต์แวร์ แต่เป็นเรื่องอุปสงค์ ผู้ผลิตจีนมีอุปกรณ์จิ๋วที่เหมือน Mini iPhone 16 หรือ Mini S24 ซึ่งใส่ฟังก์ชันสมาร์ตโฟนและเล่นเพลงได้ ขายในช่วง $50~$100 ผู้ปกครองส่วนใหญ่น่าจะซื้อของแบบนี้ให้ลูกมากกว่า mp3 player และก็มีพ่อแม่ไม่มากนักที่ตั้งใจจะไม่ให้ลูกมีมือถือจนถึงอายุ 14 ทำให้อุปสงค์ของตลาดเป็นไปตามนั้น
  • Sony ยังทำเครื่องเล่นดี ๆ ออกมาอยู่ภายใต้แบรนด์ "walkman" ลิงก์ทางการ แต่สำหรับเด็กอายุ 10 ขวบอาจจะแพงไปหน่อย เลยแนะนำให้หามือสองจาก eBay
  • แค่นึกถึง mp3 player อย่าง SanDisk Clip ก็ชวนให้ความทรงจำย้อนกลับมา
• อ่านโพสต์นี้อย่างเพลิดเพลิน แม้จะยังอ่านไม่จบก็ตาม ชอบตรงที่ได้อ่านกระบวนการตัดสินใจเล็ก ๆ ละเอียด ๆ ของนักพัฒนาและเบื้องหลังของมัน แอปเพลงแทบทั้งหมดดูมี UX และเลย์เอาต์คล้ายกันไปหมด จนรู้สึกเหมือนต้อง 'ชกมวย' กับแอปเพลงทุกตัวอยู่ตลอด ขอเป็นกำลังใจให้คนที่กล้าลองอะไรใหม่ ๆ
• ฉันยังใช้แค่ไฟล์โลคัลในแอป Apple Music อยู่ ปิดบริการสตรีมมิง Apple Music แล้วโหลดเพลงทั้งหมดเข้าแอป Apple Music บน macOS จากนั้นก็ต่อโทรศัพท์เข้ากับโน้ตบุ๊กแล้วซิงก์เหมือนปี 2007 เพราะเพลงของฉันไม่ได้เปลี่ยนบ่อย วิธีนี้เลยไม่มีปัญหา และยังให้ความรู้สึกคิดถึงการซิงก์ผ่านสายไปพร้อมกัน
  • มีคนเสริมว่าการซิงก์อัตโนมัติผ่าน wi-fi ด้วย iTunes ก็ยังทำงานได้ดีอยู่
• ต่อคำถามที่ว่า "ทำไมบริษัท IT ที่อ้างว่านวัตกรรมถึงกลับสร้างอุปสรรคต่อการพัฒนาแอปแบบเป็นประชาธิปไตย" มีการยกคำพูดของ Michael Eisner อดีต CEO ของ Disney มาอ้างว่า สุดท้ายแล้วธรรมชาติของบริษัทคือการแสวงหากำไร และ Apple ไม่ใช่บริษัทที่ขับเคลื่อนด้วยนวัตกรรมหรือประชาธิปไตย แต่ขับเคลื่อนด้วยรายได้ หากไม่สามารถรับประกันรายได้เพิ่มขึ้นได้ การลดกำแพงทางเข้าสำหรับนักพัฒนาหรือเปิดกว้างแบบประชาธิปไตย ก็เท่ากับยอมปล่อยรายได้จาก 'ห่านทองคำ' ของสโตร์ทางการไป ดังนั้นตรรกะคือให้ความสำคัญกับกำไรก่อนเสมอ
• สำหรับผู้ใช้ Android ที่มีคลังเพลงออฟไลน์ส่วนตัว ขอแนะนำ Musicolet อย่างแรง มันทำงานได้สมบูรณ์แบบ
  • และ Symfonium ก็ยอดเยี่ยมมากเช่นกัน เพราะรองรับได้กว้างทั้ง Plex, Jellyfin, WebDAV, SMB และอื่น ๆ
• อ่านการวิเคราะห์เชิงเทคนิคแบบลงลึกได้อย่างสนุก และสัมผัสได้ชัดว่าการย้ายจาก React Native ไป SwiftUI ทำให้โค้ดเนทีฟจัดการการเข้าถึง iCloud และการปรับแต่งต่าง ๆ ได้ง่ายขึ้นมากแค่ไหน ส่วนเทคนิคค้นหาด้วย SQLite FTS5 ก็ประทับใจจนคิดว่าจะเอาไปใช้กับแอปห้องสมุดของตัวเอง
• ตอนแรกฉันหลีกเลี่ยง Swift เพราะรู้สึกว่ายาก แต่ไม่เห็นด้วยกับความเห็นที่ว่าพอมี async/await แล้วการเขียนโค้ด concurrency ง่ายขึ้น แม้ async จะทำให้เขียนโค้ดสะดวกขึ้น แต่พอระบบใหญ่ขึ้น กลับยิ่งทำให้ตาม flow ของโค้ดและทำความเข้าใจ concurrency ยากกว่าเดิม เมื่อยังมีปัญหาที่แก้ไม่ตก ก็คิดว่ายังมีทางเลือกอย่าง green lightweight threads ในระยะยาวจึงกังวลว่าแนวทางแบบ async อาจเพิ่มต้นทุนการดูแลรักษามากกว่าเดิม
  • มองว่าปัญหาไม่ได้อยู่ที่แนวคิด concurrency เอง แต่อยู่ที่ข้อจำกัดของ abstraction แบบ async/await มากกว่า concurrency ที่ดีควรทำให้เมื่อโค้ดขยายใหญ่ขึ้นแล้วเข้าใจและดูแลง่ายขึ้น และการห่อหุ้มแบบยึด process/service เป็นศูนย์กลางก็มีข้อดีมาก
  • แต่ถ้าเป็นเป้าหมายแบบเครื่องเล่นเพลงเรียบง่ายของเจ้าของคอมเมนต์เอง ความซับซ้อนที่เพิ่มจาก async ก็คงแทบไม่เป็นปัญหา