XcodeとiOSのアップデート
【要旨】
①iOSをアップデートしたらXcodeのバージョンを確認する習慣を身に付けよう。
②Xcodeのアップデートには時間がかかることを気に留めておこう。
■■■■■■■■■■■■■■■
また作業が止まってしまいました。
iOS 13.2にアップデートしたiPhone XS Maxでアプリの動作を確認しようとしたら、転送中にXcodeが落ちる症状が発生。
Mac App Storeを覗いてみてもXcodeのアップデートは来ていません。
一応iPhoneを再起動しつつ、Mac App StoreでXcodeを検索してXcodeのページを開くと、「開く」ボタンが「アップデート」ボタンに変化しました。
Xcodeのアップデート来てたんかいっ。
重要なアップデートは漏らさず通知してほしいです。
Xcodeを11.2にアップデート、これがいつものようにそこそこの時間がかかります。
差分だけをインストールしてくれているはずだと思いますが、重いですね、データ量も、インストール作業も。
Mac App Store上ではインストールが完了したように見えても、アクティビティモニタで確認すると「mds」や「installd」といったプロセスが忙しそうにしています。
このような状態を無視すると後々、よくわからんけど何かパソコンが変な気がする、という症状にいつか出会すと私は信じているので、これらのプロセスが大人しくなるまで待ちます。
急がば回れ。
■■■■■■■■■■■■■■■
Xcodeをアップデートできたからよしっ、とはいきません。
iPhoneがbusy状態で接続待ちです。
「iPhone is busy: Preparing debugger support for iPhone
Xcode will continue when iPhone is finished.」
意訳
「接続準備中だよ。完了したら続きはするから待ってね」
「is finished.」するまで、これまた結構な時間が必要でした。
最後にXcodeと接続して以降、
・iOSのバージョンを変更していない (iOS 12.4.1) iPhone 7は数秒
・iOSを12.4.1 → 12.4.2にアプデしたiPhone 6は数分
・iOSを13.1.2 → 13.2にアプデしたiPhone XS Maxは1時間以上
の間、「is busy」状態でした。
いつも思うけど、「Preparing debugger support」って何をしているのだろう。
■■■■■■■■■■■■■■■
しばらく、ぼーっと眺めている間、興味深い現象がありました。
Macから10m以内、つまりBluetoothの圏内に置いているけど、画面は消灯したまま触れていないiPad (iPadOS 13.2) が、ConnectedとDisconnectedを行ったり来たりしていました。
iOS 13からの新機能「探す」の実装にあたって、Bluetoothを利用したオフラインでの追跡が可能になりましたが、その影響でしょうか。
macOS Catalina ヒラギノ角ゴ問題について
macOS Catalinaにおけるフォント問題について検索してみると、Chromeにおける事例ばかりヒットするので困る。
macOS Catalinaでは「ヒラギノ角ゴ ProN」は消滅したと思っていたら、Numbersでは「ヒラギノ角ゴ ProN」と「ヒラギノ角ゴシック」は別物として指定できるみたい。macOSをCatalinaにアップデートした後でNumbersをインストールしたから古い設定が残っているのではないはずなのに。何これ怖い！
というわけで、ヒラギノ角ゴ問題を調べてみました。誤りがあったらごめんなさい。
【ヒラギノ角ゴ ProNとは】
macOS Mojave以前のシステムフォント。太さはW3。
ちなみにiOSのシステムフォントは、英数部分がSF(San Francisco)、日本語部分がヒラギノ角ゴ ProNのW3。
【ヒラギノ角ゴの無印(StdN)とProNの違い】
ProNはStdNより収録文字数が多い。
ヒラギノ角ゴ ProNは
Adobe-Japan1-5規格、文字数20,317
ヒラギノ角ゴ StdNは
Adobe-Japan1-0規格、文字数9,354
【ProとProNの違い】
字形が違う。
ProはJIS90字形、ProNはJIS2004字形。
JIS2004は国語審議会の「正字」に準拠する字形。
例として、「蝕」の食偏の形が違う。
（個人的にはJIS90字形の方が現代的で馴染み深い気がするけど）
【macOS Catalinaで起きたこと】
ヒラギノ角ゴのStdNとProNが統合された。
例として、
旧ProNの太さはW3とW6の2種類だったのが、W0-9の10種類になった。
旧StdNのJIS90字形をJIS2004字形に変更。
など。
新しい名称は「ヒラギノ角ゴシック」となり「ヒラギノ角ゴ ProN」は消滅した。
【ユーザが目にしたこと】
「ヒラギノ角ゴ ProN」を指定しているソフトでは、違うフォントで表示される事態となった。
例えばVivaldiでは「Al Bayan」で表示された。（フォント一覧の一番上だからだと思う）
【Numbersのヒラギノ角ゴProN問題】
デフォルトのフォントは「ヒラギノ角ゴ ProN」。「ヒラギノ角ゴシック」を選択することもできる。
NumbersはmacOSをCatalinaにアップデートした後にインストールしたので、Mojave時の「ヒラギノ角ゴ ProN」設定が残っていたというわけではない。
Numbers上で「ヒラギノ角ゴ ProN」と「ヒラギノ角ゴシック」を比較してみたが差異を見付けることはできなかった。
どちらにせよmacOS Catalinaの新しい「ヒラギノ角ゴシック」を見ているらしい。
結論、よく分からん。
【感想】
「ヒラギノ角ゴ ProN」と「ヒラギノ角ゴシック」を統合した新しいフォント「ヒラギノ角ゴ2019」を作れば、混乱は少なかったのでは？
UISegmentedControl 外観整理
Xcode11 + iOS13ではUISegmentedControlの外観が変更されていましたので違いを整理しました。（こういうのは公式ドキュメントに含めてほしい！）
ダークモードやSwiftUIが来た現在では、外観変更は下記の範疇に収めるのが妥当かと存じます。
【追記 (19-10/13)】モバイル版の一部環境では、上の画像をフルサイズで表示できない場合があるようです。その場合はPC版表示できるブラウザでご確認ください。
【おまけ：選択解除】
iOS13では
segCon.selectedSegmentIndex = UISegmentedControl.noSegment
だけでは選択解除できません。
正確には、内部は選択解除されていますが外観に反映されません。
選択解除を外観に反映するためには
segCon.setNeedsLayout()
を追加する必要があります。
（これはバグの可能性があり、今後のアップデートで修正される可能性があります）
ELECOM マウス EX-Gシリーズ 静音化改造？
エレコムのマウスM-XGL10BBSとM-XGL10UBSを所有しています。
M-XGL10UBSのクリック音がおかしくなってきたので静音化しました。
結論として、静音化のポイントはよくわかりません。
分解して上部カバーを外し、カバーを捻って曲げ癖を少し変えてやっただけです。
クリック時の「コツ」音の、マウス内部の空洞での反響が変わったような感じで、購入時の音に戻りました。
代償として上部カバーの先端を押しても反応しなくなったので、持ち方を変える必要がありました。
クリック音のスペクトルを添付します。
クリック音の変化が視覚でわかると思います。
連続でボタンを押してコツコツと音を出しているときのスペクトルです。
中～高音が減ったことがわかります。
低音部の大部分は暗騒音です。
分解して再組立しただけでほとんど何もしていないようなものですが、大きな変化がありました。
上部カバーが軟質樹脂で成形されているマウスは、ただ分解組立するだけで性能が変化する可能性があることがわかりました。
これは製品製造時に個体差が出やすいということでもあると思います。
フォントメモ
「悲報、俺氏またフォント沼にハマる！」
マウス、ファイラー、テキストエディタ、そしてフォント。
私がこれらに求める条件は、そんなに特殊ではないと思っています。
けれど、条件の全てを備えてはいないので妥協が生じてしまう。
だから、何かのきっかけがあれば見直したいという欲求が再燃してしまいます。
Mac版のテキストエディタだけは例外で、CotEditorには全く不満がありません。
私にとってCotEditorは完全な神アプリです。
そんなCotEditorのアップデートが公開されたというツイートが目に入って、うっかりフォントの不満点を想起してしまいました。
フォントの見直しにおいて過去に確認したことの堂々巡りがあったので、メモを記しておきます。
【フォントの選択基準】
①用途：Xcodeと幾つかのテキストエディタ用
②等幅であること
③日本語フォントを含むこと
④可読性が高いこと（半角英数の可読性が優先）
【候補のフォント】
①MyricaM
②Source Han Code JP
③Osaka
【不満点】
①MyricaM
・全角フォント、特に記号の一部に可読性が悪い文字がある
・「“」と「”」（始と終）が見分けられない
②Source Han Code JP
・システムが等幅フォントに分類してくれない
・「～」と「〜」（全角チルダと波ダッシュ）が見分けられない
③Osaka
・MyricaMやSource Han Code JPに比べて可読性に劣る
・Mac専用（非公式のWin用Osakaがあるが低品質）
【結論】
MyricaMを使う。
【理由】
・「“」と「”」は入力時の変換候補（システムフォントで表示される）で識別できる。
・「～」と「〜」は入力時の変換候補では識別できないので、識別できるフォントを採用する必要がある。
・半角英において、MyricaMは可読性と美しさを備える。Source Han Code JPは可読性は高いが美しさに劣る。
・システムが等幅に分類しないフォントは一部のエディタで使えない。
例：TeraPadでSource Han Code JPを使えない
【備考】
Unicodeに非対応な一部のソフトでは、ファイル名に波ダッシュを使っていると不具合を生じる場合があります。
だから全角チルダと波ダッシュの違いを意識する必要があります。
最新のJIS規格では全角チルダも波ダッシュも「上がって下がる」曲線で表現するのが正しいようですが、例えば線の太さを変えるなど、何らかの識別方法が欲しいと思います。
macOS Catalina、Sidecarの「非」すゝめ
Sidecarの使い方や解説という記事はたくさんありますが、大切なことが記載されていない場合があるようです。
見落とされがちな重大事項、それは。
「Apple IDの2ファクタ認証がオンになっている必要があります」
公式ドキュメントはきちんと読まなければいけませんね。
macOS CatalinaとiPad OSでSidecarを使うことを楽しみにしていましたが、私は2ファクタ認証が大嫌いなのでSidecarを諦めることにしました。
一度Apple IDの2ファクタ認証を有効にすると、取り消すことができません。
これはとても重要なことです。
私は既にiPadを所有しているのに、うっかり予備のiPadを入手してしまいました。
けれどApple IDの2ファクタ認証を有効化しないことの方が重要なので、Sidecarは使わないし、従って予備のiPadは死蔵品とします。
