私の記憶する限りでは、URLスキームの重複が問題になったのはfb://を使うFacebookとTouchRetouchからでした。
もちろん他にもあったでしょうが、これは双方人気アプリだったため問題に。
この時も再インストールすれば動くとか、fb://は使わない方がいいとかいろんな情報があったのを覚えています。
（2012年2月頃の話題）
この当時はまだURLスキームに対応したアプリの数が比較にならないほど少なかったので、ほとんど衝突は見られませんでしたが、いまやひどい有様です。
重複のひどい現状
Wikipedia関連には多くのクライアントが登場していますが、それらのうちでもWikipanion、Articles、Wikiamoという人気のあるアプリがこぞってwikipedia:というURLスキームを採用しています。
このせいでWikipanionを起動したくてもArticlesが起動するなんてことが起こってしまいます。
sip:というURLスキームを使っているアプリは20以上あります。
ユーザーがSIPアプリを複数インストールする可能性を開発者が少しでも考えていれば、こんな馬鹿げたことをやらないでしょうに。
重複を調べるための完璧な方法はありませんが、Zwappというサイトが1万件以上のURLスキームを検索できますので、そちらで簡易的に確認ができます。
Zwapp.com
vncやmmsなどでも調べてみるといいです。
しかし、ここで確認できるのもごく一部だけです。
日本のアプリなどは、MyScriptsというアプリで調べた方がいいでしょう。
（※MyScriptsとiWappというスクリプトが必要になります）
MyScripts LE
無料
販売: Takeyoshi Nakayama
評価: 
（6件）
iPhone/iPad対応
使い方など、詳しくはこちらで → http://aitamblr.tumblr.com/tagged/iWapp
今後憂慮すべき分野
私が好きなURLスキームの形にhttpタイプのものがあります。
GoodReaderで有名になったやり方ですが、httpの前にgを付けghttp://とすることでSafariなどのブラウザからURL情報をそのまま取得できるというものです。
ブックマークレットでの対応も楽なうえ、構造がシンプルでユーザーに分かりやすいので、今後も増えていくでしょう。
で、これがhttpタイプのリストです。とりあえずアルファベットだけ。
ahttp: IAnnotate PDF
bhttp: Sleipnir(Black Edition)
chttp: Clipbox
dhttp: dAnce! Web Browser
ehttp:
fhttp:
ghttp: GoodReader
hhttp: hackadl
ihttp: Instapaper
jhttp:
khttp:
lhttp:
mhttp:
nhttp: ののワ
ohttp: Opera
phttp: ACTPrinter
qhttp:
rhttp: Documents by Readdle
shttp: Sleipnir
thttp:
uhttp:
vhttp:
whttp: WebHub
xhttp:
yhttp:
zhttp: Save2PDF
まだ、空きがあると思うかもしれませんが、載せていないだけで、実際にはこの中でもすでに重複があります。
ここで問題になってくるのは、これが先着順でも占有できるわけでもないところ。
年に10万本以上のアプリが世に出る中で、たった26パターンの覚えやすいURLスキームを永続的に占有できると考えるべきではないですよ。
httpタイプのものを設定するのなら重複しないだろうレベルでリスク回避を。
（xhttpの形を使わず、完全に置き換える方がいいと思う方も多いでしょうが、httpタイプにはまたメリットがあるので、それはまたいずれ）
設定すべきはユニークな重複しないURLスキーム
以前に書いたエントリ『URLスキームが複数のアプリで同一であった時のiOSバージョンごとの挙動について』でも示していますが、重複したURLスキームではどのアプリを起動するかが明確ではありません。
期待したアプリが呼び出せないURLスキームなんて、家族が出るかもしれない家の電話番号を渡されるのと同レベルで、積極的に使いたいものではありませんよね。
後継アプリを別アプリとしてリリースする際にも、重複しないURLスキームを使わないと、旧アプリと新アプリでの使い分けが困難になります。
新旧のアプリを両方インストールしてくれるユーザーは歓迎こそすれ、混乱させるべきではない。
もちろん有料版と無料版も同様です。
開発者はわかりやすさではなく、他のアプリと被る恐れのないユニークなものを優先して設定すべきです。
