내가 직접 만든 오디오 플레이어

 (nexo.sh)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 2025년에도 iPhone에서 사용자가 보유한 음악 파일을 자유롭게 듣고 동기화하기 어렵다는 문제에서 출발해, 로컬 우선 음악 플레이어를 SwiftUI로 직접 구현함
  • Apple Music 구독을 끊으면 iCloud Music Library 동기화가 멈추고, iTunes Match는 연 $24.99로 256kbps AAC 사본을 온라인에 저장하는 별도 유료 선택지임
  • React Native/Expo는 깊게 중첩된 iCloud 폴더 순회와 파일 권한 처리에서 실패·크래시가 잦아, Apple 네이티브 API를 쓰는 SwiftUI 구현이 더 단순한 선택이 됨
  • 앱은 SQLite FTS5로 파일명과 artist, album, title 같은 메타데이터를 검색하고, iCloud 가져오기·라이브러리 관리·재생 화면을 분리해 구성함
  • iOS는 보안 범위 북마크와 개인 개발 빌드 제한 때문에, 개인이 만든 앱을 오래 안정적으로 쓰는 과정에서도 파일 접근과 배포 장벽이 남아 있음

왜 직접 음악 플레이어를 만들었나

  • iPhone에서 사용자가 보유한 음악 파일을 재생하려면 Apple에 비용을 내거나 여러 제약을 우회해야 하는 상황이 여전히 남아 있음
  • 로컬 음악 라이브러리를 이미 정리해 둔 사용자에게 스트리밍 서비스는 필수라기보다 편의 기능에 가까움
  • Apple Music 구독을 해지하면 iCloud Music Library 기반 기기 간 동기화가 중단됨
    • 이 기능은 구독 뒤에 있음
    • iTunes Match를 쓰면 연 $24.99로 다시 사용할 수 있음
    • Match는 256kbps AAC 사본을 온라인에 저장하며, 원본 파일은 사용자가 바꾸지 않는 한 그대로 남음
    • 구독이 없으면 클라우드 동기화가 사라지고 케이블/Wi‑Fi 동기화로 돌아가야 함
  • 목표는 오디오 파일을 가져오고, 정리하고, 재생하는 기본 음악 플레이어를 직접 만드는 것이었음
  • 완성된 앱은 전체 텍스트 검색, iCloud 지원, 로컬 우선 경험을 제공하며 GitHub에 공개됨

기존 선택지가 맞지 않았던 이유

  • Apple 기본 앱

    • Files 앱으로 iCloud의 음악 파일을 직접 재생할 수는 있지만, 음악 감상용 앱으로 설계되어 있지 않음
    • 플레이리스트 관리, 메타데이터 정렬, 재생 큐 같은 핵심 기능이 부족함
    • 음악 재생 자체는 가능해도 전체 사용자 경험은 제한적이며, 관련 Apple 커뮤니티 논의도 있음

  • 서드파티 앱

    • App Store에는 오프라인 음악 재생 앱이 많지만, 사용자가 이미 소유한 파일을 재생하는 앱에도 구독 기반 가격을 적용하는 경우가 많음
    • Doppler는 단일 결제 모델이라는 장점이 있었음
    • 다만 UX가 앨범 관리 중심이고, 검색 품질이 만족스럽지 않았으며, 중첩 폴더가 많은 iCloud 가져오기는 느리고 사용하기 어려웠음

React Native에서 SwiftUI로 바꾼 과정

  • 처음 선택한 React Native/Expo

    • 과거 Swift 경험 때문에 Swift를 피하고, 웹 개발 경험을 재사용할 수 있는 React Native/Expo를 먼저 선택함
    • 재생 UI 구현은 쉬웠고, 필요한 기능을 갖춘 것으로 보이는 Gionatha Sturba의 music-player 템플릿을 사용함
    • 문제는 파일 시스템 접근과 클라우드 파일 동기화에서 커졌음
    • expo-filesystem 같은 라이브러리는 기본 파일 선택은 지원했지만, 깊게 중첩된 iCloud 디렉터리의 재귀 순회는 자주 실패하거나 앱 크래시를 일으킴
    • iOS 샌드박스는 명시적 사용자 권한 없이 앱이 파일을 읽지 못하게 함
    • 결과적으로 JavaScript 기반 접근은 Apple 네이티브 API를 직접 쓰는 것보다 더 복잡해졌고, Swift로 전환하면 iCloud 파일 접근과 샌드박스 권한을 더 잘 제어할 수 있었음

  • SwiftUI를 선택한 이유

    • UIKit이나 스토리보드 대신 SwiftUI를 선택해 선언적 UI 계층을 만들고, 도메인 로직과 데이터 동기화에 집중함
    • Swift의 async/await와 Swift Actors 통합은 데이터 흐름과 동시성 관리를 쉽게 만들었음
    • SwiftUI는 앱을 독립적인 ViewModel 컴포넌트로 구조화하는 데 도움이 됨
    • OpenAI o1과 DeepSeek 같은 LLM은 순수 UI 코드나 데이터 바인딩 코드를 생성할 때 복잡한 상호 의존성을 덜 만들었음

앱 구조와 데이터 모델

  • 세 가지 주요 화면

    • 앱은 Library import, Library management, Player and playback 세 흐름으로 나뉨
    • Library import는 iCloud 라이브러리 폴더를 추가하고, 모든 폴더에서 오디오 파일을 스캔해 SQLite 데이터베이스에 경로를 삽입함
    • Library management는 추가한 곡을 관리하고 플레이리스트를 구성함
    • Player and playback은 반복, 셔플, 큐 관리, 재생·정지·다음 곡 기능을 담당함
    • Apple 기본 파일 선택기는 키워드로 검색한 여러 디렉터리와 여러 파일을 한 번에 선택하는 흐름에 맞지 않음
    • 빈 라이브러리로 앱을 실행하면 Sync 탭에서 “Add iCloud Source” 버튼을 보여줌
    • 폴더를 선택하면 트리 순회 중 진행 막대를 표시하고, 색인이 끝나면 Library 탭으로 이동함
    • 첫 화면에는 Playlists / Artists / Albums / Songs가 표시됨
    • 트랙을 누르면 하단에 Mini-Player가 나타나고, 이를 탭하면 전체 화면 Player로 이동함
    • 전체 화면 Player는 셔플, 반복, 큐 재정렬, 볼륨을 제공함
    • Sync에서 “+”를 눌러 다른 폴더를 선택하면 새 곡을 백그라운드에서 병합하며 재시작이 필요 없음

  • 서버식 로직 계층

    • 모바일 앱이지만 웹·클라우드 백엔드 경험을 바탕으로 백엔드식 아키텍처를 적용함
    • 도메인·로직 계층을 View와 ViewModel 계층에서 분리해 클라우드 동기화, 메타데이터 파싱, SQLite 데이터 접근을 안정적으로 처리함
    • 계층 구조는 다음과 같음
      • SQLite가 원본 곡 행과 FTS 색인을 저장함
      • Repository가 데이터베이스를 감싸고 비동기 API를 노출함
      • 도메인 Actor가 가져오기, 검색, 큐 로직 같은 비즈니스 규칙을 소유함
      • ViewModel이 Actor를 구독하고 UI용 구조체로 변환함
      • SwiftUI View는 전달받은 데이터를 렌더링함
    • 상태 변경은 스레드 안전하게 유지되고, iCloud 동기화·재생·UI는 직접 계층을 건너뛰지 않도록 분리됨

SQLite FTS5로 만든 로컬 검색

  • 영구 저장소는 SQLite를 사용했고, CoreData는 쓰지 않음
  • CoreData를 피한 이유는 스키마, 원시 쿼리, 특히 전체 텍스트 검색을 직접 제어해야 했기 때문임
  • iOS 11 전후부터 FTS 기능이 포함된 SQLite를 추가 설정 없이 사용할 수 있음
  • 일반 쿼리에는 SQLite.swift를 사용했지만, FTS 쿼리는 일반 SQL 문으로 처리함
  • SQLite FTS5는 파일명과 artist, album, title 같은 메타데이터를 별도 검색 인프라 없이 질의할 수 있게 함

  • FTS 테이블 구성

    • FTS5 테이블은 두 개를 사용함
    • songs_fts: SQLiteSongRepository가 사용하며 artist, title, album, albumArtist를 색인함
    • source_paths_fts: SQLiteSourcePathSearchRepository가 사용하며 fullPath, fileName을 색인함
    • 두 FTS 테이블은 기본 B-tree 테이블인 songs, source_paths 옆에 위치함
    • FTS는 UI에서 읽기 전용이며, 모든 쓰기는 Repository 내부에서 처리됨
    • songs_fts 생성 예시는 songId를 UNINDEXED로 두고 unicode61 토크나이저를 사용함
    • 다양한 문자를 처리하기 위해 unicode61을 선택함
    • 검색하지 않는 키는 UNINDEXED로 지정해 용어 사전이 불필요하게 커지지 않게 함

  • 부분 검색과 순위화

    • 사용자가 “lumine”을 입력하면 내부적으로 “lumine*”처럼 와일드카드를 붙여 부분 검색 결과를 즉시 찾음
    • 검색 결과 정렬에는 SQLite의 bm25를 사용함
    • 이 방식은 예측 가능한 스키마, 로컬 우선 접근, 강력한 전체 텍스트 검색을 제공하며 네트워크 의존성이나 외부 서비스를 추가하지 않음

iOS 파일 접근과 북마크 제약

  • iOS 앱은 파일 위치를 기억하기 위해 영속 북마크를 저장할 수 있음
  • 하지만 앱 샌드박스 외부 파일에 확장 접근을 주는 security-scoped bookmarks는 macOS에서만 제공됨
  • iOS 앱은 일반 북마크로 파일 경로를 기억하고 문서 선택기를 통해 다시 접근을 요청할 수 있지만, 해당 접근이 조용히 계속 유지된다는 보장은 없음
  • 관련 내용은 Apple의 bookmark documentation에 있음
  • 이를 완화하기 위해 파일을 앱 자체의 샌드박스 컨테이너로 복사하는 대체 메커니즘을 구현함
    • 북마크가 유효한 동안 백그라운드에서 파일을 선제적으로 복사함
    • iOS가 권한을 재설정해도 잘못된 오디오 파일 참조에 접근할 위험을 줄임
  • 이 접근은 색인 속도도 개선함
    • 접근이 활성화된 동안 폴더 구조를 한 번 스캔함
    • 관련 오디오 파일만 가져옴
    • 깊게 중첩된 디렉터리를 안전하게 순회함
  • 외부 위치의 개별 오디오 파일을 기기 재시작 후에도 안정적으로 재생하는 문제는 해결되지 않았음
  • 네이티브 앱에서도 이 사용 사례는 iOS에서 충분히 지원되지 않으며, 파일 접근을 안정적으로 처리하기가 여전히 복잡함

재생과 UI 구현

  • 메타데이터 파싱

    • 오디오 파일 메타데이터 파싱에는 Apple AVFoundation 프레임워크의 AVURLAsset을 사용함
    • AVURLAsset은 title, album artist 같은 미디어 파일 메타데이터를 검사할 수 있음
    • 트랙 번호 같은 일부 필드는 ID3 태그에서 직접 찾아야 했음
    • 공식 문서가 엣지 케이스를 충분히 다루지 않아 GitHub 검색으로 구현 예시를 참고함

  • 오디오 재생

    • 라이브러리 색인 후에는 AVAudioPlayer 인스턴스를 초기화해 재생하는 방식으로 오디오 플레이어를 구현함
    • Control Center에서 음악을 제어하려면 AVAudioPlayerDelegate 프로토콜을 구현하고 Apple의 MPRemoteCommandCenter에 연결해야 함
    • MPRemoteCommandCenter는 시스템 수준 재생 제어에 앱이 응답할 수 있게 함

Swift와 Apple 개발 경험

  • 어려웠던 점

    • Xcode의 실시간 SwiftUI 프리뷰는 진전이지만, 전체 개발 경험은 Flutter가 5년 전에 제공하던 VSCode 통합, 실시간 시뮬레이터 리로드, 익숙한 디버깅 도구 수준에 못 미쳤음
    • Swift의 Neovim 또는 VSCode용 LSP 지원은 xcode-build-server 같은 추가 도구가 필요하고, 웹 중심 생태계의 개발 경험과 같지는 않음
    • Apple SDK 일부는 여전히 Objective-C 스타일에 남아 있음
    • Spotlight 파일 검색은 NSMetadataQuery로만 노출되고, NSMetadataQuery는 KVO와 문자열 키를 사용함
    • Swift 친화적 래퍼는 아직 없음
    • SwiftUI의 선언적 UI는 유용하지만, iCloud 권한이 얽힌 전체 앱 동작은 프리뷰에서 에뮬레이션할 수 없어 클라우드 상호작용을 직접 모킹해야 함

  • 좋았던 점

    • async/await 덕분에 I/O 중심 동시성 코드를 콜백 없이 명령형 코드처럼 작성할 수 있었음
    • Actor 안에 동기 코드도 쉽게 넣고 JavaScript 생태계처럼 호출할 수 있었음
    • React Native나 Flutter의 오픈소스 바인딩에 제한되지 않고 Apple 네이티브 라이브러리를 직접 사용할 수 있었음
    • 많은 Apple API는 예제가 있어 시작하기 쉬웠음
    • SwiftUI의 React식 UI 구성 방식은 생산성과 탐색 여지를 제공함

개인용 앱을 오래 쓰기 어려운 iOS

  • 약 1.5주 동안의 구현 끝에 iCloud 저장소에서 오디오 파일을 가져올 수 있는 로컬/오프라인 음악 플레이어를 만들었음
  • 하지만 개발자 인증서가 없으면 앱은 7일만 실행되고, 이후에는 다시 빌드해야 함
  • Apple Developer Program에 등록하려면 $99를 내야 함
  • EU의 DMA Act 이후에도 사이드로딩은 완전히 열려 있지 않음
    • EU 사용자는 개발자 사이트에서 서드파티 마켓플레이스 앱을 설치할 수 있음
    • 개발자는 여전히 Apple의 $99/년 프로그램에 등록해야 함
    • Apple의 Alternative Terms에도 동의해야 함
    • 개인·취미 용도에서는 7일 개발 빌드 제한이 사라지지 않음
  • iOS의 PWA도 제한이 남아 있음
    • iOS 16~18.x 업데이트 이후에도 PWA는 Safari 샌드박스 안에서 실행됨
    • WebGL2와 web-push는 사용할 수 있음
    • Web Bluetooth, USB, NFC, Background Sync, 약 50MB를 넘는 보장 저장소는 제공되지 않음
    • WebGL은 Metal shim을 거치므로 실제 프레임레이트는 네이티브 Metal 앱보다 뒤처지는 경우가 많음
  • AI는 익숙하지 않은 기술을 다루는 데 필요한 지식을 더 쉽게 제공해 소프트웨어 개발 복잡도를 낮췄지만, iOS 앱은 여전히 인위적 규칙을 따라야 함
  • 개인이 직접 만든 앱이라도 일주일 넘게 실행하려면 Apple의 최종 허들이 남아 있으며, 이는 개인 앱 개발과 배포를 제약함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Winamp가 기본 음악 플레이어이던 시절을 지나왔고, 스트리밍 시대에도 여전히 로컬 음악 라이브러리를 폴더로 정리해 둠
    여기 댓글의 다른 사람들처럼 오프라인으로 음악을 듣기 위해 취미 프로젝트로 구식 음악 플레이어를 만들었고, 1페이지짜리 HTML/JS 앱이며 키보드 조작 전체와 간단한 대기열 기능을 넣었음
    확인해 볼 수 있음: https://nobsutils.com/mp

    • 27년쯤 지난 지금도 Winamp UI가 정답에 가까웠다고 생각함
      디렉터리 안의 파일 모음, 전체 컬렉션 셔플, 특정 디렉터리만 재생 같은 단순함이 좋았음
    • 이런 단순한 음악 플레이어를 찾고 있었어서 마음에 듦
      참고로 현재 표준 북마크 단축키인 cmd + d가 웹사이트 북마크 대신 테마를 바꿈
    • 내게 기본 음악 플레이어는 항상 foobar2000이었고, 지금은 Cog 앱으로 대체해서 쓰고 있음

  • FLAC 형식으로 25년 동안 음악 컬렉션을 만들었고, 작년에 Android 폰과 1TB MicroSD 카드를 사서 모든 음악을 넣을 수 있게 됨
    기술이 따라잡기까지 긴 프로젝트였지만, 이제 전부 주머니에 넣을 수 있어서 꽤 만족스럽다
    업계가 밀어붙이는 걸 스트리밍하고 광고를 감수하면서 통제권을 포기하는 임차인이 되고 싶지 않은 사람이 나뿐일 리는 없고, 자기 앱까지 직접 만드는 사람들을 보는 것도 멋짐

    • 기술은 이미 오래전에 따라잡았고, 목적에 맞지 않는 형식을 고집하는 쪽에 가까움
      잘 재인코딩하면 차이를 들을 수 없는 투명한 음질로 훨씬 작은 카드에 모든 음악을 넣을 수 있고, 백업으로는 데스크톱에 FLAC을 보관하면 됨
    • 컬렉션 선별을 정말 잘한 편임
      내 컬렉션은 FLAC/APE/ALAC/WavePack이 25% 정도뿐인데도 3TB가 넘고, 그래서 이동 중에 음악을 듣기 어렵다
      모바일 기기에 뭘 넣을지 미리 고를 수가 없음
    • 나도 25년보다는 훨씬 짧지만 개인 컬렉션을 FLAC 전용으로 만들고 있고, 이미 1TB를 넘었음
      서버는 https://www.navidrome.org, 클라이언트는 https://symfonium.app 조합이 아주 좋았음
      이제 2TB SD 카드도 있으니 가격이 내려가면 아마 하나 살 듯함
    • Android에서는 표지 이미지와 제목이 불안정한 문제가 항상 있었음
      바꿔도 적용이 안 되거나, 적용됐다가 갑자기 엉뚱한 표지로 바뀌곤 했는데, 보기에는 Android 버그 같았음
      이런 문제를 겪었는지 궁금함

  • 전체 앨범을 듣되 중간에 쉬거나 기기를 바꿀 수 있게 하려고 직접 웹 앱을 만들었음
    앨범을 처음부터 끝까지 듣는 걸 좋아하는데, 적어도 YouTube Music은 재생 위치를 기억하지 않고 다른 기기에서 다시 앨범을 열어 중단한 지점을 찾아야 해서 불편했음
    내 웹 앱은 URL을 붙여 넣으면 서버에서 yt-dlp로 내려받고 거기서 스트리밍할 수 있으며, 재생 위치를 항상 기억해서 차 안에서는 폰으로 듣다가 직장에서는 노트북에서 이어 들을 수 있음
    NTS Radio처럼 다른 출처의 믹스를 추가할 때도 잘 맞음

    • YouTube Music에서 가장 답답했던 부분이 바로 저장 가능한 대기열과 더 매끄러운 기기 전환이었음
      공개되어 있다면 그 웹 앱을 한번 보고 싶음

  • 아직 다 읽지는 않았지만 좋은 글이고, 개발자가 더 세부적인 결정을 어떻게 내렸고 왜 그랬는지 읽는 걸 좋아함
    시도해 본 오디오 플레이어들이 마음에 들지 않는다는 생각에는 공감함
    음악 앱 세계에서는 화면 구성과 UI가 거의 보편화된 듯한데, 나는 그게 마음에 들지 않고 이해도 잘 안 됨
    모든 음악 앱과 권투하는 느낌이라, 뭔가 새로운 걸 만들어 보려는 사람은 반갑다

  • 여전히 Apple Music 앱에 내 로컬 파일을 넣어 사용함
    Apple Music 스트리밍 서비스는 꺼 두고, macOS의 Apple Music 앱에 전부 불러온 뒤, 2007년처럼 폰을 노트북에 꽂아 iPod처럼 동기화함
    모든 게 기대한 대로 동작하고, 음악이 자주 바뀌지 않아서 동기화도 문제가 안 됨
    유선으로 동기화할 때 묘한 향수도 느껴짐

    • 내가 알기로는 iTunes로 자동 Wi‑Fi 동기화도 여전히 잘 동작함

  • async/await가 없던 시절 Swift에서 동시성 코드를 Go나 JS/TS보다 투박하고 보일러플레이트가 많게 느꼈다는 데는 동의하기 어려움
    비동기 처리는 동시성 코드를 쓰기는 쉽게 만들 수 있지만, 코드베이스가 커질수록 추론은 덜 단순해질 수 있음
    복잡한 비동기 코드베이스에서는 코드 흐름과 동시성을 이해하기가 더 어렵다
    스레드 코드 실행 비용을 줄이는 게 목표라면 경량 그린 스레드라는 해법이 있고, 스레드 코드 유지보수 비용을 줄이는 게 목표라면 비동기는 장기적으로 더 많은 노력을 요구할 가능성이 큼

    • 좋은 동시성은 코드가 커질수록 이해와 추론을 더 단순하게 만들어야 함
      프로세스나 서비스 기반 캡슐화만으로도 큰 이점이 있음
      이건 동시성 자체의 실패가 아니라 async/await 추상화의 한계에 가깝다고 봄
    • 이 경우에는 단순한 오디오 플레이어가 목표라서, 아마 큰 문제가 되지는 않을 듯함

  • 글이 노래를 관리하고 재생하는 소프트웨어뿐 아니라 물리적인 기기에 대한 이야기이길 기대했음
    몇 년 전 음악 듣기를 정말 좋아하지만 아직 폰을 쓸 준비는 안 된 10살 아들에게 MP3 플레이어를 사주려 했는데, 선택지가 너무 처참해서 놀랐음
    Apple이 iPod을 단종하면서 아무도 채우지 못한 큰 공백을 만들었다고 봄
    USB 스틱 형태의 iPod shuffle이 지금까지 써 본 최고의 MP3 플레이어였고, 작고 별도 케이블 없이 꽂을 수 있으며 배터리도 오래 갔음
    음악을 탐색할 화면은 없었지만 그게 의도였고, 셔플에 맡기면 됐음
    이렇게 비교적 단순한 개념조차 하드웨어 시장에서 제대로 복제되지 않았다는 게 아쉽다
    사람들은 하드웨어 문제가 아니라 소프트웨어/DRM 문제라고 하겠지만, 좋은 저가 휴대용 음악 재생 기기가 없다는 건 정말 안타까움

    • 여기서 진짜 변화는 iPod의 소멸이 아니라고 봄
      Spotify와 스마트폰의 존재가 MP3 플레이어를 죽였고, 둘이 시장의 공기를 너무 많이 차지해서 나머지를 질식시켰음
    • Fiio가 이 범주의 제품을 꽤 많이 만들고 있음
      예를 들면 https://www.fiio.com/cp13와 https://www.fiio.com/jm21이 있음
    • 중고 iPod이 많고, 구형 하드디스크 모델 상당수는 플래시 저장장치로 개조하기도 꽤 쉬워서 선택지가 될 수 있음
      전자공학과 “오래된” 기기 재활용을 배우는 작은 교육 프로젝트로도 괜찮다
      외관 커스터마이징 선택지도 많고, Bluetooth나 USB‑C 추가 같은 더 깊은 개조도 가능함
      다른 사람들이 말했듯 소프트웨어 쪽도 Windows의 iTunes, macOS의 Finder/Music 통합으로 여전히 잘 동작함
    • 하드웨어나 소프트웨어 문제가 아니라 수요 문제에 가깝다고 봄
      중국 제조사들은 Mini iPhone 16이나 Mini S24처럼 보기 좋고 음악 재생도 되며 스마트폰 기능도 있는 기기를 50~100달러에 팔고 있음
      부모들은 MP3 플레이어 대신 비슷한 기기를 아이들에게 사줄 가능성이 큼
      14살 아들에게 폰을 주지 않는 건 관습적이지 않은 양육 방식이고 존중하지만, 그런 수요가 현재 가능한 공급 이상으로 많지는 않아 보임
    • Sony는 아직도 Walkman 브랜드로 꽤 좋은 플레이어를 만듦: https://electronics.sony.com/audio/walkman-digital-recorders...
      10살 아이에게는 비쌀 수 있지만, eBay에서 중고를 찾을 수 있을지도 모름

  • Music.app으로 로컬 음악을 관리하고 Finder의 iPhone 동기화를 쓰는 조합이 아직 내게는 잘 맞음
    다만 Music.app은 끔찍했던 Big Sur 재작성 이후 몇 년째 유지보수가 안 되는 듯하고 성가신 버그도 있음
    결점에도 불구하고 이 조합은 내가 본 것 중 최고의 음악 라이브러리 관리 + 모바일 동기화 해법이지만, 소프트웨어가 유지보수되지 않고 크로스 플랫폼도 아니라 결국 직접 시스템을 써야 할 것 같음

    • Music “재작성”의 일부 문제는 실제 재작성이라기보다 iTunes에서 복사해 붙인 것에 가깝다는 데 있음
      OS 9 시절의 흔적인 모달 설정/환경설정 창처럼 iTunes 특유의 기묘함이 많이 남아 있음
      OS X 설정 창은 모달이어서는 안 됨
      완전히 새로 만든 WinUI 기반 Windows용 Music처럼, 처음부터 다시 만든 버전을 내부에서 작업 중일 것 같다는 추측이 듦
    • 내 5세대 Video iPod에서는 내장 Finder 동기화가 아직도 많이 망가져 있음
      가장 짜증 나는 건 팟캐스트 동기화였고, iTunes가 담당하던 시절에는 잘 됐지만 Big Sur의 Finder 동기화에서는 버그가 있어서 다른 트랙이나 팟캐스트로 갔다가 돌아오면 재생 위치를 기억하지 못함
      그래서 몇 분보다 긴 팟캐스트는 사실상 기기에서 쓰기 어렵게 됨
    • 내 앱도 한번 시도해 볼 수 있음: https://www.plastaq.com/minimoon

  • 사람들은 Android로 갈아타는 대신 정말로 자기 음악 앱을 만들어 버림
    파란 말풍선 때문인지, 아니면 모든 게 “그냥 된다”는 점 때문인지 궁금함, 오프라인 음악 재생만 빼고

    • 빵이 더 맛있다는 이유만으로 정말 다른 나라로 이사하겠음?
      직접 굽는 게 뭐가 문제인지 모르겠음
    • iOS용 음악 플레이어 프로토타입을 만들었음
      VLC 앱이 내 파일 서버에 있는 FLAC의 메타데이터를 안정적으로 파싱하지 못하고, 저장공간 제한 때문에 전체 음악 컬렉션을 기기에 저장할 수도 없었기 때문임
      내 앱은 더 많은 기능을 원한다는 점에서 프로토타입이지만, 오디오 재생, 원격 파일 접근, FLAC 메타데이터 파싱은 있어서 추가 기능을 구현할 동기가 부족할 만큼은 동작함
      글쓴이처럼 처음에는 경험이 있고 유지보수 중인 앱도 몇 개 있어서 React Native를 쓰고 싶었지만, 다른 플랫폼을 대상으로 삼거나 디버깅하고 싶지는 않았음
      그래서 SwiftUI를 써 보기로 했고, 특수 도구[1]로 핫 리로드 비슷한 것을 만들었음
      Xcode에 커스텀 링커 플래그를 넣어야 하는 꽤 지저분한 해킹이지만, TypeScript와 React Native의 개발자 경험을 그리워하지 않을 정도로는 동작함
      [1] https://github.com/johnno1962/InjectionIII
    • 사람들은 정말로 Android를 피하려고 코드를 씀
    • foobar2000은 오래전부터 App Store에 있었음
      사실 글쓴이가 마음에 드는 무료 음악 앱을 못 찾았다는 건 조금 이상하다고 봄
      그래도 뭔가를 만들기 위해 꼭 핑계가 필요하지는 않으니, 이야기를 시작하기 위한 서사였을 수도 있음
    • iOS에서 navidrome/substreamer 앱 조합을 쓰고 있는데 잘 동작함
      선택한 음악을 기기에 보관할 수도 있음

  • 오프라인 음악 컬렉션이 있다면 https://play.google.com/store/apps/details?id=in.krosbits.mu...를 정말 추천함
    문제없이 잘 동작함

    • Symfonium도 훌륭함
      Plex, Jellyfin, WebDAV, SMB 등도 지원함
답변달기