如何混編不用多說，蘋果對Swift 3.0以上的混編輔助已經(jīng)做得很方便了——無非是build settings中設(shè)置標志，以及兩個文件雨涛，一個是系統(tǒng)或自己創(chuàng)建的bridge文件碧浊，用于Swift文件調(diào)用OC類導入頭文件的橋接；一個是系統(tǒng)生成的xx-swift.h文件隘击，這個連導入都不需要做侍芝，直接引用即可。
Swift的以O(shè)bject為基類的集合類型在傳遞時可能全部被深拷貝埋同，而OC以NSObject為基類的傳遞都是默認指針傳遞州叠。
Swift文件調(diào)用OC類的屬性時不會編譯成可選類型，因此當該OC類的屬性為空時凶赁，而編譯器并不會給出提示咧栗，于是運行時Swift代碼取值時會崩潰。所以一定要關(guān)注調(diào)用的OC屬性是否可能為nil虱肄，并相應(yīng)做判空處理致板。
混編后的App如果產(chǎn)生Swift文件內(nèi)的崩潰，在Bugly上無法生成有效的堆棧咏窿，可能會定位到具體的Swift函數(shù)斟或，但行數(shù)不確定。
個人認為向Swift演進的最大障礙是：由于兩種語言混編集嵌，并且Swift的ABI不穩(wěn)定萝挤，所以為了兼容所有系統(tǒng)，包括Swift還沒有發(fā)明時的iOS 7纸淮，App打包時會把Swift運行時庫全部加入進包中平斩，其中Swift Core, Foundation, Support等動態(tài)庫有將近30多M，打ipa包時會比純OC多出10多M咽块；而解壓安裝到本地后的占用空間更是要多出40绘面，50M。
基本上領(lǐng)導和產(chǎn)品經(jīng)理們不會放過你的。
更新與更正：經(jīng)過實踐發(fā)現(xiàn)揭璃，打包成提交App Store的ipa與企業(yè)分發(fā)的包略有區(qū)別晚凿，蘋果會對Store版本ipa進行合理瘦身，因此這個問題就不再是問題了瘦馍。夜
