很多人可能都想過要開發一款APP，雖然擁有許許多多創意的點子，但卻不知道該從何開始下手嗎？這篇文章將會分享一個實際從無到有、從創作開發到上線推廣的開發案例，讓你實際了解中間所有的過程、會踩到的問題點以及你可能從沒想過但開發中一定會遇到的困難。
以下文章如果是從「聖經種子」為出發點的部分都會以引言作為標示。
一個APP的開發周期我大致區分以下6大階段，文章內會做各階段的概論以及遇到的問題，其他開發細節則會另外獨立新文章來分別做詳細的分享。
APP開發周期
規劃期 > 開發期 > 測試期 > 增修期 > 上線期 > 推廣期
規劃期
規劃期內需要考慮以下
- 構想
這裡需要先思考為什麼要做這款APP，它的特點在哪裡？坊間很多文章都有在教學一些基本的評估，例如解決痛處、優化操作體驗...等等，都是可以作為APP的功能方向發想。
我本身是個基督徒，平常看到有些人寫了些心得分享，但對於參考的聖經經文段亂都是凌亂沒有經過整理的，今天可能看到某人分享了A段，下一次看到又是B段的筆記或心得。再加上因為疫情的關係，大家都在隔離的階段，很少面對面實體的一起研讀聖經，在閱讀的過程中，如果遇到某段不明白或是想要了解別人的觀點、分享的時候，卻沒有對應的資源。於是，我就想要有個從聖經經節角度下去的心得筆記分享功能，而不是大家由分享的角度〈類似於Facebook〉下去隨意挑選章節。
- 受眾 (TA, Target)
找到構想後需要知道有哪些人會成為你的使用者，這關係到你設計這個APP的角度、Beta受測者挑選、接受需求回饋來源、推廣方向。
聖經種子的受眾很明確的是基督徒們，但這裡我們多考慮到了﹝全球性﹞的問題，為了能讓大家的心得分享能夠無遠弗屆，不受地區、語言的限制，所以直接規劃出中/英文版本，並且心得筆記都要能有即時翻譯。
- 系統平台
再來要確認需要提供的操作平台有哪些？常見的系統有iOS、Android、Web、Windows、Linux、Mac...等等。每多一個平台有可能是雙倍以上的工作量，因為牽扯到了不同的系統語言和底層架構，例如iOS使用Swift或是Object-C，Android使用的是Java或是Kotlin，更遑論一個系統中就有不一樣的尺寸大小，iOS中有iPhone系列、iPad系列...，Web中支援有各種尺寸的RWD設計(Responsive Web Design)，所以在一開始就決定好要提供的平台是很重要的一件事情。
聖經種子規劃支援iOS及Android兩個手機及平板的平台
- 程式框架
這裡就看各人喜好了，有原生的Swift / JAVA，或是直接跨平台設計React / Flutter，各有各的優缺點，建議可以觀看網路上的比較文章後選擇最適合自己的框架。
我們最後是選擇使用Flutter作為我們的開發框架，原因是我們小團隊使用跨平台設計比較方便，且Flutter作為Google中得到大力支持的小孩，以及套件和支援度都是相當優秀的，後勢看漲。
- 夥伴
依照專案的大小，可以小到一個人獨力完成，也可以大到有UI/UX、PM、行銷...等等，團隊越大分工越細，專業度越高，但是伴隨而來的是溝通成本和利益分配。團隊越小當然執行速度越快，但可能需要包山包海的事情越多，專業度就不會是被看得很重要的部分了。選擇團隊的夥伴也是個大學問，除了本身的專業度、配合度，還有跟這個團隊的契合度都是個大考驗，所以能遇到合得來的夥伴，記得好好珍惜呀！
雖然一開始是打算做Side Project練練功，但個人蠻注重美感這件事情，也希望做出來的成品可以有一定的水準，所以有規劃了UI/UX的配額。由於這個APP的方向很明確，所以團隊的尋找方向就往基督徒、有專業能力和有興趣一起練功來找，當然自己個人的人脈這時候就顯得很重要囉。最後我們的團隊成員有
UI x 1
UX x 1
Coding x 3
- 獲利方式
常見的營收方式有下列幾種：
- 付費下載 : 例如APP Store、Play Store或其他各種管道上的定價販賣，優點是有穩定的銷售和獲利比，缺點是使用者購買使用意願降低，以及各大商店平台上的巨大稅額 (相關報導 : 馬斯克嗆蘋果稅30％太多、祖克伯罵蘋果稅)
- 內置廣告 : 常見的有Admob、FAN...等等，優點是跟著使用者的使用和瀏覽量可以獲取一定的收益，不必被一次買斷，但缺點就是會跟著供應商的演算法而變化，無法掌控；且很吃設計者的美感和功力，常常有開發者直接掛一個橫幅在APP上或是網頁上一堆廣告降低使用者的瀏覽體驗。
- 應用程式內購買 : 這是另一種獲利方式，IAP (In-App-Purchase)，藉由APP內販售虛擬商品或是訂閱會員之類的服務，來獲取對應收益。優點是可以無限擴充，讓有需求者可以花錢體驗；缺點就是要控制平衡﹝尤其是遊戲類APP﹞，以及跟商店販賣一樣要被收取龐大的商店平台稅。
- 業配/聯盟行銷 : 這在APP中比較不常見，利用推薦代碼轉換成銷售抽成，但如果剛好APP內容和某些實體販售商品有相依性，或許也是另一種可以轉換營利的模式。
- 電商/服務 : 這種我歸類為非APP內獲利，只是把交易和行銷手段放在APP上。
- 背後金主 : 本身就是公司或是集團內配置的APP，所以所有資金和支出都由金主提供。另一種就是靠贊助，有人覺得這APP對他有所助益，願意捐贈支持，類似於現在比較常見的"Buy me a coffee"或"LikeCoin"，但相對得到的收益還是有限。
一個APP的開發和營運還是會有些必要支出，例如Apple每年的開發者費用、各商店的上架費用、以及Saas或Baas的後台運作費用...等等，所以要能穩定的走下去還是必須要先確認好獲利的來源，避免到最後一個優秀的APP就因此而沉入大海，或是根本直接胎死腹中。
因為聖經種子算是福音性質的APP，所以一開始不打算太商業化，只在一個附加的小遊戲中使用道具時要觀看獎勵式廣告 (整頁式，需觀看滿一定秒數才可獲得獎勵)，以及在使用者名單或是筆記心得做原生廣告 (可客製化各種樣式，以最貼近原生APP的外觀嵌入當中)。最後增加IAP來提供贊助訂閱方式並可免廣告。
開發期
開發中的各種爭執討論、協作設計、功能開發、技術問題、定期會議以及推薦使用的工具...等等，以及初期你不會預想到的問題和必須功能，後續會另外寫一篇詳細完整的文章來做分享。
這裡先提供我們所使用的相關環境和軟體
會議通訊 : POP
專案內容 : Basecamp
UI / UX : AI, Sketch, Figma
Framework : Flutter
IDE : AndroidStudio, VSCode
Saas : Firebase
VersionControl : Git, Gihub
沒預想到的功能和問題
1. 推播(Push Notificaiton)
2. AppLink和DeepLink
3. Loading畫面
4. 帳號刪除功能
5. OAuth登入
6. 動畫
7. 程式周期問題 (背景模式、重啟、關閉...等等)
8. 版本相依性問題
9. 中英文長度問題
10. 不可預期的框架、平台、套件等等的原生性問題
11. 隱私權、使用者服務條款、EULA之類的合約條款產生
12. 新手導引教學
測試期
一般來說正常的軟體測試周期為內部測試(Alpha)、封閉測試(Close Beta)、公開測試(Open Beta)、正式發佈(Public)。不同平台都有各自的測試方式，開發時也都有各自的模擬器可以使用，要特別注意的是iOS版本必須要Mac電腦並且安裝XCode才可以編譯和跑模擬器；如果你要連接實機測試操作則要先擁有開發者帳號和線上註冊實機的序號。
在測試階段有個很重要的重點，"定期出測試版本"，因為只有持續的修正和測試，才能在正式發佈前盡可能的完善APP，我們最不希望的事情就是正式推出之後，發現有重大的異常，這會導致初期的推廣以及後續使用者的信任、留存率遇到嚴重困難。
- Android
Android相對開放(不安全?!)，可以打包APK後給各使用者測試，也可以打包成AppBundle丟到Play Store上供對應的測試群組來下載測試
- iOS
iOS相對封閉(安全?!)，只能透過上傳ipa檔案到AppStore上，並且測試人員必須安裝TestFlight (對於使用者來說可以想像成測試版的AppStore) 來進行安裝驗證和測試。
在測試期間如何接受使用者的問題回饋?
1. 各平台自帶的回報系統
2. 程式內建立使用者回報系統
3. 程式內建立自動上傳Crash分析
4. 通訊群組 (Line官方...等等，只適用於內部及封閉測試)
測試階段也蠻值得獨立一篇文章來做細部計錄和探討。
增修期
測試期過後除了可能有很多被回報的BUG需要修正以外，也會有許多期望的功能和需求冒出來，這裡我把它定義為增修期。在開發階段和測試期，所有開發者都會面臨的一個重大問題，「這個功能到底該不該加？」。
「聖經種子」在開發中不免俗的也遇到了這個問題，如同前面提到的，最一開始的想法和功能需求是「針對經文的心得筆記」，但隨著開發中加入了小遊戲，又進階成了不小的動畫遊戲，以及各種同類型APP被認為是「基本該有的功能」。因為這些功能的調整，以及前面開發期所提出的未預想到的功能和問題，導致我們的開發期間從半年整整拉長到了一年半...囧。
在這裡提供你幾個可以歸納出測試者的需求，以及如何割捨的方法。
- 問卷
測試期中間，可以針對各版本設計不同的問卷，用以了解大家的偏好。
- A/B testing (維基百科)
測試版本中可以夾雜不同的變數，來主動的測試使用者的偏好和習慣。
- 80/20法則 (維基百科)
收集完需求後，使用80/20法則來把80%的人需要的功能先做出來。
- 最小可行性產品 (維基百科)
常常聽到先求有再求好，我們這裡改一下，先求完成特色差異化或可以表達核心設計的功能，等下個版本時再滿足其他需求，但最大的前提是絕對不能有BUG降低使用者體驗。
上線期
上線期我會區分為兩個階段，上架前和上架後。
正式上架前要記得把自己當一個全新的使用者，將APP刪除重新安裝一遍，並且全部流程、功能檢查一次是否完善，套件版本是否有重大更新 (非BUG不建議在此時做更動)，接著，更改version和build version，並為你的版本打上tag，這部分可以考慮用一些自動化的打包上傳工具，例如Fastlane。
送審部分會建議你多留一點時間，因為要保留被打槍(?!)修改的時間。各家商店內要填的資料蠻多的，尤其如果有在APP內販售商品，還要填寫各種稅單，每家商店介面也並不一定都非常友善，還有各種不同的規範.....，實際上花費的時間會比你預想中來的要多上很多很多。
(可以參考看看APPLE這滿滿的Review Guidelines)
上架後你可能以為高枕無憂了，卻不知道其中藏了許多的陷阱，導致很多無法預期的問題發生並且造成使用者流失。
後續有機會將獨立寫一篇抱怨被打槍文章，以及各種在上架前後、大大小小的坑，讓你可以吸收我們慘痛的經驗來避免跌倒。（獨立文章連結）
推廣期
最後APP上線之後就可以開始好好的宣傳啦～A/B Testing在各方面都還是可以持續使用唷，無論是文宣，還是行銷手法，都可以藉由兩種以上的測試條件來找出最適合你的方案。
底下是我們使用的宣傳方式
1. 官網、動畫
使用一頁式網站來給人家一種正式有技術性的感覺，如果SEO有做好的話，效果可以更加倍！動畫是可以放在後續社群推廣或是實體行銷之中都可以的，所以我們有做了這部分。
2. 社群推廣
雖然現在社群的廣告作用力已經大幅下降，但能夠有觸及率的地方我們都還是盡可能地去嘗試，要做社群推廣，就必須要常常有實質內容的更新，讓觸及率可以往外擴展。除了一般網上推薦可以做互動式問答之外，我們還打算邀請一些比較具有影響力或知名的人/牧者，來實際分享他們的使用心得，為我們做推薦。
3. 實體行銷
這部分就要看最前面所提到的目標客群來做規劃，因為聖經種子的TA很明確的是基督徒，所以我們會開始走訪各大教會，實地走訪在主日聚會中做宣傳和行銷。
結論
要完成一個APP並不是一件簡單的事情，如果今天你打算自己開始動手做做看的話，希望上面的分享可以對你有所幫助，如果你也有相關的經驗歡迎分享給我，有任何其他的問題想要了解的，或是內容有錯誤的都可以留言唷！文章中有部分需要更詳細說明的之後會各別獨立出文章做深入解析探討和分享，敬請期待唷！！
