大家好，我們是成都小火科技公司，今天是2025年9月29日，星期一。去年夏天，我們公司做了一個記錄咖啡口味的小眾APP，客戶要求中英雙語，同時要求用蘋果原生語言開發。

關于蘋果APP原生開發語言，目前主要有兩種技術棧，到底是使用Swift還是OBject-C呢？網上攻略一半說Swift“新且簡潔”，一半說OBject-C“穩定適配廣”，我盯著屏幕翻了兩天文檔，最后決定“先試Swift”。畢竟這款APP功能簡單，主要是列表展示、表單輸入和圖片上傳，沒必要一上來就啃OBject-C的復雜布局。但剛寫登錄頁就栽了跟頭：Swift的預覽功能確實香，改一行代碼就能實時看到輸入框的顏色變化，可當我把代碼放到iPhone SE模擬器上時，發現底部的“登錄”按鈕直接被安全區擋住了，預覽窗里壓根沒提示這個問題。我對著屏幕愣了半天，又去Apple Developer論壇翻帖子，才知道要加一句`padding(.bottom, UIApplication.shared.windows.first?.safeAreaInsets.bottom ?? 0)`，把安全區高度算進去。改完再運行模擬器，按鈕終于乖乖待在屏幕下方，那種“終于搞定”的踏實感，比看十篇教程都管用。

原生開發里最讓我頭疼的不是代碼，是蘋果的“審核門檻”。第一次提交APP時，我信心滿滿地填完信息，結果第二天就收到拒絕郵件，理由是“未說明獲取位置信息的用途”。我趕緊打開info.plist一看，果然只加了獲取位置的權限申請，沒寫清楚“為什么要要位置”——其實我的APP只是想根據位置推薦附近的精品咖啡館，卻忘了在描述里說清楚。那時候已經是晚上十點，我抱著電腦坐在書桌前，把隱私描述改成“需要獲取您的位置信息，用于推薦3公里內評分8.5以上的精品咖啡館，不會存儲或分享您的位置數據”，重新打包上傳。沒想到第二天一早打開郵箱，就看到“審核通過”的通知，那一刻才明白，蘋果審核不是“故意刁難”，而是更在意用戶的知情權——你得把“為什么要權限”說清楚，用戶才愿意信任你的APP。

還有個意外收獲，是蘋果生態里的工具真的“夠省心”。之前幫朋友做過安卓APP，測試時要反復發APK文件，還得擔心測試員手機版本不兼容；但蘋果的TestFlight完全不用操這個心，只要把測試員的郵箱加到列表里，他們在App Store搜索“TestFlight”，輸入邀請碼就能下載測試版。我記得第一次把咖啡APP的測試版發出去，朋友當天就反饋“收藏咖啡的按鈕點了沒反應”，我查了下代碼，發現是把button的action綁定錯了方法（把`saveFavorite()`寫成了`saveHistory()`），改完重新上傳，不到10分鐘朋友就收到了更新提示。這種“改完馬上能測”的效率，讓我覺得原生開發雖然前期有門檻，但熟悉之后反而比跨平臺開發更省時間——不用在“適配不同系統”上反復折騰，能把更多精力放在功能本身。

現在這個咖啡APP已經上線小半年了，偶爾會收到用戶的評論，有人說“記錄界面很流暢，比那些廣告多的APP舒服”，還有人說“推薦的咖啡館真的小眾，沒踩過雷”。每次看到這些評論，我都會想起第一次打開Xcode時的手足無措——那時候總覺得“原生開發太難了”，可真正沉下心去查文檔、踩坑、解決問題，才發現它的核心不是“復雜的代碼”，而是“站在蘋果的邏輯里，把用戶體驗做細”。比如iOS用戶習慣“左滑返回”，我就給每個頁面都加了手勢返回；比如蘋果強調“不打擾用戶”，我就把推送通知控制在“每周一次咖啡推薦”，從不多發。

其實做蘋果原生APP就像學做咖啡，一開始總搞不清水溫、研磨度的搭配，可多試幾次就會發現，那些看似“繁瑣”的規則（比如蘋果的設計規范、審核要求），本質都是為了讓最終的成品更“順手”。現在我偶爾還會給APP加新功能，比如最近加了“咖啡筆記導出成PDF”的功能，用的是蘋果原生的PDFKit框架，跟著文檔寫了不到200行代碼就搞定了。回頭看，當初那個對著Xcode發呆的自己，要是知道后來能這么輕松上手，大概也不會那么焦慮了吧。

文章來源網址：http://jt-toy.com/archives/xiaochengxukaifa/2202，轉載請注明出處！