建議1 盡量使用系統控件

     系統控件可以使得用戶容易上手，但在iPhone開發中還有很多人習慣使用checkbox而不是UISwitch，使用combobox而不是使用UIPickerView。究其原因可能有兩點：一是從其他Windows或者Android系統轉到iPhone開發的殘留，二是因為跨平臺開發中為了減少設計和資源的工作而趨同設計。不過這樣的設計往往造成自定義控件的開發投入，質量上也往往無法和系統控件相媲美。

建議2 合理抽象

   UI代碼是很容易重復寫的代碼，很多時候就會造成代碼效率的錯局，讓人有一種高效工作的錯覺。其實很多代碼是完全重復或者結構重復的，通過適當的抽象就可以進行消除和避免。比如在一個應用中，不同地方所需要的內嵌網頁瀏覽器，這些地方往往都有一些共通的行為。比如加載的時候會顯示加載進度并在狀態欄顯示網絡狀態圖標，在加載完畢后隱藏進度和網絡狀態顯示。如果單獨在不同Controller中實現不僅不合理，而且容易造成大量代碼重復以至于后來的維護噩夢。通過合理抽象，抽取一個基類后就可以封裝這塊的行為，實現相同邏輯代碼的復用。

建議3 優先使用組合。

   UI中很多部分應該像積木，可以隨意拼接組合。比如下圖的用戶信息顯示部分可以由諸如UIImageView，UILabel等幾個基本控件拼接而成，而這種顯示在一個項目中會通常在多個界面中顯示。面對這種的問題，參考建議2后可能就會想著抽象一個基類用來處理用戶信息顯示相關的邏輯和界面。所有有這需求的界面都可以繼承自這個基類。這種抽象是解決了邏輯和界面重復實現的問題，但另一方面卻引入了高耦合的繼承。如果有些界面因為功能原因更會迫切繼承一個其他基類，比如建議2中提到的處理網頁加載的基類，由于Objective-C無法支持多重繼承，從而被迫進行部分代碼的copy&paste。所以在抽象的時候就應該格外珍惜基類的抽象的使用，不斷利用Liskov原則進行繼承合理性的檢查和確認，同時把握“優先使用組合”的原則，通過基本控件的組合制作一些應用相關的組合，比如顯示用戶信息的，這樣其他需要的節目就可以利用組合來復用這部分代碼，從而避免繼承，也其他更合理的繼承保留可能。

建議4 UI和邏輯的分開

   這是很重要的一點，iPhone SDK給開發者提供了一個很好的基礎來實現UI和邏輯的分開，所以實現的過程中務必遵照一些Apple的指導文檔，而避免在UI中揉合著大量邏輯代碼。要真這樣的話不僅對不起Apple工程師在這方面的努力，更是給自己增加無盡的麻煩。

建議5 充分利用IB。

   曾經遇到這樣的一個同事，九幾年開始做MFC開始，最初也很希望使用STL庫，不過在一次項目中發現了STL的內存泄露問題后就開發摒棄STL，以至到現在也不允許自己和屬下在項目開發中使用STL。這真是一朝被蛇咬，十年怕井繩。在使用Xcode進行iPhone開發的過程中同樣有這樣的一些人。他們很早就開始接觸和使用IB，但使用過程中發現很多IB的問題和不便，甚至有一些在實際項目中無法忍受，以至于到現在還一直抵觸IB。目前，雖不敢說IB已經很完美，但是它對開發效率的提高所起的作用是毋庸置疑的。

建議6 不要低估了Apple工程師

   在開發的過程中經常會發現一些比較奇怪的問題，這時候通常就懷疑是不是Apple的bug，于是乎就開始尋找一些特殊處理進行規避并逐漸認定這就是Apple的問題。一旦有過這樣的經歷后，以后遇到類似的問題就會首選自己發現的那些特殊處理，而逐漸偏離了開發的正道。舉個自己親身經歷的例子，一次為了改變UITableViewCell的顏色，開始時直接改變cell的backgroundColor，但發現搞不定，一番搜索后發現改變cell的ContenView的backgroundColor就OK了，不過一旦顯示accessoryView就露餡了。于是乎干的徹底點，直接自定義一個UITableViewCell，并用一個UIImageView做背景，現在終于可以“為所欲為”了。不過回想下，怎么簡單的一個問題如此大動干戈，真是不值當，所以心里會暗暗罵下Apple的工程師，怎么就不讓cell的backgroundColor起作用呢？這么明顯的bug！以至于以后的一段時間我就習慣用那“土辦法”，而且是屢試不爽。突然有天在stackoverflow上看到一個類似問題的討論，原來這種問題可以通過重寫-tableView:willDisplayCell:forRowAtIndexPath:的委托方法實現。想想之前罵過的話以及走過的彎路，只能感嘆自己掌握不深入。有了這樣的經歷后在遇到類似的問題我會先懷疑使用合理，而不是輕易下結論。