open source app（ARC以外）を変更しています。私のiOSの経験の大部分はARC対応のobjective-cです。プロジェクトに新しいファイルを作成して追加するときに、私はcompiler flagsを使用してARCに準拠させる傾向があります（特に奇妙な非アークコードbugsに直面している場合）。同じiOSプロジェクトでARCコードと非ARCコードを混在させることはどのくらい安全ですか？
夜に私を抱かせるものは、私のプロジェクトでは、弧と非弧のコードを混在させることはどのくらい安全で信頼性が高いのですか？ QA時間が来たら、メモリリークやパフォーマンスなどのテストをするのは悪夢です。別の方法で尋ねました。既存の非アークコードをアークコードに変換し、潜在的な問題を取り除く価値がありますか？
問題なく自由に混合できます。
はい、確かにこれはあなたが必要とするすべての答えです。注意点が1つあります（プリコンパイルされたコードで、ARCを過リリースに騙すという命名規則がありません）が、この状況では当てはまりません。 – borrrden
err ..よく私は皆さんの両方を大いに尊敬しており、私はあなたの両方の技術経験を認めています。私はいくつかの証拠や書類を希望していましたか？またはあなたの答えは単に個人的な経験に基づいています（それでも十分です）。 – abbood
@abbood - ARCは魔法ではなく、コンパイル時にコードを調べ、必要な保持と解放を追加します。生成されたコードは、自分で作成したコードと変わりません。 [ARCリリースノートへの移行]（https://developer.apple.com/library/mac/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226）から： 「一部のファイルに対して手動参照カウントを使用する方が便利な場合は、ARCをファイル単位で使用することもできます。 – sosborn
これらはコンパイラフラグであり、リンカフラグではありません。また、ARCを使用しても、漏れや性能についてアプリをテストする必要はありません。 –
私の悪い..固定.. – abbood