TuneDiceを作った理由

TuneDiceを作った理由 | Tsukutta

I got tired of deciding the next song at karaoke, so I made a random selection app

I often felt subtle stress from the fact that choosing the next song at karaoke took time every time. Even though I had playlists created in Apple Music, when my turn came around I couldn't decide, and I'd end up picking the same few songs, which lacked novelty.

So I thought, why not eliminate the selection process entirely and just create an app that randomly draws one song—and I made an iOS app called "TuneDice." I published it on the App Store the other day.

https://apps.apple.com/jp/app/tunedice/id6804372799

What it can do

Randomly select one song from a chosen playlist or your entire library and display the song name, artist name, and album art
Register only songs you've marked as "sung" in your history and exclude them from future draws (if you don't mark them, they'll come up again)
History automatically resets when the date changes; if you've sung all songs, it automatically resets and starts over
Songs you never want to draw again can be added to an NG list separate from history and permanently excluded

It doesn't actually play songs or display lyrics. It's a simple tool that just tells you the song name.

I changed the project name midway

The initial project name was "KaraokeRandomPicker." As I refined the requirements, I realized this wasn't specific to karaoke—it was just a generic feature to "randomly select one thing from a playlist." So I renamed it to "TuneDice" partway through. Since nothing had been released to the store yet, I was able to freely change the Bundle ID and folder names without hesitation.

Implementation was pair programming with Claude Code

The stack is Swift + SwiftUI + MusicKit for Swift, with Xcode project generation via XcodeGen (project.yml management). I went through almost the entire process from requirements definition to implementation with Claude Code.

I accumulated decisions in CLAUDE.md like "song source is either a playlist or library" and "sung history and NG list are managed with separate lifecycles," and refined the specifications while working backward from there to implementation. By resolving specification ambiguities on the documentation side first, I reduced rework during implementation.

Two things I got stuck on with MusicKit

Adding MusicKit capability made it impossible to build on a real device. Swift's MusicKit (import MusicKit, MusicAuthorization) doesn't require App ID capability or entitlements on the Developer Portal side. All that's needed is NSAppleMusicUsageDescription and runtime user authorization. Not knowing this, when I added the MusicKit capability, automatic signing failed due to invalid entitlements. After isolating the cause, removing it made the app build normally on the device.

Once denied, the permission dialog never appears again. Due to iOS specifications, once a user denies permission, that app can never show the system permission dialog again (this constraint is common across all apps). Not knowing this, I had added a "try again" button, which became a bug where after denial, the button appeared unresponsive because .denied was silently returned every time. I fixed it by checking the state with MusicAuthorization.currentStatus and switching the display: if undetermined, show the system dialog; if denied or restricted, show a button to open Settings. I also made it automatically re-check when returning from the Settings app.

App Store review took 3 rounds

Guideline 2.1: I was told the explanation of NSAppleMusicUsageDescription was insufficient, so I rewrote it to explicitly state "why we're accessing this" and "we don't play or save"
Guideline 5.1.1 (iv): The onboarding screen button said "Allow access to library," which made it read as if the button itself granted permission. Additionally, the "do it later" button could indefinitely defer the MusicKit authorization request. I consolidated it to a single "continue" button that always leads to the actual MusicKit authorization request
Guideline 1.5: The GitHub repository I linked as the support URL was private and flagged as a non-functional URL

None of these were feature additions—they were all about the accuracy of explanations and user flows.

In closing

TuneDice is now available on the App Store. https://apps.apple.com/jp/app/tunedice/id6804372799

I'd be happy to receive feedback.

カラオケで次の曲を決めるのが面倒だったので、ランダム抽選アプリを作った

カラオケで次の曲を選ぶのに毎回時間がかかるのが地味にストレスだなーと思うことが多々ありました。Apple Musicにプレイリストは作ってあるのに、いざ順番が回ってくると選べず、結局いつもの数曲を選んでしまい面白みに欠ける。

それなら選ぶ作業自体をなくして、ランダムに1曲出すだけのアプリを作ればいいと思い、「TuneDice」というiOSアプリを作りました。先日App Storeに公開しています。

https://apps.apple.com/jp/app/tunedice/id6804372799

できること

選んだプレイリスト、またはライブラリ全体からランダムに1曲抽選して曲名・アーティスト名・アルバムアートを表示する
「歌った」ボタンを押した曲だけ履歴に登録し、次回以降の抽選から除外する（押さなければまた出てくる）
日付が変わったら履歴は自動リセット、全曲歌い終わったら自動リセットして最初から
二度と引きたくない曲は履歴とは別にNGリストに入れて恒久的に除外できる

実際の再生や歌詞表示はやっていません。曲名を教えてくれるだけのシンプルなツールです。

途中でプロジェクト名を変えた

最初のプロジェクト名は「KaraokeRandomPicker」でした。要件を詰めていくうちに、これはカラオケに限った話ではなく「プレイリストから何かひとつをランダムに選ぶ」だけの汎用機能だと気づき、途中で「TuneDice」にリネームしました。ストアには何も出していない段階だったので、Bundle IDやフォルダ名を含めて気兼ねなく変えられました。

実装はClaude Codeとのペアプロ

Swift + SwiftUI + MusicKit for Swift、Xcodeプロジェクトの生成はXcodeGen（project.yml管理）という構成です。要件定義から実装まで、ほぼ全工程をClaude Codeと進めました。

CLAUDE.mdに「曲ソースはプレイリストかライブラリのどちらか」「歌った履歴とNGリストは別ライフサイクルで管理する」といった決定事項を書き溜めながら仕様を詰め、そこから逆算して実装を進めるやり方にしました。仕様の揺れを先にドキュメント側で潰しておくと、実装の手戻りは減りました。

MusicKitでハマった2つのこと

MusicKit capabilityを付けたら実機ビルドできなくなりました。Swift向けMusicKit（import MusicKit、MusicAuthorization）は、Developer Portal側のApp ID capabilityやentitlementを必要としません。必要なのはNSAppleMusicUsageDescriptionと実行時のユーザー認可だけです。それを知らずにMusicKit capabilityを追加したところ、無効なentitlementのせいで自動署名が通らなくなりました。原因の切り分けたところ、外したら実機で普通に読めるようになりました。

一度拒否されると、二度と許可ダイアログは出ません。iOSの仕様上、ユーザーが一度パーミッションを拒否すると、そのアプリからはシステムの許可ダイアログを二度と出せません（どのアプリでも共通の制約です）。それを知らずに「もう一度試す」ボタンを付けていたら、拒否後は毎回黙って.deniedが返るだけでボタンが反応しないように見えるバグになっていました。MusicAuthorization.currentStatusで状態を見て、未確定ならシステムダイアログ、拒否・制限済みなら設定アプリを開くボタンに出し分け、設定アプリから戻ったタイミングで自動的に再チェックするようにして直しました。

App Store審査は3ラウンドかかった

Guideline 2.1：NSAppleMusicUsageDescriptionの説明が薄いと指摘され、「何のためにアクセスするか」「再生や保存はしない」ことまで明記する文言に書き直した
Guideline 5.1.1 (iv)：オンボーディング画面のボタンが「ライブラリへのアクセスを許可」という文言になっていて、そのボタン自体が権限を許可するように読めると指摘された。加えて「あとで設定する」ボタンがシステムの許可ダイアログを無期限に先送りできてしまう作りだった。ボタンを「続ける」ひとつに集約し、必ず本物のMusicKit認可リクエストにつながるようにした
Guideline 1.5：サポートURLに貼っていたGitHubリポジトリが非公開で、機能しないURLとして差し戻された

どれも機能追加ではなく、説明や導線の正確さを問われる指摘でした。

最後に

TuneDiceはApp Storeで公開中です。https://apps.apple.com/jp/app/tunedice/id6804372799

フィードバックいただけると嬉しいです。