#1518: iCloud バックアップは 180 日後に削除される、ARM Mac の真相、Apple が iBooks Author を放棄、メニューバー用スクリプトと BitBar チュートリアル

TidBITS 読者の Walter Ian Kaye が、単純な質問をした。「皆さん、Apple が 180 日以上経った iCloud バックアップを削除していることを知っていましたか？ 私は知りませんでした😭」

息子が高校生の頃に使っていた若者言葉を自分が知らぬ間に口にしているのに気付いて私はいつも困惑するのだが、今回 Walter の質問を目にして私がまず口にしたのは、まさにその "Wait, what?" だった。

Apple が iCloud バックアップを 180 日後に削除していたなんて私は全然知らなかったし、TidBITS Slack チャンネルで手早くアンケートをとってみてもその事実は TidBITS スタッフや寄稿編集者たちの間でも一般的知識ではなかったことが分かった。

でも、ちょっと Google 検索をしてみると、その方針は決して新しい話ではなかった。2014 年に困り切って苦情を述べていた iCloud ユーザーが何人もいたし、Take Control 執筆者の Kirk McElhearn は 2013 年の Macworld 記事でその事実に触れている。

Apple はこの事実をさまざまな場所で公表している。iCloud User Guide にも、Manage Your iCloud Storageサポート記事にも、iCloud Terms and Conditions にもそのことが書かれている。けれども、そのような制約があるならばきっと iOS のインターフェイスのどこかに警告が出るだろう、例えば iCloud Backup を有効化する画面か、何がバックアップされているかを調べる画面かに警告が出るだろうと思われるなら、その期待は落胆に終わる運命にある。

Apple によるこの削除方針の確認通知は、その昔の The Hitchhiker's Guide to the Galaxy での Arthur Dent の家の取り壊し通告ほど極端には隠されていた訳でない。それでも、iCloud バックアップからのリストアをするつもりで見てみたら既に Apple が削除していたと気付かされた人の身になってみれば、一度も見たこともないサポート書類に書いてあるのが唯一の警告だったとしたら、それは Arthur Dent の立場とほとんど同じことではないだろうか。

その一方で、Apple がデバイスのバックアップを削除したいと思う理由も頷ける。かなりサイズの大きいものだし、誰も二度と使わない可能性が高いのだから。何億台ものデバイスが iCloud にバックアップしていることを考えれば、そのために必要となるストレージの必要量は想像もつかない。

でもまた他方、いったい Apple は何を考えていたのか？！？ ユーザーがたった一つしか持っていない、他に替わるもののないバックアップを、しかも削除が迫っているという警告をユーザーインターフェイスの中にはっきり示すこともなく削除するとは、どう見ても受け入れ難い。

当然のことだが、大多数の人々はこの問題に遭遇することはない。バックアップを作っておいて、リストアすることもなく半年間も放っておくというのは、普通ではない状況だ。普通ではないけれども、あり得ないとは到底言えない。Walter は死にかけていた iPad をバックアップして、それ以来新しい iPad を買うためにお金を貯めていたのだが、iCloud に 200 GB のストレージ容量を確保するため毎月 Apple に料金を払い続けてきたのだから、まさかリストアができなくなるなんて思ってもいなかった。

明らかに Apple はスケジュール化された手順を使ってバックアップの経過期間をチェックし、180 日を過ぎたものを削除しているに違いない。ならば、その手順にちょっと調整を加えて、ユーザー宛に電子メールで警告を送るようにするのも Apple のエンジニアたちにとってはごく簡単なことではないだろうか。例えばこんな風に：

あなたの "Adam's iPad 2" の iCloud バックアップは 2020 年 1 月 1 日に作成され、2020 年 6 月 30 日に有効期限が切れます。その前に同じデバイスで新たなバックアップを作成しなければ、このバックアップは削除されます。

さらにもっと望ましいこととして、その電子メールのメッセージにリンクを含めて、ユーザーがそのリンクをクリックすれば 180 日のカウンターがリセットされるようにしてはどうだろうか。そうすれば Walter のような人たちがリストアする前にバックアップが期限切れとなってしまう事態が防げる。

それはさておき、もしも iOS デバイスのバックアップをいつまでも残しておきたいと思うならば、Mac にバックアップしておく方法もある。macOS 10.15 Catalina では Finder を使ってできるし、それより前の macOS ならば iTunes でできる。(バックアップの種類によって他にも違いはあるけれども、180 日館の制限があるという話は聞かない。) 残念ながら、ローカルにバックアップをすれば大量のストレージ容量が消費される。(私の iPhone 11 Pro のバックアップは 67 GB 以上ある。) その上、バックアップは ~/Library/Application Support/MobileSync/Backup/ に置いておかなければならず、起動ドライブの容量が小さい人にとっては深刻な問題となる。実際、Walter がそもそもバックアップに iCloud Backup を選んだのはそれが理由だったのだから。

討論に参加

Apple が同社のメディア出版サービス iTunes Connect の参加者に通知したところによると、Mac 用の iBooks Author アプリは「今後アップデートされず、間もなく Mac App Store から削除されます」とのことだ。iBooks Author のファンたちが長年恐れてきた瞬間が、ついにやって来た訳だ。(2017 年 10 月 24 日の記事“iBooks Author Conference の焦点は iBooks エコシステムの懸念”参照。)

2012 年初めの特別な教育イベントで導入された (2012 年 1 月 19 日の記事“Apple、学校に戻る： iBooks 2、iBooks Author と iTunes U”参照) iBooks Author は、「教育者や小規模の出版社が独自に本を制作する」ためのツールを提供しようとする Apple の試みの一環であった。けれども Apple はその代わりに電子ブック作成用ソフトウェアに向けた努力を Pages に集中させることにし、サポート書類“Transition from iBooks Author to Pages”を提供して iBooks Author ユーザーたちが Apple のこのワードプロセッシングおよびページレイアウト用アプリに切り替える手助けをした。

2012 年に導入された当時には、iBooks Author は Apple としての教育用ソフトウェアに向けた関心を世に向けて告げるものに見えた。インタラクティブな教科書を作成する仕事を教育者たちの手に委ねるために設計され、パワフルでありながら (比較的) シンプルな形でワードプロセッシングとページレイアウトの諸機能を提供し、さまざまの「ウィジェット」つまり著者が原稿の中に気軽に放り込むことのできるインタラクティブな項目を取り揃えた。例えば画像ギャラリー、埋め込みスプレッドシート、小テスト、多様な種類のメディアなどが使えた。

しかしながら、初期のバージョンの iBooks Author で作られた電子ブックは、サードパーティの電子ブックリーダーが読める標準的な EPUB 書類ではなかった。その代わりに、Apple の読書用ソフトウェア iBooks でしか読むことができなかった。iBooks Author で作られたブックが含むことのできた非標準のインタラクティブ・コンテンツへの対応を iBooks が提供していたからだ。それでもなお、このソフトウェアを利用して教育市場以外、例えば旅行用の本や料理本などを制作した出版社は多かった。

程なく iBooks Author は苦しい時期に突入した。iBooks Author がリリースされてからほんの数か月しか経たないうちに、Apple の書籍出版ビジネスが独占禁止法の訴訟に巻き込まれたのだった。(2013 年 7 月 10 日の記事“Apple の電子ブック価格操作訴訟を解説”参照。) 結局は敗れるに至った Apple がこの訴訟を戦っている間に、Apple はこのアプリを宣伝することへの興味を失い、このアプリを使いたがっている教育者たちへの支援を提供する気もなくしてしまったようだった。けれども Apple はその後も iBooks Author の更新を続け、EPUB フォーマットへの書き出し機能を追加しさえした (2015 年 7 月 10 日の記事アップデートで iBooks Author の範囲広がる”参照) のだが、Apple がそのことを公に語ることもほとんどなかった。

そうする代わりに、Apple は Pages に関心を向けた。ずっと以前から Apple の iWork スイートの一部であった Pages は、Apple が書籍ビジネスのために裁判所で戦っていたのとちょうど同じ時期に、全面的なデザイン改訂を受けつつあった。現在は Pages 5 と呼ばれているそのアプリが 2013 年後半に登場した際、多くの人たちはこれが前回のバージョンの Pages に比べて (さらに iBooks Author に比べても) 機能が劣ると思ったし、これは iBooks Author が備えていた異彩を放つ諸機能を一つも備えていなかった。(2013 年 10 月 22 日の記事“無料の新 iLife、iWork アプリはデバイスとプラットフォームを横断”参照。) それでもなお、Apple はその後も引き続き Pages の機能を強化し拡張したので、最近のバージョンの Pages にはブック・テンプレート、電子ブック出版機能、さらには iBooks Author に備わっていたようなメディア機能のうちいくつかさえ含まれるようになった。(2018 年 11 月 12 日の記事“Pages 7.3, Numbers 5.3, Keynote 8.3”参照。)

iBooks Author の終焉が差し迫った今、Apple が提供する電子ブック出版用アプリで出版社や教育者が利用できるものは Pages しかない。出版社に関して言えば、現行バージョンの Pages が十分に iBooks Author の欠落を埋め合わせられるかもしれない。電子ブック用のフォーマッティング機能はかなりパワフルなものになったし、それに iBooks Author と違って Pages は Apple 製でないデバイスでも読める標準的な EPUB ブックを作成することができる。

けれども教育者たちにとっては、Pages は良し悪しだ。一方では、Pages が提供するウィジェットは、iBooks Author のウィジェットのほんの一部のものにしか同等でない。とりわけ、メディアおよび画像ギャラリーが問題だ。他方、Pages は Mac だけでなく iPad、iPhone、さらにはウェブブラウザでも動作するし、iBooks Author には一度も組み込まれなかった共同作業用の機能も備えている。

この最後の点は重要だ。教育者たちはパワフルな電子ブック出版ツールにアクセスできるようになっているべきではあるけれども、仕事をしている教師たちで、独力で本を執筆して出版し、それと並行して授業プランを練ったり、宿題を採点したり、そしてもちろん、教室で授業したりする、そんな時間と技能を持ち合わせている人などほとんどいない。共同作業によって作業を分担し、他の教師たちやコンテンツの専門家たちと協力して電子ブックのプロジェクトを進められること、これは iBooks Author が提供したことのなかった機能だ。

諺に言う犬小屋の中にもう何年間も放置されてきた iBooks Author とは違って、Apple は定期的に Pages をアップデートしているし、少なくとも若干ながら宣伝もして人々にその存在を知らしめている。多くの意味で、Pages はかつて iBooks Author が渇望していた豊かなメディア・オーサリング用アプリとなっている。将来のバージョンの Pages で、Apple がもっと多くの iBooks Author ウィジェットを組み込んでくれればと願うばかりだ。

幸いにも、これまで使い続けてきたアプリがついに虚空のビット・バケットの中へと消え去ってしまったとしても、ベテランの iBooks Author ユーザーたちは自らの苦労の成果を捨て去る必要はない。iTunes Connect 会員たちに宛てた書簡の中で、Apple は「iBooks Author ブックを Pages に読み込んでさらなる編集を加えたいとお思いの方たちのために、間もなく Pages にブック読み込み機能を登場させる予定です」と述べた。

もしもその読み込み機能がうまく働けば、iBooks Author の終焉は、悲しいことではあるけれども、熱心な教育的著者たちにとって思ったほどに胸が張り裂けるニュースではないのかもしれない。

討論に参加

Apple が、現行の Mac に使われている Intel x86 プロセッサを、iOS 機器を動かしている Apple の A シリーズチップの様な ARM プロセッサに切り替えるのではないかとの噂は絶えることがない。Apple は一度もその様な移行を口にしたことはないが、Apple の進路としては間違っていない。しかしながら、最近 Bloomberg の Mark Gurman は、Apple が ARM-based Mac に 2021 年に移行するとの記事を書き ("Bloomberg、Apple が 2021 年に Mac を ARM に移行させると伝える" 27 April 2020)、更に今週になって、彼は 22 June 2020 に Apple の Worldwide Developers Conference で発表があるかも知れないとの記事でフォローアップした。Bloomberg は過去にも問題の記事を出したことがあるが (Apple、Businessweek の中国ハックの報道記事をきっぱりと否定" 8 October 2018 参照)、Gurman は信用出来る情報源で正確な記事を書くことで知られている。

ARM は世界で群を抜いて最も多用されているプロセッサである。世界には、数十億の Intel PC があるが、ARM 機器は一千億台を超える。Apple が Intel-based Mac を設計した時、それは Apple が x86 チップを使って作った初めての主要製品であった。しかし、Apple は ARM チップを使っての多くの経験を有している。ARM プロセッサを使った最初の Apple 機器は 1993 年の Newton であった。それ以来、Apple は ARM プロセッサを iPod, iPhone, iPad, Apple Watch, そして Apple TV に使ってきた。

Apple はこれ迄も、二度に亘って Mac のプロセッサを成功裏に切り替えてきた。1994 年には、Apple は Mac の 初代の Motorola 68000 プロセッサから IBM PowerPC プロセッサに移行した。そして 2006 年には、同社は Intel x86 プロセッサの方が良いとして PowerPC を捨てた。 どちらの移行も何年にも亘るテストのお陰で概ね順調であった - Apple は、最初の Intel Mac が出荷される何年も前から Intel 上で走る Mac OS X のバージョンを維持していた。Apple はまず間違いなく今 ARM 上で走る macOS のバージョンを、秘密のラボに、保持していると思われる。

私は、Apple が ARM-based Mac を開発中かどうかに付いての内部情報は一切持っていないが、Intel から ARM に切り替えることに関する得失を見てみよう。

明白な勝ち：低消費電力

ARM プロセッサに対して最も一般的に言われる長所はより低い消費電力である。ARM プロセッサは Intel の x86 プロセッサよりも少ない電力を消費するというのは本当である。この特長は ARM の比較的すっきりした現代的な設計から来ているが、初代の 8086 プロセッサ以来 Intel が溜めてきた長年のしがらみには縛られていない。恐らく、もっと重要なのは、Intel が汎用の PC 用に設計した標準品の部品に依存することなく、ARM が Apple にそれが必要とする特定のサポートを独自の ARM チップ設計に追加させてくれるやり方であろう。

より少ない消費電力は Mac を幾つかの点でより良くするであろう。一番明白なのは、ラップトップ上の電池がより長持ちすることである。8 時間の代わりに、新しい ARM-based Mac ラップトップは同じフォームファクターの中で一回の充電で 12 時間持つようになるかも知れない。しかし、Apple は常により薄型の、より軽量のラップトップを目指している。そこで Apple は、8 時間の電池寿命は多くのユーザーには十分であり。電池をより小さくして、より薄い、より軽いラップトップデザインを目指すかも知れない。

消費電力の減少はプロセッサによって生起される熱も少なくなることを意味し、ヒートシンクもより小さくなり、そしてファンによる騒音もより小さくなるであろう。これは、ラップトップにもデスクトップにも恩恵をもたらす。iMac Pro の様に、その熱設計の限界に近い所で走るコンピュータは、同じデザインの中でより強力なプロセッサを手にすることも出来るし、同じ処理能力を持ちながらより小型の筐体とすることも可能になる。

しかし、より少ない電力は ARM に切り替える唯一の特典ではないし、主たる特典ですらないかも知れない。

Apple の真の動機：支配と利益

Apple は自らの運命を自分で制御したいと思っており、現時点でそうする最善の方法はプロセッサロードマップ (計画) を支配することである。ロードマップとは将来の開発計画を意味する：何の機能を加えるか、どの様な計画をどの様な順番で、どの生産工場とプロセスを使うか、何個のプロセッサを作るか、そして個々の製造会社に何個割り当てるか、等々である。Apple はこれらの鍵となる決定に対して Intel に依存したくはない。Tim Cook が言ったとして有名なのは "我々が製造する製品の背後にある主要な技術は自分で保有し制御する必要がある。"

Intel から ARM に切り替えるもう一つの理由は利益である。Intel プロセッサは利益率の高い製品であり、Apple もその儲けは Intel に払うのではなく自分のものとしたい。

結論を言えば、Apple が Intel x86 アーキテクチャーから ARM アーキテクチャーに切り替える主な理由はビジネスであり、技術ではない。では次に、それらとそれに関わる経営判断を見てみよう。

ロードマップ

プロセッサロードマップを支配することで Apple はその製品をより制御しやすくなる。Intel がチップセットに組み込む構成要素に縛られてしまうのではなく、Apple は System On a Chip (SOC) を Mac 専用に設計出来る。これは iOS 機器ではもう何年も前からやっていることである。Apple は、コアの数と型、デジタル信号プロセッサメディアコア、データの大きさとインストラクションキャッシュ、メモリコントローラ、USB コントローラ、Thunderbolt コントローラ等々を制御出来る。Apple は単一チップだけではなく、プロセッサラインの全体の方向も支配するであろう。

Windows を Microsoft から、或いは ChromeOS を Google からライセンスする PC メーカーとは異なり、Apple はそのオペレーティングシステムも支配している。これが Apple に競争相手に対して巨大な優位性を与えている。Apple の最新の iPhone SOC は高速と低速コアの両方を有している。同社はこれらを "性能" と "効率" コアと呼んでいる。"3 GHz プロセッサ" の様なコンピュータの宣伝速度はこの高速コアの速度である。プロセッサ依存度の高い仕事をする時、例えば、Final Cut Pro X でのビデオレンダリングや Xcode で iPhone アプリをコンパイルする様な、これらのタスクは高速コア全てを使うであろう。一方で、メールメッセージを書いたり Web ページを読んだりしている時には、Mac は殆ど何もしなくてよい。現在、全ての macOS は主たる Intel プロセッサをより低速で走らせられる。高速と低速のコアを持つカスタムの ARM-based SOC があれば、macOS は、より低速の、よりエネルギー効率の良いコアに切り替えられる。タスクに応じてコアを動的に切り替えることが、エネルギー節約の鍵なのである。

iOS 機器用の A シリーズチップに、Apple はまたカスタム設計のメディアコアを作り込んだ。これは、映画用にビデオをポッドキャスト用にオーディオをデコードする、そして暗号化の様なタスクを司る。Intel チップも同様な機能を持っているが、カスタムチップの場合、Apple は Mac で最も一般的なメディアフォーマットや暗号化アルゴリズム用に最適化出来る。そして Apple はまた macOS を支配しているので、macOS アルゴリズムとプロセッサコアを完全に合致させることが可能になり、どんなタスクに対してもより少ない電力消費が可能になる。Apple 技術者がアルゴリズムを改善した時、彼らは次世代のメディアコアをその改善を完全にサポートするべくアップデート出来る。しかも、それらの改善が競争相手の手に渡ることを避けながら。

近代の Mac アプリのコードの多くは、一つのタスクを成し遂げるために macOS API コールを貼り合わせているだけである。多くのアプリにおいて、プロセッサに負荷のかかる仕事の大多数は macOS の中で起こっている。つまり、Apple はアプリがする仕事の多くを新しい ARM プロセッサで最適化出来ることを意味する、サードパーティ開発者達が新しい ARM プロセッサ自身を活用することに熟練するのを待つ迄もない。例えば、映画の再生の多くは macOS をコールすることに関わっており、macOS は Apple の最適化されたメディアコアを使ってビデオをデコードする処理をこなせる。

Intel の生産問題

ここ数年ほど、Intel は一連の生産問題を経験した。それらの多くは、より細密なプロセス、つまりシリコン上により精細な回路をエッチングする、への移行の結果であった。より細密なプロセスはより小さなチップを可能にし、より少ない電力を消費し、そして発生する熱量もより小さくなる。我々が知ることは決してないであろうが、Apple が長い間新型 Mac をリリース出来なかった一つの理由は、Apple が必要とする新型チップを提供するのに Intel が対応出来なかったことにあるのは考えられる。これが Mac の販売台数に影響しないはずはなく、Apple はこのパートナーについて公に苦情を言ったことはないが、Intel に満足しているはずもない。

Intel チップを買うことは、Apple が Intel のチップ製造に依存することを意味する。 Apple が独自のチップを設計すれば、好きな製造場所を使える。Apple は現在、その A シリーズチップのために TSMC と Samsung に依存しているが、これらの企業が Apple のニーズを満たすのに問題があれば、Apple は他の製造場所を、同等の能力を有しているとして、選べる。Apple は、部品に対して複数の供給源を持つことを好む。

時として製造の問題は、Intel の場合の様に技術的だが、中国製に対する特別関税の様に政治的な場合もあり、或いは、自然災害の場合もある。2011 年にはタイのハードディスク工場が洪水により閉鎖され、世界的な品不足を招いた。複数の供給源を持つことにより、一つの業者の問題で生産が止まる事態は回避出来る。

利益

スクリーンに次いで、プロセッサはコンピュータの最も高価な部品の一つである。プロセッサは単に高価なだけではない；それは利益率も高い。生産量が大きい場合、プロセッサは製造にかかるコストよりも遙かに高い値段で売られる。Intel プロセッサに依存することは、これらの豊かな利幅を手にするのは Apple ではなく Intel であることを意味する。独自のプロセッサを設計し製造することで、Apple はこれらの利益を自分のものにすることが可能となる。その場合、Apple はコンピュータを同じ価格で売り続けて利益を追加することも出来るし、同じコンピュータを、同社の有名な高利益率を犠牲にすることなく、値下げして売ることも可能になる。

Intel と ARM はあたかも競争相手と見えるかも知れないが、彼らのビジネスモデルは全く異なっている。Intel はプロセッサのみならずメモリコントローラの様な関連する支援コンポーネントも全て設計する。そしてそれらを System On a Chip に集積する。同社はチップを自らの製造工場で製造する。そしてチップをコンピュータメーカーに直接販売する一方で、そのブランドを一般大衆にも宣伝する ("Intel Inside")。Intel は高級プロセッサを売ることでその利益の大部分を稼ぐ。最高速のプロセッサは最も高い利益率を持つが、更に高速のプロセッサによって直ぐに時代遅れにされてしまうので、Intel は常に限界に挑んでいる。Intel には AMD の様なライバルもいなくはないが、概して、Intel は高級プロセッサにおいては支配的な供給源である。

ARM (以前は Advanced RISC Machines として知られていたが、今では Arm Limited) は全く違う様に働く。ARM はプロセッサを設計し、その設計をライセンスする。ARM は支援コンポーネントを納めないし、自分のチップも作らない。ライセンスを受けた者が、ARM プロセッサと支援コンポーネントを一つの SOC に集積する - これが Apple がその A シリーズチップに対してやっていることである。ARM プロセッサは安価であり利益率も低いので、ARM は量で稼ぐ。世の中には、Intel プロセッサよりも遙かに、遙かに多い ARM プロセッサが存在する - 私は誰かが、一次近似をすれば世界中のプロセッサは全部 ARM プロセッサであると言っていたのを聞いたことがある。

Intel は ARM よりも遙かに多くの利益をあげているが、その理由は Intel CPU は高額の高性能チップであり、Intel はそのプロセッサを設計、製造、そして販売するからである。ARM はその設計をただライセンスするだけであり、それらの多くは安価な低電力設計である。

しかし、Apple は成功裏にその ARM ベースのプロセッサをスケールアップし Intel のプロセッサと競争出来るまでにした。この ARM のビジネスモデルのお陰で、Apple は競争力のある部品を遙かに安く作ることが出来、その利益も自分のものに出来る。

関連する合理化

同じプロセッサを全ての Apple 製品で使えれば、全社的にはより効率的であろう。Apple のハードウェアチームは、唯一つのプロセッサアーキテクチャー、一つのメモリコントローラー、そして一つの I/O システムをサポートするだけで済む。Swift や Objective-C の様な上位レベルの言語で書かれたアプリの殆どは、あまり改修を必要としないであろう。ブートコードやデバイスドライバーの様な低位レベルのソフトウェアは共有することも可能となるであろう。開発ツールや App Store は、単一命令セットアーキテクチャーを目指せば、合理化出来るであろう。

勿論、これらの節約が目に見える様になる迄には数年かかるであろう。その間、Apple は Intel-based Mac をユーザーや開発者のために数年間はサポートするであろう。

移行はどの様なものになるであろうか？

Apple による IBM の PowerPC アーキテクチャーから Intel x86 への移行は比較的短時間で終わった - 全 Mac ラインが１年以内に切り替わった。Apple は ARM への切り替えもその様に短時間でやれるかも知れないが、同社はもっと時間をかけて進めるかも知れない。最も分かり易い顧客利益は MacBook Air の様なより小型のラップトップで実現されるであろう。ARM-powered MacBook Air は、その Intel 前任機よりもより強力で、電池寿命も長く、一方でより薄型で、より軽量となり得る；成功間違いなしの組み合わせである。現在の iPad の ARM SOC はもう既に多くの Apple のラップトップラインの Intel プロセッサよりも強力であり、全ての Apple ラップトップを ARM に変換するのは意味をなす。

Mac mini は MacBook Pro の上級機よりも強力だと言うわけではないので、同じ ARM プロセッサが使える。iMac の、そしてとりわけ iMac Pro のユーザーは、今日出荷されているどんな ARM チップよりも強力かなプロセッサを欲しがるであろう。と言うのも、目標は現在出荷されている製品に追いつくことではなく、それを追い越すことだからである。iMac の用途に見合うだけの力を持つ ARM チップであれば、Apple の直近のロードマップの中で対応出来るのではなかろうか。

問題は Mac Pro で、こちらは高価格帯の Intel Xeon プロセッサに依存している。勿論、Apple が対応可能な ARM プロセッサを開発するのは不可能ではないであろう - 問題は、どれぐらいの時間がかかるかであろう。また、このとても高価な Mac Pro の販売量はかなり低いと思われる。何を言いたいかというと、そのために開発されたカスタム ARM SOC は、その開発コストを担いきれるだけの量をそれ自身で売るのは現実的ではないと言うことである。Apple は、それを ARM への移行の全コストの一部として見做さなければならないであろう。

Apple が、どんな Intel Mac であれ、それを売りそしてサポートする限り、同社は２つのバージョンの macOS、２つのコピーの全てのアプリ、２つのセットの Xcode 開発ツールと App Store 基盤を作成し、テストし、そして維持していかなければならない。これには相応のコストがかかる。一旦移行が始まったら、Apple は Intel 時代を可能な限り速やかに通り過ぎたいと思うであろう。

これまでの移行では (Motorola 68000 から IBM PowerPC, そして PowerPC から Intel)、Apple は以前のプロセッサファミリーにために書かれたアプリを走らせるために、オペレーティングシステムの中にエミュレータを含めた。Apple が新しい ARM Mac 上で Intel アプリを走らせるエミュレータを用意するであろうと想定するのは理に叶うであろう。これ迄のエミュレータはほぼ完璧に動いたし、ARM 上の Intel エミュレータでも事情は同じであろう。

しかし、新しい ARM チップを十分に活用するには、サードパーティ開発者は彼らのアプリを ARM のために再コンパイルし、アップデートを App Store に提出しなければならないであろう。多少の小さな変更は必要になるかも知れないが、手がかかりすぎるということはないであろう。App Store は LLVM 中間言語でエンコードされたアプリを受け入れるので、開発者は彼らのアプリの一つのコンパイルバージョンを提出すればよく、それを App Store は少し違う ARM プロセッサを持つ iPhone モデル用に翻訳する。しかし、LLVM 中間言語は、Intel アプリを ARM アプリに翻訳出来るほど強靱ではない。

Windows はどうなる？

ARM 移行の犠牲者は Microsoft Windows 互換性かも知れない。現行の Mac は Windows PC と同じ Intel プロセッサを使っており、Windows とそのアプリを最大速度で走らせてくれる。Apple は Boot Camp を使うことで Mac を Windows PC としてブートするのを容易にしているし、VMware Fusion や Parallels Desktop の様なサードパーティ仮想化製品は macOS の内部で Windows を走らせる。もし Mac が Intel チップを持たないようになったら、Windows はネイティブには走らせられなくなるであろう、少なくとも Intel プロセッサ用にコンパイルされた主流バージョンは。

他の選択肢も幾つかある。Apple の Intel x86 エミュレータも Windows を走らせるのをサポートするかも知れない。かつて、PowerPC Mac 用の Windows エミュレータがあったが、本物の PC 上で走る Windows にはとてもかなわなかった。その性能は、Windows でなければならない時折のタスクには十分かもしれないが、ゲームや他の本格的な使用には恐らく満足を得られないであろう。

更に、Microsoft は ARM 用の Windows を自社の Surface Pro X 用にリリースしているが、多くのサードパーティ Windows ソフトウェアは ARM 互換バージョンとしては出されていない。声を上げる少数派の Mac Windows ユーザーはいるかも知れないが、Apple の注意を引くほどには多くないであろう。

将来は ARM

ARM Mac の正当性には抗しがたいものがある。長期的に見れば、Apple が二つのプロセッサファミリーをサポートするのは理に合わないので、いずれ Mac 製品群は全て ARM に移行すると思われる。もし ARM への移行が PowerPC や Intel の時の様に円滑に行くのであれば、顧客にとっては、得るものは多く、恐れるものは殆どない。

討論に参加

Mac のメニューバーにさまざまな機能を追加するアプリにはあらゆる種類のものが存在しているけれども、プラグインのシステムを通じてメニューバーに文字通り 何でも 追加することのできるアプリを私は見つけた。名前を BitBar というこのアプリは、無料でオープンソースだ。私は macOS 10.14 Mojave と 10.15 Catalina の双方でこれをテストしてちゃんと働くことを確認した。

初めて BitBar を起動すると、プラグインを保存しておくディレクトリを選ぶよう求めてくる。私は iCloud Drive の中に BitBar フォルダを作って、どのマシンでも手軽にプラグインを同期して使えるようにした。これは期待通りに働くし、たぶん Dropbox や Google Drive でも同じように働くと思う。

BitBar ウェブサイトにはコミュニティーの人たちが作ったプラグインを集めた豊かなライブラリが含まれている。天気や、株価や、暗号通貨の価格や、電子メールメッセージ、Slack 通知、その他考え得る事実上あらゆるものを表示するプラグインが集まっている。飼い猫が部屋の中にいるか外にいるかを示すものさえある。プラグインをインストールするのはそのプラグインライブラリページにある Add to BitBar ボタンをクリックするだけという手軽さで、それだけでそのプラグインがあなたが指定したプラグインフォルダにインストールされる。

BitBar のプラグインはすべて、単純なテキストベースのシェルスクリプトだ。プラグインを削除したければプラグインフォルダの外へ出してからメニューバーで BitBar を Control-クリックし、Preferences > Refresh All を選べばよい。(私はプラグインフォルダの中にある Archive フォルダに入れることでプラグインを無効化している。) 同じように、どのようなシェルスクリプトでもプラグインフォルダの中へドラッグしてから Refresh All を選べば利用できるようになる。BitBar を Control-クリックしてから Preferences > Open Plugin Folder を選べば、素早くプラグインフォルダにアクセスできる。

BitBar の良いところは、Terminal の中で動作するスクリプトはすべて BitBar プラグインになれることだ。単純なシェルスクリプトも、Python スクリプトも、Ruby スクリプトも、正しいフックが入ってさえいれば AppleScript でさえ使える。そのことはまた、入手したプラグインをどのテキストエディタででも開いて簡単に変更を加えられるということも意味しているし、たとえそのスクリプティング言語にそれほど馴染みがなくても、スクリプトに示された実例をヒントに小さな変更を加えるだけで自分でいろいろ調整を施せるということをも意味する。実際、そういうことはいたるところで実行されている。

BitBar プラグインに変更を加えて自分の望む動作を得る

想像してみよう。欲しいことに似たことができるプラグインを見つけたけれども、自分の望みとはちょっとだけ違っている。ここで嬉しいのは、プラグインに簡単に変更を加えられることだ。

例えば私は、Got Internet? プラグインを入手して、その ping_address 変数を 8.8.8.8 (Google DNS) から tidbits.com に変更し、さらに表示するテキストを TidBITS ウェブサイトに接続可能ならば "TidBITS 👍"、接続できなければ "TidBITS 👎" を表示するように変更した。

皆さんが便利に使えるかもしれないちょっとしたハックをご紹介しよう。 Simple RSS Reader プラグインをインストールして、そのファイルを開き、FEED_URL 変数がデフォルトで http://feedpress.me/sixcolors?type=xml となっているのを https://tidbits.com/feed/ に変更するのだ。これで、メニューバーから最新の TidBITS 記事すべてにアクセスできる！

それからまた、私は Coinbase Prices プラグインにも変更を加えた。デフォルトでこれはたくさんの暗号通貨を表示するのに、私が一番興味を持っている Chainlink は表示されない。そこで私はコードの中の dash_price 行を単にコピーして、ブロックの最後のところにペーストし、それを link_price に改名するとともに、Coinbase URL の中の DASH-USD を LINK-USD に変えた。そして最後に、echo $link_price 行を末尾に追加した。これは文字通り猿真似のスクリプティングで、そのスクリプトは私にはそれほど馴染みのない Python で書かれていたのだが、施した変更は期待通りに働いた。ただし、価格の横に素敵なアイコンが表示されるようにはならなかったが。

私が最も大幅な変更を加えたプラグインは、そしてこれこそ私を BitBar に導いてくれたスクリプトだったのだが、mpd-control だ。iTunes/Music に音楽ライブラリを引っ掻き回されるのが嫌になって、私はコマンドラインベースの mpd ミュージック・プレイヤー・デーモンを実験的に使い始めていた。このデーモンには数々のフロントエンドが出ていて、私は Terminal ベースの ncmpcpp を気に入ったのだが、音楽を一時停止する度に Terminal ウィンドウに切り替えなければならないのがどうにも面倒に感じられていた。デフォルトで、この mpd-control プラグインは現在再生中のトラックを表示し、それをクリックして音楽を再生・一時停止できるようにする。これに十分単純な変更を施して、私はコマンドを並べられるメニューを作り、再生/一時停止、次のトラックや前のトラックへの移動、それに ncmpcpp を Terminal ウィンドウで開くコマンドを並べた。

私ほどにはオタクでない人向けには iTunes Now Playing という素敵なプラグインもあって、メニューバーから音楽の再生をコントロールできる。

極端な例を一つ挙げておくと、私は Linux で使っているスクリプトを使ってメニューバーからsee the weather forecastようにしている。驚いたことに、このスクリプトは事実上何の変更を加える必要もなくそのまま動作した。ただ、私はそこに変更を加えて、Terminal を開いて curl wttr.in を走らせるオプションを追加しておいた。それを使えばコンソールベースの天気予報が開く。

BitBar でプラグインを作成する

ここで、BitBar プラグインを一から作成するのがどれほど簡単かをご紹介しよう。シェルスクリプトのことを何もご存知ない方にもちょうど良い入門方法になるのではないかと思う。なぜなら、大したリスクを冒すこともなくシェルスクリプトと macOS のネイティブなインターフェイスを統合できるからだ。それに、学ぶのなんか嫌だという人も、誰かをおだてて、または誰かにお金を払って、必要とするプラグインをその人に作ってもらうこともできる。

何もないところから始める必要もない。BitBar の説明書には徹底的な実例がいくつも付属しているし、プラグイン・ギャラリーの中にはチュートリアルのプラグインさえあって、さまざまのアイデアを例示しつつ、心ゆくまで変更を加えられるようになっているからだ。けれどもここでは、私が何もないところからプラグインを作り上げた手順をご紹介することで、それがどんなに単純なことかをお見せしたいと思う。

Terminal を /Applications/Utilities から開く。心配ご無用、何も恐ろしいことなんかしない。まずは date とタイプして Return を押そう。すると現在の日付と時刻が表示される。

これを BitBar に入れるのは簡単だ。私は BBEdit を開いて次のようなシンプルなスクリプトを作り、それを date.sh と名付けた。

#!/bin/bash
date

最初の行の #!/bin/bash は、システムに対してこれがスクリプトだと知らせる。いったんこのテキストファイルを実行可能にしさえすれば (その方法はすぐ後で述べる)、macOS はこれをプログラムだと認識してその後に続くものすべてを Terminal コマンドとして実行する。次の行は単純に date コマンドを呼び出す。つまり、Terminal の中に date とタイプすれば日付と時刻が表示され、そのコマンドを BitBar スクリプトに入れても同じことが起こる。

スクリプトのファイルを実行可能に設定する方法は、Terminal に慣れていない人にとっては少し手ごわく感じられるかもしれないが、別に難しいことではない。プログラムとして走らせるためには次の作業をしなければならない。

1. Terminal を開く。
2. Finder で BitBar のプラグインフォルダを開く。
3. Terminal で、スクリプトを実行可能にするためのコマンド chmod +x  をタイプする。(x の後に必ず空白文字を入れておく。)
4. Finder のウィンドウから date.sh のアイコンをドラッグして、Terminal の中へドロップする。これでディレクトリパスが挿入される。
5. Return を押す。

それから BitBar を Refresh すれば、これでもう日付と時刻がメニューバーに表示される。

Terminal で man date とタイプすれば date コマンドのマニュアルページが読める。その中に、出力をカスタマイズする方法の実例が書いてある。自由にいろいろ試してみよう。

では、日付をクリックしたら Calendar アプリが開くようにするにはどうすればよいのだろうか。簡単にできるのだが、いくらか作業が必要だ。スクリプトに BitBar アクションを追加するために使う特殊なフォーマッティングのフックがあって、BitBar の GitHub ページにリストされている。ただしこれらは echoコマンドのコンテクストでしか動作しない。echo コマンドというのは、Terminal の中でテキストや変数の値を表示するためのシンプルな Unix コマンドだ。

そこでまず初めに、私はスクリプトを変更して date コマンドの出力を変数 MYDATE に割り当てた。つまり MYDATE=$(date) だ。(等号の左右に空白文字がないことに注意！) 記号に恐れおののいてはいけない。これはただ単に MYDATE という名前の変数を作っているだけのことだ。ドル記号とそれに続く括弧により、date コマンドの出力をその変数に割り当てよという命令がシステムに伝えられる。

次に、BitBar に日付を表示してそれをクリック可能にせよと指示する行を作った。ここで単に echo $MYDATE とだけ書けば、変数 MYDATE の内容が表示されるだけだ。それではさっきのものと何も変わらない。でも、ここではそれに続いて特殊な BitBar フックを書いて、次のようにした：

echo "$MYDATE | href=file:///Applications/Calendar.app"

まず、これは変数 MYDATE の値を echo する。(シェルスクリプトでは、変数の名前の前にドル記号 ($) を付ければその変数を参照することになる。) けれども私は引用符に挟まれた中に、MYDATE 変数だけでなく BitBar 特定のコマンドを、パイプ記号で区切って含めた。HTML に馴染みのある方なら href コマンドをご存知だろう。リンクを指定するためのものだ。私はこれで Calendar アプリへのリンクを作った。

Refresh をした後には、日付をクリックすると Calendar アプリが開くようになった。ここまでで作ったスクリプト全体を書くと次のようになる：

#!/bin/bash

MYDATE=$(date)
echo "$MYDATE | href=file:///Applications/Calendar.app"

それでは、コマンドを並べたメニューを作るにはどうするのか？ それには、BitBar プラグイン・スクリプトの中のどこにでも echo "---" を追加すればよい。けれども、このプラグインの現在の状態では、クリックすると Calendar が開いてしまうのでメニューが出ることはない。そこで、クリック可能でなかった状態にいったん戻す必要がある：

#!/bin/bash

date
echo "---"

では、どんなコマンドをそのメニューに入れようか？ まずは、クリックすれば Calendar アプリが開くリンクを入れておこう。こんな感じだ：

echo "Calendar | href=file:///Applications/Calendar.app"

ここで私がしているのは "Calendar" という単語を echo してから前の例で使ったコードでクリックすれば Calendar アプリが開くようにしているだけだ。

そこで私たちのプラグインの最終形態は次のようなもので、これは日付を表示した上で、メニューを出してそこから Calendar アプリを開けるようにする：

#!/bin/bash

date
echo "---"
echo "Calendar | href=file:///Applications/Calendar.app"

表示される時刻が少し遅れることに気付くかもしれない。デフォルトで、個々の BitBar プラグインは毎分１回ずつ更新をする。これを変えたければ単にタイムスタンプをファイル名に追加すればよい。例えば date.1s.sh のような名前にすれば毎秒の更新になる。date.1h.sh にすれば毎時の更新、date.1d.sh にすれば毎日の更新になる。詳しくは BitBar の説明書をご覧頂きたい。

ここで述べた基本的な例をもとに、いくつかの方向に拡張することもできる：

• 日付のフォーマットを変更する
• 他のカレンダーアプリ、例えば Fantastical や BusyCal を開く
• Date & Time 環境設定枠へのショートカットを作る

Bookmarks プラグインを作る

普段私は複数のウェブブラウザを切り替えて使っているが、ブックマークを同期させた状態を維持するのはなかなか面倒なものだ。Alco Blom の URL Manager Pro を使ってもよいのだが、自力でやってみたいという気持ちがあるので、各行に URL を１個ずつ入れたシンプルなテキストファイルを使うのが良い解決法になるのではないかと思い始めた。BBEdit などのテキストエディタでは普通、手軽に URL を開けるようになっている。(例えば BBEdit では URL を Command-クリックすればそれがデフォルトのブラウザで開く。) でも、BitBar を使っているうちに私は気づいた。「ちょっと待て、リンクのリストをプラグインにしたらいいんじゃないか」と。やってみると結構簡単にできることが分かったのだが、現在のところ私はこれをさらに完璧なものにすることを目指して磨きをかけているところだ。

この線で作ってみた最初のプラグインは極めて基本的なものであった。まず私は URL のリストを作ってそれを ~/Documents/urls.txt に保存した。(やってみようと思う方は、お好きな名前でどこでもお好きな場所に保存すればよい。)

それから、次のようなスクリプトを作った：

#!/bin/bash # システムにこれがスクリプトだと告げる

LINKFILE=~/Documents/urls.txt
# これで LINKFILE という変数を作り、私の URL リストを指し示す。
# この方が、コードの中で直接リストを参照するよりもクリーンだ。

echo "URLs"
echo "---"

この２行は BitBar に対して、表示すべき名前を "URLs" とし、echo --- でメニューを出すように告げる。

ここからが面白いところだ。作っておいた URL リストを読み込んで、個々の行を echo するとともに、それがリンクであることを BitBar に告げるコマンドも含めなければならない。

while read line; do
    echo "$line|href=$line"
done <$LINKFILE

重要なのは最後の部分 <$LINKFILE だ。これはシェルに対してそのファイルのすべての行を while ループの中へ読み込むように告げる。while read line というのは普通の言葉に翻訳すれば「まだ処理していない行がファイルにある間はずっと、その行を読み込んで変数 line に保存する」という意味だ。その次の do は文字通り「せよ」という意味で、何をするかといえばまずその行つまり $line を echo してから、パイプ記号の後の href= を実行する、つまり BitBar に対してその後に続くテキストがリンクだと告げる。その２番目の $line は単純に BitBar に対してタイトルとして表示した $line が URL の $line であることを告げる。この場合、リンクのタイトルとリンクの URL は同じ文字列になっている。

実際に使ってみると、このように見える：

これで十分使えるけれども、私としては生の URL が表示されるよりも記述的な名前が表示される方が望ましいと思えた。それに、私は多数のブックマークを持っているのにスクリーン上の面積は限られている。そこで私は Markdown ベースのブックマークファイルを作って記述的な名前を指定するとともに階層構造を持つメニューを作れるようにしようと心を決めた。その種のテキスト処理には正規表現を使うことが必要で、シェルスクリプトの中でそれをする最もシンプルなやり方は sed コマンドだが、私はあまり詳しくない。仕方なく私は sed コマンドについてさんざん Google 検索をした挙句、まあまあ使えるスクリプトを書くことができた：

#!/bin/bash

LINKFILE=~/Documents/SyncThing/links.md

echo "Bookmarks"
echo "---"

while read line; do
    [ -z "$line" ] && continue
    LINKNAME=`echo $line | sed 's/^.*\[//;s/\].*$//'`
    LINK=`echo $line | sed 's/^.*(//;s/).*$//'`
    echo "$LINKNAME|href=$LINK"
done <$LINKFILE

このコードは、最初に作ったブックマーク用スクリプトとそんなに大きくは違っていない。まずはリンクのリストを循環するのだが、今回は Markdown ファイルを読み込んで、各行ごとに sed を使ってタイトルまたは URL を抽出し、それぞれを変数に入れる。それから LINKNAME 変数を echo して、BitBar に対して LINKURL に保存された URL へリンクするように告げる。while ループの最初のところにある [ -z "$line" ] && continue という行は、シェルに対して空白行をスキップするように告げる。

LINKNAME や LINK に割り当てられたコマンドの前後にあるバッククォート文字 (`) に注意して頂きたい。この文字は macOS に対して、単なる文字列ではなくそのコマンドの結果を割り当てるように告げる。

このようにした結果、問題点が一つ残った。BitBar がサブメニューを扱うやり方が変なのだ。Markdown では、見出しは次のようになる：

#Bookmarks
[TidBITS](https://tidbits.com/)
[TidBITS Talk](https://talk.tidbits.com/)
[The Prepared](https://theprepared.com/)

##News
[Slashdot](https://slashdot.org/)

１個の # はトップレベルの見出しを意味し、２個の ## はサブ見出しを示す、という具合になっている。ところが、BitBar で使えるようにするためには、Markdown の URL リストを次のように書き換えなければならない：

[TidBITS](https://tidbits.com/)
[TidBITS Talk](https://talk.tidbits.com/)
[The Prepared](https://theprepared.com/)

News
[--Slashdot](https://slashdot.org/)

こうすれば "News" というのがサブフォルダの名前になり、項目をそのサブフォルダに入れるためにはその項目の名前の前に２個のダッシュ文字を入れなければならない。もちろん、Markdown 見出しの下にある行の数を数え、# 文字を削除し、見出しの下にある項目のそれぞれの名前の前に -- を付ける、という作業をするスクリプトを書くことは可能に違いないと思うけれども、私は sed や awk にそれほど詳しい訳ではない。(詳しい方がおられれば、教えて頂けるととてもありがたい。私から未来永劫なる正規表現の感謝をお捧げしよう。)

けれども、BitBar で実現された結果は素敵できちんとしたものだった。メニューからブックマークの一つを選べば、デフォルトのウェブブラウザでそれが開く。ブラウザを切り替える際には、どのブラウザがデフォルトかを切り替えるだけでブックマークがそのブラウザで開くようになる。

BitBar はあなたが望む何にでもなれる

BitBar でできることのいくつかについて、Terminal やスクリプティングに慣れていないという方々にも、大まかな考え方をお伝えできたとしたら嬉しい。過去に少しでも「これをメニューバーに置いておけたらいいのに」という考えが浮かんだことがおありなら、おそらく今は BitBar を使ってそれができるだろう。制限があるとすれば、それはあなたの想像力と、あなたかあなたがご存知の誰かがシェルスクリプトをどこまで駆使できるかとにかかっている。

もしも私が使ったり、作成したり、編集したりした BitBar プラグインに興味がおありなら、私の GitHub ページに置いてあるのでどうぞご覧頂きたい。

討論に参加