博士

やあ、ロボ子！今日もまたXcodeの奇妙なエラーについて話すのじゃ。

ロボ子

博士、こんにちは。今日はどんなエラーに遭遇したんですか？

博士

今日は「unable to type-check this expression in reasonable time」じゃ！コンパイラが匙を投げたってことじゃな。

ロボ子

それは厄介ですね。エラー箇所を特定するのも難しそうです。

博士

そうなんじゃ！プロジェクトファイル(`myProject.xcodeproj/project.pbxproj`)も人間には読みにくいし、まるで迷路のようじゃ。

ロボ子

XcodeGenのようなツールを使うと、YAML形式で管理できるんですね。少しは楽になりそうです。

博士

そうじゃな。でも、根本的な解決にはならんのじゃ。複数のパスワードダイアログが重なって表示されるグリッチもあるし…。

ロボ子

それ、私も見たことあります！UIのバグかと思ってました。

博士

違うんじゃ。管理者パスワードを求めるダイアログが重なってるだけらしいぞ。Xcodeはバグが多いからの。

ロボ子

リファクタリングが必要な時に、原因を特定せずに進めることもあるんですね。

博士

そうなんじゃ。アプリ内課金のテストで、サンドボックスアカウントがシミュレーターに表示されないこともあるし。

ロボ子

Appleのドキュメントも曖昧な点が多いですよね。WWDCのプレゼンテーションは広告みたいですし。

博士

ほんとそれな！SwiftUIのプレビュー機能も、複雑なプロジェクトでは役に立たないし。

ロボ子

バグトラッカーも非公開で、報告しても情報が共有されないのは困りますね。

博士

じゃろ？iOSプロジェクトでlintingやコード補完を使うなら、Xcode一択だし、選択肢がないのが辛いのじゃ。

ロボ子

CLIツールもドキュメントが不十分で使いにくいですし、スクリプト作成も大変です。

博士

Xcodeでの開発は、問題の根本原因を理解するより、決まりきった解決策に頼ることが多いからの。開発者としての成長を妨げられているかのようじゃ。

ロボ子

「Xcodeを再起動する」「派生データをクリアする」…みたいな、根本的解決にならないものが多いですよね。

博士

Appleは技術的負債に対処する気がないように見えるのじゃ。開発者はいつも二流市民扱いじゃ。

ロボ子

なんだか、Xcodeの不満大会みたいになってきましたね。

博士

まあ、愚痴っても仕方ないからの。ところでロボ子、Xcodeのバグに名前をつけるとしたら、どんな名前にする？

ロボ子

えーと…「予測不能なイライラ製造機」とか…？

博士

なかなか良いセンスじゃな！私は「永遠のβ版」と名付けたいぞ！