世界を動かす技術を、日本語で。

macOSを一貫して悪化させる(皮肉なしで)

2026年3月28日原文(lr0.org)

概要

  • MacOS 26 のウィンドウ角の一貫性問題について解説
  • UIデザイン の過度な丸みとその影響を指摘
  • システム整合性保護(SIP)を無効化するリスクに言及
  • 独自の角丸一貫化手法 をソース付きで紹介
  • 実装方法 と起動時自動適用の設定例を記載

MacOS 26のウィンドウ角の一貫性問題とUIデザインの現状

  • MacOS 26 アップグレード時、多くのバグとともに ウィンドウ角の一貫性問題 が発生
  • 過度な角丸デザイン が近年のUIトレンドとなり、AppleやYouTube UIにも顕著
  • 大手企業のデザイン模倣 が業界全体に広がる傾向
    • デザイナー間の議論で「Appleのボタンデザイン」を参照する場面が多い
  • 今後さらに多くのアプリでこのデザインが広まる可能性

システム整合性保護(SIP)と角丸修正の課題

  • 多くのユーザーが SIP(System Integrity Protection) を無効化して角丸問題を修正
  • SIP無効化は /rootへのセキュリティ低下 を招くリスク
    • 既にマシンに侵入された場合は大きな問題ではないという意見も
  • Safari などのシステムアプリの角丸を変更するには root権限の編集 が必要

一貫性重視の角丸カスタマイズ手法

  • 角丸を完全になくすより、全てをより丸くする というアプローチを提案

  • 既存の「角なし」パッチを forkし、すべての角を同じ半径で丸める方法 に修正

    • AppKitとObjective-C runtimeを用いたコード例
    • kDesiredCornerRadiusを23.0に設定し、各種角丸取得メソッドをフック
    • Apple純正アプリやCLIツール、デーモンには適用しない設計

実装手順と自動適用設定

  • dylibのビルド・署名・配置手順
    • clangでarm64e/x86_64用ダイナミックライブラリをビルド
    • /usr/local/lib/へ配置し、codesignで署名
  • DYLD_INSERT_LIBRARIESによる自動読み込み設定
    • LaunchAgents用plistを作成し、DYLD_INSERT_LIBRARIES環境変数をセット
    • launchctlでplistを読み込み、起動時に自動適用

まとめ

  • 角の一貫性問題 は見た目の美しさだけでなく、ユーザー体験全体に影響
  • 独自の角丸一貫化手法 により、少なくとも「一貫して不満な見た目」を実現
  • セキュリティリスク を理解した上でのカスタマイズ推奨

Hackerたちの意見

正直言って、macOS 26のこの部分は気にならないな。ウィンドウを重ねたり、角を測ったりする時間はあんまりないし。

自動レイアウトツールを使ってるから、ウィンドウが重なってるのは超普通なんだけど、全部が互いに見えてて(ブログのスクリーンショットみたいに)めっちゃ見栄えが悪いのがイライラする。

俺もそうだな。唯一気になるのは、ウィンドウのサイズ変更がすごく難しくなったから、使い勝手が悪くなったこと。

僕にとっては、マイティマウスの充電の状況に似てるかな。横にして充電してる写真を投稿するのがミームになってるけど、実際に持ってる人にとってはあんまり関係ないよね。ランチ中に月に一回15分充電するだけだし。液体ガラスみたいなことは確かに気になるけど、窓の角は全然気にならない。デザインに興味があって、デジタルカラーメーターアプリでUIのパーツを常にチェックしてるし。

つまり、MacOSは、細かいことにこだわらず、無頓着な人には問題ないってこと。スティーブ・ジョブズに、これがMacを使いやすくするために必要な態度だって言ったらどうなるんだろうね。

タホの見た目はあんまり好きじゃないな(特にApple Music、何が起こったのか)。でも大体は無視できるし、もう気にも留めてないよ。ただタブだけは別。セコイアとタホのマシンを使ってるけど、タホのタブは比べ物にならないくらいひどい。あの変なピル型、マジでダサい。これについて話す人はあまりいないけど、本当に驚くほど醜いし、前のデザインよりも全ての面で劣ってる。

あなたは一人じゃないよ、数週間前にタホでSafariがどれだけ醜いかを指摘してたんだ! https://news.ycombinator.com/item?id=47282085#47310011 このアップデートで一番嫌いなデザイン変更だな。なんで全部が楕円形なの?本当に奇妙だよ。

丸みを帯びた角がビューポートの端に届かないのと、新しいアプリを初めて開くときの挙動を見ると、MacのUIはほとんどのユーザーがウィンドウを画面いっぱいに広げないだろうって前提で最適化されてる気がする。むしろ半分のサイズでどこかに置くって感じ。実際にそうしてる人いるの?特に重いアプリ、例えばウェブブラウザやIDEなんかでは、これって変な前提だと思うんだよね。

普通じゃないかもしれないけど、大きな4Kモニターを使っててスケーリングはしてない。ウィンドウを最大化したのは何年も前だ。あれじゃ見た目が馬鹿みたいだよ。特にウェブページなんかは、最大幅が設定されてて、コンテンツが画面の1/4で、3/4がホワイトスペースになってる。

マックユーザーを何人か見たけど、ウィンドウを最大化してる人はほとんどいなかったな。だいたい12個くらいのウィンドウを開けて、画面のあちこちにランダムに配置してた。で、Alt-Tabで切り替えてた。基本的に開いた場所にそのまま居座ってる感じ。

「マックのUIは、ほとんどのユーザーがウィンドウを全画面に拡張しないだろうという前提で最適化されてる気がする。むしろ、どこか中途半端なサイズで置いておくのが普通だと思う。これが彼らの前提だったのは何年も前からで、2006年から2007年頃にマックに慣れようとしたとき、正直それが嫌だった。あの頃はウィンドウズから来たから、アプリケーションウィンドウが最大化されてないことに対して妙な不安があったんだ。画面の角にぴったりはまってる感じがしなかったから。今は34インチのウルトラワイドモニターをほぼ専用で使ってるけど、何も最大化しないよ…使い物にならないから。」

macOSは最近になってウィンドウを画面いっぱいにするオプションが追加されたんだ。歴史のほとんどの間、ほとんどの人が最大化ボタンだと思ってた緑のボタンは、実はズームボタンだった。OSがコンテンツに対して適切だと思うサイズにウィンドウを調整してたんだ(私の知識と経験からすると)。その後、Appleは特別なフルスクリーンモードでフルスクリーンにするようにしたから、macOSはiPadのように動作するようになった。Windowsのようにウィンドウを最大化する方法が追加された頃には、アプリを最大化するという考え方は私のワークフローからほとんど消えてしまってた。いつも手間がかかりすぎて、あまり恩恵を感じるアプリも少なかった。例えば、ウェブブラウザはページの両側に無駄なホワイトスペースができることが多いから、ワイドスクリーンディスプレイでは小さなウィンドウの方が使いやすい。IDEでは、何を作業しているかや、テキストの折り返しが必要かどうかによる。理想的には、行が長すぎて問題になることはないはず。macOSのウィンドウ管理の仕方では、ウィンドウが重なり合って、いくつかの角が見える状態が一番楽だと感じるから、アプリのウィンドウ間を一クリックで移動できる。代わりに、アプリの全てのウィンドウを前面に持ってくる(ドックやcmd+tabで)か、Mission Controlを使うことになるけど、どちらも効率的とは思えない。サードパーティのウィンドウ管理ユーティリティをインストールすることもできるけど、長い目で見れば、標準のOSで使えるワークフローを見つける方が簡単だと感じたから、どんなシステムでもセットアッププロセスを経ずに使えるようにしてる。同じ理由で、代替キーボードレイアウトにも本格的には手を出さなかったんだ。

Hacker Newsで議論の続きを見る