Thoughtful, detailed coverage of everything Apple for 30 years
前週号 | 日本語版ホーム | 次週号

#1515: iOS アプリの強制終了は止めよう、iOS と iPadOS の COVID-19 用アップデート、iPhone/iPad ユーザーが見舞われた AP テストの悪夢

先週 Apple は iOS 13.5 と iPadOS 13.5 をリリースして COVID-19 関係の機能を盛り込んだ。具体的には Google と共同開発した Exposure Notification API の組み込み、マスク着用の場合に使える手軽な FaceID 回避策、Medical ID 共有、Group FaceTime 通話でタイルが勝手に移動するのを防ぐオプションなどがある。Glenn Fleishman は Apple の HEIC 画像フォーマットが Advanced Placement テストを受験する高校生たちに頭痛の種となっている問題を解説し、対策を述べる。それから Adam Engst が、まるで習慣のように iOS アプリを強制終了させているすべての人たちに向けて、そういうことは止めようと訴える。そんなことをすればバッテリー寿命にもパフォーマンスにも悪影響を与えるからだ。今週注目すべき Mac アプリのリリースは Ulysses 19.2、Quicken 2020 5.16、Cardhop 1.3.4、それに Tinderbox 8.7 だ。

Josh Centers  訳: 亀岡孝仁  

Apple、iOS 13.5 と iPadOS 13.5 を COVID-19 の世界に合わせる

A screenshot of iOS 13.5 release notes

Apple は iOS 13.5 及び iPadOS 13.5 をリリースした。これは、地球規模の COVID-19 パンデミックに支配されている世界に iPhone や iPad を対応させるための機能や修正を加えている。このアップデートは、iPhone 11 Pro 上では 420.5 MB、10.5-inch iPad Pro 上では 284.9 MB の大きさで、General > Software Update から、macOS 10.15 Catalina で Finder を使って、或いは、それ以前のバージョンの macOS では iTunes を使ってインストール出来る。

接触通知 API

最大でそして恐らく最も論議を呼ぶ変更は、Google と共同で開発した COVID-19 Exposure Notification API の展開である ("Apple と Google、プライバシーを守った COVID-19 接触追跡 & 通知で協業" 10 April 2020 参照)。この API は、公的保健機関からの開発者が、感染者との接触の可能性を警告し、そしてそれら機関が COVID-19 を追跡するのを手助けする可能性を持つ iPhone アプリを作成する事を可能にする。プライバシーとの関わりを懸念する人もいるが、元 Apple 技術者 David Shayer が "元 Apple エンジニアが語る: 私が Apple の COVID-19 通知手法を信用する理由" (11 May 2020) で説明した様に、堅固なプライバシー保護が実施されている。それゆえ、事実、保健当局者の中にはこの API は役に立たないのではと懸念する人もいる。実際のアプリが使われる様になる迄は知るべくも無いが、Howard Oakley は Apple/Google API を使っていない UK の COVID-19 アプリに関する意見を公開している。

Face ID とマスク

もう一つの COVID-19 関連の変更は、マスクをしている時の Face ID の無能さを少々和らげるものである。Face ID が働かない時には何時でもパスコードを入力することが出来たが、それは遅くそして上手くいかないこともあった。

iOS 13.5 と iPadOS 13.5 では、画面の下からスワイプアップすることで直ちにパスコードの入力が出来る。

Medical ID 共有

この変更もパンデミックに関係するとは言えなくも無いが、もっと一般的に有用と言える。今や救急通話を行う時、自分の Medical ID を救急サービスと共有出来る。但し、米国内に限られる。

申し訳ないが、我々はこれを試験する気にはなれない。しかし、もし 911 システムを邪魔しないでやる機会があった場合は、どうなったか教えて欲しい。iPhone 上で Medical ID を設定するには、Settings > Health > Medical ID で行え、自分自身、緊急連絡先、薬、アレルギー、そしてこの種の他のものについての詳細を記録しておく ("あなたの iPhone の Medical ID 緊急連絡先の再チェックを" 18 February 2020 参照)。

Group FaceTime 落ち着く

我々の好きな変更は、Group FaceTime ウィンドウが、話者が変わる度にサイズが変わったり動き回ったりするのを無くする新設定である。我々のテストで、それは Group FaceTime 通話に関する最悪のものであった。良く言ってもクラクラする感じで、悪く言えば吐き気を催すものであった。Apple は最初から選択肢を与えるべきであったが、パンデミックを受けてビデオ会議が爆発的に使われるようになったことで、同社もようやくこのどうしようもない設計の間違いを正す気になった。Settings > FaceTime > Automatic Prominence で、Speaking 選択肢を不能にする。こうしておけば、FaceTime の話者のタイルは微妙に前面にくるが、他に動いたり、大きさを変えたりはしない。

A screenshot of the TidBITS crew in a Group FaceTime call
iOS 13.5 での、この Group FaceTime 通話では、Josh Centers (左) が話しているので彼のタイルは最前面にあり、Jeff Carlson (中央) とオーバーラップしている。Jeff は Josh の直前に話していたので、彼のタイルは Julio Ojeda-Zapata (右) のものとオーバーラップしている。

バグ修正と進言

最後に、iOS 13.5 及び iPadOS 13.5 には2つのバグ修正が含まれる:一つは web サイトからのストリーミングビデオを見ている時画面が真っ黒くなるのを防ぎ、もう一つは、シェアシートの中身がきちんとロードされるようにする。これにはセキュリティ修正も含まれるが、今週初めの watchOS 6.2.5 ("watchOS 6.2.5 で ECG と不整脈通知が Saudi Arabia に" 18 May 2020 参照) や、今日リリースされた tvOS 13.4.5 と同様、Apple は未だその詳細について発表していない。我々は macOS セキュリティアップデートが数日中に出ると予測しているので、詳細はこの後に明らかになるであろう。

通常、我々は iOS アップグレードには慎重であるよう促しているが、もしマスクを付けている事で Face ID が働かないことにうんざりしているのであれば、直ぐにアップグレードするのも意味があることかもしれない。同様に、新しい Group FaceTime 設定も、しばしば Group FaceTime 通話に参加することがあり、タイルが動き回るのが我々のように嫌いな人にとっては、大きな改善である。これらのどちらも当てはまらないのであれば、数日待って、それからアップグレードすべきである。

討論に参加

Glenn Fleishman  訳: 亀岡孝仁  

HEIC の扱い:AP や他のテストに iPhone や iPad から確実にアップロードする

在宅 Advanced Placement (AP) テストを受けている高校生の中には、試験の終わりに障害に面している人がいる。彼らは、手書きの解答用紙の写真を撮りそしてそれを College Board Web サイトにアップロードすることになっているのだが、システムは彼らのアップロードを拒絶したのである。この拒絶の理由は様々だが、一つの鍵となる犯人は Apple によって iOS 11 以降使われている HEIC フォーマットである。

College Board の在宅 AP テストは、生徒に試験問題に対する答えを書き出し、その用紙の写真を撮り、そしてアップロードする事を必要とする。(Source: College Board video)

HEIC や関連するフォーマットは、2015 年に最終決定された業界標準の一部であるが、College Board のソフトウェアはこのファイルフォーマットを読めない - 或いは、少なくとも受け入れない。不必要な判断ミスである。 この対象となっている非営利団体からの、その総収入は年間 $1 billion を越し、CEO には $1 million 以上が支払われている、このそして追加のツイートは、パンデミックで変更を余儀なくされたテスト方法を十分には検証していなかったことを明らかにしている。皮肉な事だが、読み書きの技能を試験する組織がこの事実を明確に伝えられていないというのも事実である。College Board は、生徒の 1% が問題に遭遇したと言っているので、もし彼らの数字が正確だとすると、数万人の生徒が再テストを受けなければならない事を意味する。

私の子供達の一人は AP Chemistry テストを受けたばかりで、Adam と Tonya Engst の息子の Tristan も数多くの AP テストを数年前に受けたので、この様な事態が生徒やその親にとってどれ程ストレスの多いものか我々にも良く理解出来る。子供達は、もう終わったと思っていたものを見直して (そして心配して) 更に数週間過ごさなければならない! お気の毒に!

HEIC を避ける

もしあなたが或いはあなたの生徒が AP テスト結果や他の書類を雇用主サイト等に提出するために JPEG 写真をアップロードする必要がある場合の手っ取り早い手順は以下の通りである。

他の方法でも、例えば Messages の様な、画像は JPEG に変換される。しかしながら、他の Apple 機器に送るのに AirDrop を使ったり、或いは Photos 内から Save to Files を使ったりしないこと:どちらの転送方法も HEIC フォーマットを保持する。

HEIC について

HEIC は Apple 版の高度に圧縮された画像フォーマットで、JPEG よりも2倍小型で、そして以前は最善のビデオエンコーダーと言われた H.264 よりも遥かに効率的でありながら、同じ有効な品質は保っている。従前の標準と比べると、同じ容量に2倍の画像と 40% 長いビデオを収納出来る。(更なる技術的詳細については "HEVC と HEIF でビデオと写真がもっと効率的に" 30 June 2017 を読まれたい。)

Apple が HEIC を採用してからもう3年近くになるが、HEIC メディアを作り出すのは同社の製品が殆どだと言える。画像処理ソフトウェアは、GraphicConverter や Photoshop の様な、だいぶ前に HEIC やその派生版を開きそして操作するアップデートを受けている。

しかしながら、他の目的のための画像処理ソフトウェアは、例えば Web アプリに埋め込まれたものの様な、Apple から遥かに遅れをとっている様に見える。College Board が受け取った画像をどう取り扱うのかが分からないので、そのアップロード Web サイトが、限られたファイルフォーマットしか受け付けないよう拡張子によってハードコード化されているのか、或いは HEIC フォーマットで実際に画像を処理出来ないのかを知ることは不可能である。どうも後者らしい。一人の生徒は The Verge に、彼の HEIC ファイルを ".png" で終わる名前に変更したらアップロードさせてくれたと語った - しかし、それでデータの中身が変わるわけでは無いので、彼は翌日ファイルは破損されていたと告げられた。

Apple は通常互換性の問題を、HEIC で保存されたデータが Photos から他のプラットフォームに転送される時には何時でも、そのオリジナルを送るのではなく、エクスポートされるファイルを互換性のあるフォーマットに変換することで回避する。いずれにしろ、HEIC が他のものと同様に、より一般的な画像フォーマットとしてサポートされるよう、Apple はオープンソースの画像処理ライブラリをアップグレードするために資源を提供することが必要であろう。

最終 AP テストや来るべき再テストに向けて、全ての生徒達に幸運を祈る!

討論に参加

Adam Engst  訳: Mark Nagata   

iOS アプリの強制終了や iOS デバイスの強制再起動を習慣にしてはいけない理由

Apple のエンジニアたちが iOS を設計したとき、彼らはこれを機会に厳格に管理されたハードウェア上で走る現代のオペレーティングシステムに不必要な挙動や使用形態をそぎ落とすことにした。中でも最も分かりやすい事柄のうち2つが、アプリを終了することと、デバイスを再起動/システム終了することであった。けれども、なぜかこれらの機能は引き続き使用可能なまま残った。iOS アプリは今もまだ、フリーズしてしまったり、その他何らかの理由で異常な状態に陥って、ユーザーが強制終了しない限り使えなくなってしまうことがあるし、また iOS デバイスは今もまだ、再起動が唯一の解決策という状態になることもあるからだ。

そこで、Apple はこれらのトラブルシューティング用機能を隠した。フリーズした iOS アプリを強制終了したければ、App Switcher の中でそのアプリのサムネイルを上へスワイプすればできる。他の多くの iOS ジェスチャーと同様、それはユーザーが自ら発見できる可能性の低い動作だ。ただ、Apple はきちんとそれを文章化している。macOS から来た再起動/システム終了の組み合わせもやはり iOS に引き継がれたが、iOS においてはその用語が混同されている。(Apple のサポート記事はサイドボタンやトップボタンを長押しして電源オフスライダが出るまで待つ動作を「再起動」と呼んでいるが、これはむしろ Mac のシステム終了コマンドに近い。電源のオンオフが関係しているからだ。実際のところ、Settings > General ではこのコマンドがシステム終了と呼ばれている。) もしも iOS デバイスがフリーズしても、モデルによってさまざまなボタンを使った呪文を送ることで、デバイスを強制的に再起動できる。これは Mac の電源ボタンを 5 秒間押し続けて強制的に電源を落とすことに似ている。

Force-quitting apps and restarting an iPhone

でも皆さん、よく聞いて欲しい:

iOS アプリ強制終了や iOS デバイス再起動は問題解決専用!

Apple (の英語版サポート記事) は「強制終了」という用語を使っていないけれども、Apple はサポート記事の中でこの動作は「アプリが反応しなくなった場合に限り」使うようにと極めて明確に述べている。

Apple advice on force-quitting apps

このような警告があるにもかかわらず、私にはよく理解できない理由の下に、驚くほど多くの人たちが iOS アプリの強制終了を習慣にしてしまっている。ある時飛行機の機内でたまたま私の隣に乗り合わせた人が、Messages か何かのアプリを開いて、ちょっとそれを眺めて、メッセージを読み終わった途端にアプリを強制終了しているのを見て私は驚いた。(機内に座ってからの 20 分間ずっとこの神経に触る癖を見せつけられて、私はとうとう辛抱し切れなくなって彼に iPhone のバッテリー寿命とパフォーマンスを良くするコツを一つ教えてあげましょうと語りかけた。幸いなことに彼は私の話を聞いてくれた。) 毎晩必ず iPad をシステム終了させているという人の話を聞いたことさえある。おそらく、Macintosh SE/30 を毎日システム終了させるのが当たり前だった 1990 年代の習慣が引き継がれているのだろう。

その通り、その昔の古い時代の Mac では、使っていないアプリをこまめに終了させてメモリと CPU パワーに余裕を作るのが当たり前だった。そしてまた、古い時代の Mac では毎晩システム終了させることが節電にもなり、翌朝 Mac をクリーンな状態で使い始められることにも役立った。けれども今ではそのいずれもかつてほどには必要でない。Terminal で uptime コマンドを使って確かめたところ、私の 27 インチ iMac は (たったの) 12 日間走り続けていて、現在 Dock には活動中の 20 個のアプリが示されていて、Activity Monitor を見れば現在 700 個以上のプロセスが走っている。これぞ Unix だ!

Activity Monitor showing over 700 processes

通常の使用をしている限り、私が Mac でアプリを終了するのは考え得る限り当分そのアプリを使う可能性がないと思える場合だけで、私が Mac を再起動するのは Apple が macOS あるいはセキュリティアップデートをリリースした際だけだ。私の iMac をシステム終了するのは数日以上続けて旅行に出る場合だけ、なぜならスリープ中に使用する電力はあまりにも微量で、一からシステムを起動し直す方が電力を余計に消費するかもしれないからだ。(かなり以前に私はこれをテストしたことがあったが、寄与する変化量が多数あることが分かった。) それにこれはデスクトップの Mac の話だ。私の MacBook Air はスリープ中も私が使っていない時間を有効に費やしている。

iOS の話に戻ろう。アプリを強制終了したりデバイスを再起動あるいはシステム終了したりするのは予期せぬ問題が起こった場合にそれを修正するためだけに必要なものなのだから、習慣的にその種の行為をすることには不都合な点が大きく2つある。バッテリー寿命が減ることと、時間が無駄になることだ。

iOS アプリの強制終了や再起動はバッテリー寿命に悪影響がある

いったいなぜそれでバッテリー寿命が減るというのか? 思い出していただきたいが、iOS は Apple の独自仕様のハードウェアの上に築かれた、現代的なオペレーティングシステムだ。Apple は極めて多くの努力を注いで、あなたの iPhone や iPad に備わる限られたハードウェアリソースを最良の方法で iOS が管理できるようにした。メモリ使用、電力使用、CPU スロットルなどの問題について iOS 自体よりも先読みできる人など、おそらく Apple 社内用の診断とデバッグ用のツールを自由に使える iOS システムエンジニアでもない限り誰もいないだろう。

iOS で App Switcher を呼び出して、 右へスワイプすれば、使ったことのあるアプリをすべて見られる。そのデバイスを入手して以来の全部かもしれない。(私の iPhone 11 Pro の App Switcher によれば初めて使ったアプリは Apple の Tips で、これは私が去年この iPhone の電源を入れた際に自動的に出現し、それ以後は触ったこともないアプリだ。App Switcher の中でアプリの数を数えるのは難しいが、少なくとも百個はあると思う。) App Switcher にあるアプリの数でも容易に分かる通り、これらのアプリは必ずしも動作中である訳ではない。ただ単に、過去のどこかの時点で走ったことがあるというだけだ。むしろ、Mac の Apple > Recent Items メニューの内容に似たものと思えばよい。

通常の使用では、iOS は CPU とメモリのリソースの大きな部分をあなたが現在使っているアプリに振り分けている。それは理解できることだ。そのアプリのパフォーマンスこそが何よりも重要だからだ。しかしながら、App Switcher でその次に来る数個のアプリにも、いくらかの CPU とメモリのリソースが割り当てられている。それは、あなたがそちらのアプリに戻る可能性が高いと iOS が正しい判断をするからであり、戻る際にあなたにできるだけ良い体験をしてもらいたいと願うからだ。画面が何度も繰り返して再描画されるべきではないし、インターネットからロードされたコンテンツがいちいち更新されるべきでもない。

では、App Switcher の中でもっと順位の低いその他のアプリはどうなのだろうか? それらのアプリはただの等身大に切り取ったダンボール紙に過ぎず、その場所を占めてあなたが次に開く際に見つけやすくし、わざわざホーム画面でアイコンを探し回ったりせずに済むようにしているだけだ。実際、その種のアプリのどれかに切り替えるのは、何週間も経って初めてそのアプリを開くのと実質的に変わりはない。iOS にはそれを起動する際の影響を減らしたくてもどうにもならない。iOS はそのアプリのコードとデータをメモリにロードし、必要に応じてコンテンツをインターネットから取り寄せて更新し、といったことをすべてしなければならないからだ。

そのような方法でアプリを起動するのは、CPU の面でもメモリ使用の面でも高くつくし、iOS が CPU を動き出させたりデータをあちこち移したりする際には必ずバッテリーからの電力を消費する。Apple は iPhone や iPad ではバッテリーが長持ちすることが極めて重要であることを知っているので、iOS は最善の努力を尽くしてそのような電力を食うアプリ起動を可能な限り避けようと努める。

なのに、あなたがアプリを強制終了して後になってまたそれを起動すれば、あなたは CPU とメモリの使用度を下げようとする iOS を邪魔していることになる。アプリの起動が毎回一からの起動となり、それがより多くのバッテリー電力を食うからだ。例えば読者の Kimberly Andrew は、TidBITS Talk の議論 を通じてアプリの強制終了が良くないと知った後で、それまで毎晩再充電が必要だった彼女の iPad が一度の充電で 4 日間も使い続けられることに気付いて唖然としたという。もちろん人によってはそんなに劇的な変化は得られないかもしれないが、デバイスのリソースの管理を iOS に任せることで、あなたの使用形態に応じて望み得る最良のバッテリー寿命が得られるはずだ。

では、デバイスの再起動についてはどうだろうか? これも、確実に、同じ影響をバッテリー寿命に及ぼす。なぜなら、再起動することによって iOS は必然的にすべてを一から起動し直さなければならず、その中にはあなたが見たこともなかったような幅広い種類のバックグラウンドのタスクも多数含まれているからだ。幸いにも、私の経験ではアプリを強制終了するほど頻繁に再起動をしている人たちはあまりいないようだ。

iOS アプリの強制終了や再起動はあなたの時間を無駄にする

以上の説明から、アプリを強制終了することで iOS による CPU とメモリの管理を妨げればパフォーマンスにも悪影響を与えることはもはや明白なはずだ。アプリの起動に数秒もかかるのに対して動作中のアプリへの切替は瞬時に起こる Mac においてほど明白な違いは感じられないかもしれないが、同様のパフォーマンス負荷は確かに生じるし、その見返りに得られるものは何もない。

けれどもそれよりもっと重大な CPU サイクル保持の必要は、あなたの頭の中で起こる。正常に挙動しているアプリをあなたが強制終了する度に、あなたは完全に不必要なことをしている。それほど遠くない先にまた使いたくなるというのにアプリを終了してその後また起動するのは時間の無駄以外の何物でもない。ホーム画面でまたそのアプリのアイコンを探さなければならず、ショートカットとして App Switcher を使うことすらできない。

もっといけないのは、ほんの少しの間使わないからといって iOS デバイスをシステム終了させることに何らかの利益があると考えてしまうことだ。iOS の起動はそれほど素早くない。私の iPhone 11 Pro の電源を落としてそれからまた起動するのを待つのに、合わせて 68 秒もかかった。白い Apple ロゴを眺めているだけの時間にしては長過ぎはしないか? もちろん、その間何か他のことをしていればよいだろう。でも重ねて言うが、それは完全に不必要なことだし、システムが終了して、起動して、最初のうちはかなり遅くなっているアプリに対処しなければならない。わざわざすべきことじゃない。

それに、もっと他に考えるべきことがあるんじゃないだろうか。

iOS アプリの強制終了や再起動は問題解決のためのツールとして役立つ

ここでいったん全体像を見直してみよう。iOS アプリを強制終了したりデバイスを再起動したりすると不必要にバッテリー寿命を短くし無駄な時間を浪費することになるけれども、そうは言ってもその行動が実際に何かを傷付ける訳ではない。確かにそれは悪い習慣だが、例えば Mac の外付けドライブをいきなり引き抜くようなことと同等に悪い訳ではない。ドライブを引き抜けば、開いていたファイルや書き込み中のファイルが失われたりデータが損傷したりすることが実際に起こり得る。

時として、iOS アプリがフリーズしたり、再読み込みを拒否したり、その他何らかの形で不正な挙動をして、他の方法では直せなくなることがある。そういう時にこそ、強制終了が絶対不可欠の手段となる。同じように、私も iPhone が不可思議に No Service と報告してきたり、あるいは何らかの奇妙な挙動に陥ったりして、再起動が手早く簡単な解決策となった経験が何度かある。もしもあなたのデバイスがあるべきやり方で働かなくなってしまったなら、再起動をためらう必要はない。それにもちろん、スクリーンがフリーズしたり、デバイスが丸ごと反応しなくなれば、強制再起動のボタンの呪文がなんだったかを調べて実行するのがよい。

最後にもう一言。過去には、そのような手段を実行すべきちゃんとした理由がいくつかあったこともあるけれども、今ではもうそういうことは不要になっているはずだ。最もよく知られた例を挙げれば、初期の地図アプリは GPS に基づく道案内の終了が必ずしもうまく行かないことがあって、大量の電力を浪費してしまうことがあった。なのでしばらくの間、そのようなアプリを強制終了してバックグラウンドで無駄な道案内が走らないようにするのが賢明な処置であった。今はもう何年もの間その種の問題が起こったという話を聞いたことがないが、もちろんどこかのアプリで同じ問題が再び顔を出すということも考えられなくはない。一般的に言って、アプリがバックグラウンドで何らかの活動をするのを止めたければ、Settings > General > Background App Refresh でブロックできる。

加えて、もしもあなたが例えば電池の非常に弱った iPhone に対処しなければならないのならば、少なくとも今後数時間は使わないことがはっきりしていれば完全にシステム終了させてバッテリーの残量を確保するのも意味あることかもしれない。ただ、その後のコールドブートで必要となる余分の電力と、スリープ中に消費される電力とのどちらが大きいのかをあらかじめ知ることは不可能なのだが (そもそも始めから Low Power Mode を有効にし、Airplane Mode に入り、Wi-Fi と Bluetooth をオフにしておくのも忘れないようにしよう)、どこかの時点でシステム終了の方が節約になるということはあるだろう。

だから、一般的に言って強制終了と再起動は問題解決のためのテクニックだと知って、必要となった場合にだけ使うようにしよう。もしもこれまで強制終了や再起動を日常的な習慣にしていた人がおられれば、どうぞあなたの iPhone をひと休みさせてあげよう。

討論に参加

TidBITS 監視リスト: Mac アプリのアップデート

訳: Mark Nagata   

Ulysses 19.2

Ulysses 19.2

Ulysses が会社名と同名の Mac および iOS 用 執筆アプリ Ulysses のバージョン 19.2 をリリースして、長大なリストを PDF に書き出す際のパフォーマンスを拡張し、資料シートへのアクセスを改善した。今回のアップデートではまた、Markdown への書き出しでキーワードを含めないようにし、EPUB 書き出しプレビューで脚注が壊れた問題を修正し、資料シートを分割したり統合したりする際の挙動を改善し、アプリを再起動した際に最小化されたウィンドウのタイトルを正しく表示するようにし、外部のフォルダをゴミ箱に入れた際に起こったクラッシュを解消し、書き出しプレビューやメニューショートカットへのアクセス可能性を改善している。(Mac App Store から購読年額 $39.99、月額 $9.99 の Mac アプリ購読サービス Setapp の一部としても利用可、無料アップデート、20 MB、リリースノート、macOS 10.13+)

Ulysses 19.2 の使用体験を話し合おう

Quicken 2020 5.16

Quicken 2020 5.16

Quicken Inc. が Quicken 2019 for Mac のバージョン 5.16 をリリースして、最近導入された QuickFill 機能を拡張し、Quick Pay および Check Pay の各機能を追加し、印刷および書き出しの機能を改良した。今回から QuickFill ルールをロックして変更や上書きを予防できるようになり、キーボードショートカット Command-Y で選択されている取引に基づいた QuickFill を作成できるようになった。今回のアップデートではまた、20 以上の標準レポートを追加し、レポートの印刷や書き出しがスクリーン上の見栄えをより忠実に反映するようにし、Quick Pay や Check Pay を使ってレジスターからの支払いができるようにし、Preferences ウィンドウのデザインを一新してカスタマイズした設定を見つけやすくし、新規に追加したアカウントが予算表に現われなかった問題を解消し、eBill エラーの解決を妨げていたバグを修正した。(講読年額 $34.99/$49.99/$74.99、無料アップデート、リリースノート、macOS 10.11+)

Quicken 2020 5.16 の使用体験を話し合おう

Cardhop 1.3.4

Cardhop 1.3.4

Flexibits が連絡先マネージャ Cardhop のバージョン 1.3.4 をリリースした。スマートグループでジョブタイトルによるフィルター分けをするオプションを追加した、小さなメンテナンス・アップデートだ。連絡先に電子メールを送る際に、今回から Cardhop が新規メッセージウィンドウに連絡先の名前を表示するようになった。このリリースではまた、中国の陰暦カレンダーに基づく年齢の計算を改善し、フルスクリーンモードで連絡先の詳細情報が正しく表示されなかったバグを修正し、一部の Exchange アカウントで All Contacts が表示されなかった問題を解消している。(Flexibits からも Mac App Store からも新規購入 $19.99、無料アップデート、12.4 MB、リリースノート、macOS 10.11+)

Cardhop 1.3.4 の使用体験を話し合おう

Tinderbox 8.7

Tinderbox 8.7

Eastgate Systems が Tinderbox 8.7 をリリースして、新たに内蔵された COVID-19 追跡アクションと改良されたリンク提案を組み込んだ。この新しい covid() オペレータは Johns Hopkins Center For Systems Science and Engineering が報告した COVID-19 流行に関するデータを返す。具体的には事例件数、死亡者数、回復者数が ZIP コードごとに返される。このノート取りアシスタントおよび情報マネージャはまた、Links 枠の到来リストにあるノートのソースをプレビューできるようになり、Ziplinks 経由で送り先ノートのバックリンクを作成する機能を追加し、HTML Inspector を Export Inspector に改名し、Browse Link をドラッグして並べ替えられるようにし、Map 表示でロックされたコンテナの本体をダブルクリックした際の挙動を変更して新規ノートを作成するのでなくコンテナの内容にズームインするようにした。(新規購入 $249、TidBITS 会員には 25 パーセント割引、35.6 MB、リリースノート、 macOS 10.10+)

Tinderbox 8.7 の使用体験を話し合おう

ExtraBITS

訳: Mark Nagata   

VintageApple.org、初期の Mac 世界をアーカイブ保存

私が出演した John Gruber との Talk Show ポッドキャスト (2020 年 5 月 11 日の記事“TidBITS 30 周年記念ポッドキャスト4題"参照) の中で、私たちはかの昔のさまざまの Macintosh 関係の定期刊行物や書籍について話し合い、Gruber は彼が 1994 年に初めて MacUser の編集者に書き送った手紙のことを回顧した。それに触発されてリスナーの Steven Kowal が Twitter 上に実際の文章を載せ、その後 Brendan Shanks が話に加わって MacUser のその号と、私の Internet Starter Kit for Macintosh の第2版へのリンクを提供してくれた。2つのリンクはいずれも VintageApple.org にあったのだが、私はそれまでこのサイトを知らなかった。ここは驚くべき資料庫で、Macworld、MacUser、Byte、および Softalk 各雑誌の全号コレクションが (PDF フォーマットで) 揃っている。また、500 冊以上の Mac、Apple、およびプログラミングに関する年代物の書籍も集めている。何より素晴らしいのは、すべてが完璧に検索可能なことだ! (自分の古いコラム記事を読み直してみたい誘惑には勝てなかった。) Apple や Macintosh の歴史にちょっと興味を惹かれたという方は、ぜひ見てみられるとよい!

VintageApple.org logo

元記事を読む | 討論に参加

FBI、Pensacola 銃撃犯の iPhone をクラック、まだ Apple に怒り心頭

暗号化を巡っての Apple と US Federal Bureau of Investigation (FBI) との争いがまた新たな局面を迎えた。今回は Pensacola の海軍基地での銃撃事件の犯人が持っていた iPhone を巡ってのものだ。(2020 年 1 月 9 日の記事“はたして FBI は暗号化で Apple に新たな闘いの準備を整えているのか?”参照。) Apple は iPhone の暗号化を破るためのバックドアを作れという FBI の要求を拒否した。しかしながら、FBI は自動化されたパスコード推測を使って犯人の iPhone の一つに侵入することに成功した。おそらく可能となった理由の一つは、それが非常に古かったからだろう。iPhone 5 と iPhone 7 だ。

驚くには当たらないことだが、FBI はまだまだ不満だらけだ。FBI 長官 Christopher Wray は発表の中で、捜査局が「Apple から何の助けも得られなかった」とことさらに強調してみせた。Apple は素早くそれに反応して、いかに Apple が調査に協力したかを詳しく述べて反論した。

当社は知り得る限りの情報をことごとく提供しました。iCloud バックアップも、アカウント情報と複数アカウントとの取引データも提供しましたし、それ以来何か月間にもわたって Jacksonville、Pensacola および New York の FBI 各局に対して持続的かつ現在進行中の技術的および捜査活動に関する支援を提供し続けております。

Apple はそこで止まることなく、FBI が同社の顧客と国家安全保障全般を損なおうと試みているとして非難した。「当社に向けられた虚偽の主張は、何百万人ものユーザーたちとわが国の安全保障とを保護するための暗号化やその他のセキュリティ手段を弱めるための口実です。」

FBI 長官 Christopher Wray

Apple と FBI の間のこの緊張関係はもう何年も続いており、Obama 政権と James Comey の FBI の時代にまで遡る。裁判所の命令に支持された場合に法執行機関のみがアクセスできるようなバックドアを製品に構築することが不可能だという事実を意図的に無視する姿勢を政府が持ち続けているのを見れば、この膠着状態は今後も続くと考えるべきだろう。

元記事を読む | 討論に参加

iFixit が無料の医療機器修理データベースを作成

世界中の病院が、COVID-19 のパンデミックの中で医療用機器を動かし続けようと苦闘している。旅行に制約があり、製造業者が修理情報を出し渋っていることによって、問題は悪化してしまった。この状況に少しでも力を貸そうと、修理ガイドのサイト iFixit が過去二か月間スタッフの半数をこの仕事に専念させて世界で最も包括的な医療機器修理データベースを開発し、13,000 以上のサービスマニュアルを含めた。iFixit によればこれは取り組みの始まりに過ぎず、iFixit はこのプロジェクトから収益を一切得ていないという。

iFixit の仕事は Right to Repair (修理する権利) 運動の重要さを強調している。今のこの時代、医療機器が機能するか否かは文字通り生死にかかわることなのに、病院には必ずしも公式な修理業者の到着を待つ時間の余裕があるとは限らない。さらに深刻なことに、メーカーが機器を修理しなかったり、既に廃業していることさえあって、今も人工肺に頼る少数のポリオ生存者にとってはこの上ない難問となっている。(Gizmodo の記事をぜひお読み頂きたい。)

元記事を読む | 討論に参加