高度にカスタマイズされたUIと広範なアニメーションおよび超低メモリフットプリントのニーズを持つXIB/NIBファイルを使用すべきでない理由はありますか？
初心者として、私はXIBから始めました。それから私は彼らの中のすべてについては何もできないことに気づきました。私が望むように物事をカスタマイズするのは本当に難しくなり始めました。そのため、最後に、すべてのXIBを破棄し、すべてプログラムで実行しました。
ですから、誰かがXIBが良いかどうか私に尋ねるとき、私は一般的にこう言います。しかし、XIBを使用しない理由は他に何がありますか？
この理由ですべてをプログラムで行うことを好むiPhone開発者は私だけですか？
Interface Builderは、Mac（ひいてはiPhone）ソフトウェア開発の最大の資産の1つだと思います。GUIは視覚的です。ビジュアルインターフェイスを使用して作成してみませんか？IBは十分な柔軟性を備えているため、「汎用」コンポーネントを使用してインターフェイスをレイアウトし、必要に応じてそれらをサブクラス化できます。もちろん、独自のインターフェイスがある場合は、ビュークラスをサブクラス化してカスタム描画を実行する必要がありますが、インターフェイスをIBにレイアウトしてから、インスペクターを使用してクラスをカスタムサブクラスに簡単に切り替えることもできます。
正直なところ、それは便利さの範囲だと思います。すべてをコードで書くことに慣れている場合は、それを実行してください。プロジェクトをうまく設計すれば、新しいウィンドウを作成するのとほぼ同じ量の作業になるはずです。しかし、多くの人がGUIの世界に慣れていないので、nib/xibsはそこでうまく機能します。
正直なところ、XIBをベースとして頻繁に使用し、コードを使用して編集して、希望する特定の外観を得ることができます。個人の好み。
その点に関する特定の欠点については、xibからビューをロードした後にビューを構成するのが難しい場合があります。IBとコードの間に競合する設定があり、トラブルシューティングが面倒な場合があります。
これがリストへの質問です。xibを使用した場合のパフォーマンスへの影響は何ですか？必要になるまでメモリにロードされないので、プラスだと思いました。とはいえ、そのロード時間は長くなり、プログラムの速度が低下します。考え？
アプリケーションにある種の「標準」ビューがある場合は、XIBを使用してください。実際のカスタマイズが必要な場合は、外部コンテンツ（XML ...）に応じて、プログラムで行います。
私はXIBを使い始めましたが、今ではすべてコードになっているので、この方法の方が快適です。私はXIBに実際の問題を抱えていましたが、インターフェイスをすべてコードで記述することで、時間を大幅に節約できます。
コードについて私がよく見つけたのは、コントロールのイベント接続です。メソッド（メッセージ）の使用法を検索すると、コード化されている場合はそれらが見つかり、IBで設定されている場合は見つかりません。
一方、ビュー上にオブジェクトをレイアウトすることは、オブジェクトのサイズと位置を確認できるIBでははるかに簡単です。コードでこれを行う場合は、サイズと原点の設定を推測して実行し、調整を行ってから、もう一度実行してどのように見えるかを確認する必要があります。
すべてのナビゲーションが接続されている起動フェーズでUIController（UITabBarControllers、UINavigationControllersなど）を処理するときに、時間を大幅に節約できます。
XIBを使用してXviewControllerを構築し、IB、ラベル、画像などに必要なものを投入します。これは、ほとんどすべての種類のアプリで、数時間で概念実証を行うことができることを意味します。これは、IBの詳細を学ぶのに時間を費やすことを正当化するのに十分です。特にiPhoneでは、優れたUIのアイデアがたくさんありますが、シミュレーターから実際のデバイスに移動すると、すべて失敗します。
私の考えでは、「フレームを3ピクセル変更->コンパイル->ああ..さらに2ピクセル必要->2ピクセル変更-コンパイル」を実行するのに多くの時間を費やしていることに気付いた場合は、バランスを取るのが最善です。 ->ああ..IBで実行できる何かのためにもう1ピクセル"、あなたは真剣に時間を無駄にし始めるでしょう。
私は上記のように始めますが、その後、カスタムのもののためにXIBを捨てることがよくあります。秘訣は、コードにカスタムのもののバージョンを何度も実装することに何時間も費やさないことですが、それがどうあるべきかを理解し、カスタムのものを一度実行することです:)
nibファイルのXMLコンテンツは非常に複雑です。これにより、変更を確認したり、Gitなどのバージョン管理システムとのマージの競合を修正したりすることが非常に困難になります。
Interface Builderは素晴らしいアイデアですが、Bret Victorは、彼の講演「Inventing on Principle」と彼のエッセイ「LearnableProgramming 」で、Appleにさらに優れたIDEを構築するように暗黙のうちに挑戦しています。
ブレットビクターの原則に基づく1つのアイデア：iOSシミュレーターアプリで「移動ツール」を選択して、アプリのボタンを移動し、実装（.m）ファイルでフレームコードを変更できるとしたらどうでしょうか。これははるかに良いでしょう。