macOS 26のウィンドウ角、いっそ全部ダサく統一する

 (lr0.org)
4 ポイント 投稿者 GN⁺ 2026-03-28 | 2件のコメント | WhatsAppで共有
  • macOS 26にアップグレードして最も不快なのはバグ以上に ウィンドウ角の不一致 問題であり、過剰な丸みそのものよりも、アプリごとに異なる適用による一貫性の欠如が本質
  • 従来の解決策は SIPの無効化 を要求し、セキュリティ上の脆弱性につながる可能性があり、Safariのようなシステムアプリのライブラリを直接修正しなければならないため複雑
  • SIPを無効化せず サードパーティアプリにのみ適用 するアプローチとして、NSThemeFrame クラスのメソッドを置き換え（swizzling）、すべてのユーザーアプリの角丸半径を 23.0 に統一
  • dylibをコンパイル・署名した後、LaunchAgents plist を通じて起動時に自動注入する方式で恒久的な適用が可能
  • 結果としてすべてのアプリウィンドウが同じように丸くなり、「一貫して悪いデザイン」だが統一された視覚効果 を得られる

問題の背景

  • macOS 26ではさまざまなバグに加えて ウィンドウ角の不一致 問題が目立つ
  • 過度な角丸そのものより、アプリごとに処理が異なる 視覚的一貫性のなさ のほうが不快な要素
  • UIデザインは伝染性が高く、デザイナーが大企業のデザインをそのまま追随する傾向があり、この現象がさらに広がる可能性がある
    • 例: デザイン論争の際に「Appleはこのボタンをどう描いたか」で決着をつけるような業界慣行

従来の解決方法の問題点

  • 一部のユーザーは SIP（System Integrity Protection）の無効化 でこの問題を解決しようと試みている
  • SIPを無効化すると /root ディレクトリの保護が失われ、システムアプリ（Safariなど）が使用する システムライブラリの直接修正 が必要になる
  • すでにマシンが侵害されている状況ならSIPの実質的な保護効果は限定的だという見方もあるが、セキュリティ上の脆弱性が生じる可能性自体は存在する

代替アプローチ: サードパーティアプリの統一

  • 角をなくす方向ではなく、すべてをより丸くする 方向で統一する方針を採用
  • SIPを無効化せずに ユーザーアプリ（サードパーティ）にのみ適用できるdylib注入方式を使用
  • 既存の角除去ソリューションをフォークして修正したコードを適用

技術実装

  • NSThemeFrame クラスの以下4つのメソッドを メソッド置き換え（swizzling）
    • _cornerRadius → 23.0 を返す
    • _getCachedWindowCornerRadius → 23.0 を返す
    • _topCornerSize → CGSizeMake(23.0, 23.0) を返す
    • _bottomCornerSize → CGSizeMake(23.0, 23.0) を返す
  • com.apple. プレフィックス を持つAppleのシステムアプリ、CLIツール、デーモンは適用対象から除外
  • arm64e および x86_64 アーキテクチャの両方をサポートする universal dylib をコンパイル

インストールと自動適用

  • clangでSafariCornerTweak.dylibをコンパイルして /usr/local/lib/ にコピーした後、codesign で署名
  • LaunchAgents plist（com.local.dyld-inject.plist）を通じて DYLD_INSERT_LIBRARIES 環境変数を設定
  • launchctl load ~/Library/LaunchAgents/com.local.dyld-inject.plist で登録すると、起動時に自動でdylib注入が適用される
  • 最終的にすべてのアプリウィンドウの角が同じように丸くなり、「一貫して悪いデザイン」だが視覚的には統一された結果 を得られる

関連記事

2件のコメント

 
cnaa97 2026-03-28

まだアップデートしてないまま..
 
GN⁺ 2026-03-28
Hacker Newsの反応

  • macOSへのアップグレード後、WindowServer が CPU を 100% 以上消費する問題が発生した。
    ファイル保存ダイアログではファイル名の貼り付けすらできず、Safari の URL 欄もおかしな動作をする。
    システム設定で 透明度を下げる、アプリごとのスペース分離を無効化する、Finder でデスクトップアイコンを隠す、といった方法で速度が少し改善した。
    バックグラウンドアプリの CPU 使用率を制限する App Tamer を勧める（WindowServer や kernel_task には効果なし）。
    最近の Apple には舵取り役がいないように感じる。ウィンドウを開いたりアプリを切り替えたりするたびに数秒待たされるのは深刻な問題だ。
    いつか AI が新しい OS を設計して、Apple・Microsoft・Google がまた競争するようになってほしい。

    • 「コンピューターは何十年も前より遅くなった」という意見には共感しない。私の経験では、今こそ 性能の黄金期 だ。
      M2 Air で数十個のタブやアプリを同時に開いても問題ない。昔は起動に 3 分、ゲームのインストールに 30 分かかったが、今は一瞬だ。
    • WindowServer の 100% CPU 問題は 原因 ではなく 症状 だ。特定のアプリがウィンドウ更新を過剰に要求したときに起きる。
    • すでに AI が作った OS を見ているが、正直 改善と呼ぶのは難しい と感じる。
    • 「Apple に舵取り役がいない」という言い方には同意する。今の macOS は スポーツカーではなく遅いはしけ のようだ。
    • QubesOS への移行を検討している。アプリと OS をサンドボックスで分離して実行でき、それでも macOS 26 より遅くない。

  • macOS Tahoe のデザインが気に入らない。特に Apple Music は理解できないほどおかしくなった。
    ただ大半は無視できるとしても、タブのデザイン だけはあまりにも醜い。以前よりあらゆる面で後退したように感じる。

    • 私も同意する。Safari のデザインがあまりにも 楕円形 になっていて違和感がある。以前のコメントでも触れた。

  • ウィンドウの角をめぐる論争がここまで大きくなるのは、macOS がそれだけ 完成度の高い OS だということかもしれない。
    Linux は大好きだが、こうした論争は結局ほめ言葉と見ることもできる。

    • ただし、こうした問題は 関心の分離に失敗している という根本的欠陥を示している可能性もある。こういうものが見えるなら、システム全体がハックのように絡み合っているということだ。
    • 角は些細な問題にすぎず、Finder のようなもっと大きな問題も多い。
    • 「小さな不満が多いのは良い OS の証拠」という論理は、Windows 11 のスタートボタン位置論争 にも適用できてしまう。つまり、論理的に説得力がない。
    • 本当の問題は、システムが 頑固すぎて ユーザーが気に入らない部分を変えられないことだ。
    • 人々が角にこだわるのは、目に見える問題 だからだ。本当の問題はもっと深く複雑だ。

  • macOS Tahoe の通知消去 があまりにも煩わしい。
    「Liquid Glass」ボタンの反応が遅く、通知が消えるまでにも遅延がある。音楽アプリのアップデートも最悪だ。

    • macOS のボタン反応は遅いが、iOS 26 ではさらに深刻だ。タップが認識されないコア UI が多い。
    • 私も通知がうっとうしすぎて、何年も前から全部ブロック している。
    • こうしたボタン反応の問題は 3 世代以上のバージョン で続いている。
    • クリックが 1 回から 2 回に増えた のも不便だ。
    • 通知ボタンは最初から ぐにゃっとして反応が鈍い 感じだった。

  • 人々は SIP(System Integrity Protection) に執着しているが、実際には ランサムウェア対策として何の効果もない。
    npm や pip のようなパッケージマネージャーを VM の外で使うなら、SIP を有効にしていてもそれ以上に危険だ。

    • もちろん、ネット上のアプリを何でも実行すれば危険だが、SIP はそれでも 差し引きでプラスのあるセキュリティ機能 だ。ユーザーがミスしないよう防いでくれる。
    • SIP は OS を保護 するのであって、ユーザーを保護するわけではない。サードパーティーアプリが rm を実行すればデータは消える。
      それでも SIP のおかげで セーフモードで起動して復旧 できる。

  • 私は Linux と Windows を半々で使っているが、こうした理由で Mac をメインにできない。
    Dock とフルスクリーンの挙動 があまりにも奇妙だ。ウィンドウを閉じてもアプリが動き続けているのも混乱する。

    • 最小化/最大化ボタンの位置が変わったのに修正できない のがたまらない。
    • ただ、アプリとウィンドウを分けて考えるとかなり便利だ。Dock の最小化を無効にしなければ問題ない。
    • 結局は 慣れの問題 にすぎない。変わった環境は誰にとっても不便だ。

  • こういう細かな部分に気づく人たちがいるのは良いことだ。彼らの 観察力 のおかげで、こちらも守られているように感じる。

    • Apple は以前、こうした細部をよく理解していた。ユーザーは意識していなくても、一貫性の崩壊 を無意識に感じ取って信頼を失う。
    • 私のように 神経過敏な傾向 がある人間には、こうした角の変化が実際につらく感じられる。

  • 今の macOS はまるで Harley Davidson と Volvo Truck が合併 してデザインを統合したような印象だ。
    ブランド統一のために妥協した結果物になってしまっている。

  • macOS の UI は、ウィンドウをフルスクリーンにせず 中くらいのサイズで浮かせて使うパターン を前提に設計されているように見える。
    しかしブラウザや IDE のように大きな画面を使うアプリには妙な前提だ。

    • こうした設計は古い伝統だ。昔はウィンドウが画面の端に触れていないと落ち着かなかったが、今は ウルトラワイドモニター を使うようになり、逆にウィンドウを小さめにしている。
    • macOS の 緑のボタン はもともと「最大化」ではなく「コンテンツに合わせて調整」だった。後になって本当のフルスクリーンモードが追加された。
      今ではウィンドウを重ねておいて ワンクリックで切り替える 方式のほうが効率的だ。
    • 私もウィンドウを絶対にフルスクリーンでは使わない。余白が多すぎて非効率 だからだ。
      ただ、新しい UI は空間の無駄が大きく、角をドラッグしてリサイズ するのがいら立つ。
    • 4K モニターを使っているが、フルスクリーンにすると Web ページの 3/4 が空白 になって見苦しい。
    • コンテンツに合わせてウィンドウサイズを決めるという哲学は昔は合っていたが、現代のプロ向けアプリ には不向きだ。

  • ピル型タブ(pill tabs) がいちばん気に障る。
    視覚的に散漫なうえ、情報伝達力も低い 奇妙なデザイン だ。