『壹』 APP軟體開發費用是怎麼算的(app開發費用詳細介紹)
【APP開發多少錢】
APP開發定價方式有2種
第一種，在線模板App。市場價格從K到w不等，但是相比於定製類的手機應用軟體價格要稍低些。但由於App模板的源代碼版權是App開發商所肢殲有，App數據來源多是存在於APP開發商的伺服器端中的，企業用戶需要交付管理費用才可以使用，企業需要使用數據作進一步分析時也需從App開發商伺服器導出。之所以是模板App，代表著模型的固定，不像原生態App，其內部的邏輯關系是修改不了的，但是可以刪減頁面和功能。UI方面只能做一些簡單的色調更改，並無法修改主體。
第二種，定製開發APP。所謂App定製，顧名思義就是可以定製自身所需要的App功能。市面上的功能模塊，定製開發公司都是可以開發的，個人想要實現的一些專屬功能也可以經由開發公司將其轉化為邏輯語言運用到APP當中，完成一整套的串聯功能，形成一個完整的源生App。
從長遠APP功能迭代商業價值來說，我們著重談論第二種，APP定製開發。因每個企業要開發每款APP都會在APP附著上符合自己企業的特色，對APP的功能要求不同，因此可以說每個企業定製出來的APP的價格也是不盡相同的。按功能需求的多少，完成需求所需要的開發時長等綜合評估進行相關APP的報價，也是APP開發行業裡面的共識。在不知道項目大小，要考慮並發量等因素，開發公司是無法進行報價的。架構是十分重要的，和App模板相比，定製App的價格就相對高一談飢沖些，App價格可以是幾萬，十幾萬，幾十萬不等的。區間的跨度很大。
也有公司選擇不開發APP轉而開發網站的，一般製作一個企業網站的報價不會太高，也就在幾千到幾萬之間。像現在很多企業使用模板製作一個商城網站的話，報價在5000元到1萬元不等。如果是私人定製一個商城網站的話，報價會偏高點，價格升到了以萬為單位級別。當然，還要看企業是製作什麼類型的商城網站了，也是要考慮網站功能和開發時長主要因素評估的，微信商城網站製作的報價和手機商城、pc端商城網站的報價相差會大一點。
App開發流程是怎樣的？
一般外包的項目都需要經常這幾個流程：
1）需求溝通：雙方溝通項目的需求，對項目的可行性進行分析
2）工作量評估：在確認了項目的需求後，開發團隊對項目的價錢和進度進行評估，並提供一份詳細的報價表及項目進度文檔，確認開發進度及時間安排
3）簽署項目合同：雙方在項目報價和開發時間上如果達成統一意見，則正式簽署項目合同，之後項目將正式啟動
4）設計,研發,測試,上線：根據最終確認的設計方案，對整個項目進行產品原型，視覺圖的設計，研發，測試，驗收，最終發布上線
5）相關文檔與源碼交付：完成所有的設計和開發，根據實際需要進行必要的技術輸出，合作完成。
6）維護升級：一般的APP項目開發完後都需要進行維護，因為隨著手機系統的升級，或長時間的使用，或多或少都會有其他一些新出現的問題需要維護
談論到商城app，首先需要細分下，商城app分為兩類一類是單用戶商城，另一類是多用戶商城，我們今天探討純商城的購物流程，不包含任何的營銷模塊（如：秒殺，搶購，三級分銷等）。
【商城APP開發價格】
第一：單用戶商城
用通俗的話可以這樣給大家解釋下，類似京東，所有的產品均是京東平台發貨，所有的用戶進入京東平台，正常注冊，登陸後只可以在線購買東西，我們定製研發的單用戶app商城，則是：平台所有的產品均由平台進行管理上傳，平台角色自然只有兩種：用戶（消費者）和平台（超級管理員），單用戶商城的開發價格大概再4-6萬元，在保質保量的前提下開發工期可以做到30-40天左右，而且是純定製開發，獨立的UE/UI設計，專業的後台人員封裝介面，專業的app工程師，專業的測試含殲人員，保證您的項目可以更好，更快，更專業的投入市場。
第二：多用戶商城
多用戶商城，從字面可以理解，多用戶即可理解成多商家，多店鋪，用戶進入app，正常流程完成注冊，登陸後，如果您是店主，有自己的實體店鋪，可以通過app商城平台在線申請開店，按照流程上傳需要的資料，平台審核通過即可完成開店，開店後即可擁有屬於自己的app店鋪，可以自主管理自己的店鋪，比如：店鋪基本信息，店鋪產品等。多用戶商城的研發周期我們可以控制在60天左右，純定製開發，依然是獨立的UI設計。價格大致在7-10萬這樣，當然具體的價格還是要根據項目的具體需求
【直播APP功能價格】
1.首先基於開發方式不同，收費標准就不一樣。如果開發方已經有了直播程序，並且直播源碼已經根據客戶需求做好了二次開發，這樣原有的直播程序功能就不需要更改，消耗的時間和人力成本就會下降，在軟體搭建完成後，如果客戶需要購買源碼，那整套直播APP開發價格在8w左右，如果不需要，價格在4w左右。
2.除了源碼二次開發方式外，特別定製的開發方式，定製開發的軟體不需要客戶提供程序，整個程序都會根據客戶需求「量身打造」，耗時久，耗費人力資源大，投入資金大，整套直播APP開發價格在10w，這還只是起步價。
3.這時會有小夥伴問了，為什麼同樣是定製開發，ios的直播APP開發價格比andiord高那麼多？這就是決定直播APP開發價格的另一個因素，手機系統。
Ios視頻開發需要使用ios指定的語言，需要聘請專門的ios開發人員進行操作，另外還需要申請蘋果開發者賬號，支付賬號的費用。去掉這兩點，還有硬體上的要求，必須使用蘋果的開發工具及電腦，這都需要付出更高的成本才能實現。
4.根據用戶從事行業的不同，所開發的APP價格也有所區別。對於電商類直播間：禮物打賞、購物車、物品展示、分享，實現這些功能的開發價格在7w左右；游戲類直播間：抽獎、禮物打賞、彈幕樣式、坐騎特效等，開發價格15w起步；顏值類直播間：美顏、連麥、pk、短視頻和圖片發布等，價格在6w左右。
直播APP人工成本
直播APP的開發自然離不開技術人員的參與，人工成本也是決定直播APP開發價格多少的關鍵，從前期的項目談判到後期的開發測試，以6人為團隊標准計算，每個月8w人工費。如果用戶需求復雜，那人工成本和時間成本都會隨著開發周期增長而增加，最終的開發價格報價也會更高。
『貳』 提交蘋果iphone app應用要交上源代碼嗎
向蘋果APPstore提交應用程序需要且必須提供源代碼文件。
蘋果APP store是一個應用商店，提供蘋果手機用戶下載應用功能，所以開發者在上傳提交至蘋果商店時必須提供開發源碼，才能在商店中正常下載使用。
提交至蘋果商店的應用，在通過審核後，會自動轉碼適配蘋果產品，手機、平板等。
『叄』 Apple 源碼用到的一些數據結構
本篇英文名叫 CWC：Kitchen Tools That Cook Loves ，翻譯過來的意思是 蘋果源碼中出現的一些數據結構 ，不斷積累更新。
CWC ： Cooking With Cook ，翻譯過來的中文意思就是 作為一個長期熱愛蘋果的蘋果開發者，我們要陪著水果公司一起積累和成長。
目前： entsize_list_tt 、 list_array_tt 、 cache_t's buckets ...
entsize_list_tt 其實就是一個通用的容器，可以獲取 內部的迭代器，用於遍歷內部存儲的元素
出現場景：
三者的聲明頭如下：
entsize_list_t 定義源碼，省略大部分方法：
這個類用來表示一個空、單數組、或者多數組。它和 list 的區別就是 多了一個多維數組的封裝。
出現場景：
ro 中沒有，只有三個單 List。
三者的聲明頭如下：
list_array_tt 源碼部分如下：
cache_t 的結構體定義：
buckets 的內部是一個連續的存儲空間，存儲是一個散列表。
開辟聲明的函數調用的是 calloc
當 msgSend 的時候，就會調用 fillCache 進行方法的緩存，存儲的涉及 cls sel 和 imp
bucket_t 的結構體很有意思，arm64 和 i386 的兩個值的順序是反著的。
arm64 的時候是 :
armv7* ， i386 和 x86_64 的時候是：
源碼注釋：
初始的 capacity 是 4。
源碼中 cache_t::insert(cls, sel, imp, reveiver) 方法調用的時候，判斷擴容。
fastpath(newOccupied + CACHE_END_MARKER <= capacity / 4 * 3)
也就是說當大於四分之三的時候，就會進行擴容操作，每次 double 擴容
capacity = capacity ? capacity * 2 : INIT_CACHE_SIZE;
當然不是無限制的擴容，有一個最大容量的限制：
MAX_CACHE_SIZE = 1 << 16
這個類型應該是執行最多次的，看一些文章說一秒鍾iOS中執行幾百萬次
explicit_atomic用來給catchT緩存方法用，核心是原子性和線程安全。
weak弱引用的散列表
擴展： non-fragile structs 是什麼？OC 1.0 （iOS自始至終都是2.0起的，Mac最開始是1.0）譯器生成了一個 ivar 布局，顯示了在類中從哪可以訪問 ivars ，對 ivar 的訪問就可以通過 對象地址 ＋ ivar偏移位元組 的方法。蘋果更新了NSObject類，例如增加一些屬性，這個又是靜態庫，發布新版本的系統，這個時候布局就出錯了，就不得不重新編譯子類來恢復兼容性。(那如果是在線上運行的app，升級系統後就沒辦法運行了)
使用 Non Fragile ivars 時，程序進行檢測來調整類中新增的 ivar 的偏移量。 這樣就可以通過 對象地址 ＋ 基類大小 + ivar偏移位元組 的方法來計算出 ivar 相應的地址，並訪問到相應的 ivar。(即使升級iOS系統，之前的app也能正常運行)
擴展再擴展： 為什麼OC類不能動態添加成員變數？ runtime函數中，確實有一個class_addIvar()函數用於給類添加成員變數，但是文檔中特別說明： This function may only be called after objc_allocateClassPair and before objc_registerClassPair. Adding an instance variable to an existing class is not supported. 這個函數只能在「構建一個類的過程中」調用。一旦完成類定義，就不能再添加成員變數了。經過編譯的類在程序啟動後就被runtime載入，沒有機會調用addIvar。程序在運行時動態構建的類需要在調用objc_registerClassPair之後才可以被使用，同樣沒有機會再添加成員變數。
理論上說，我還是認為可以添加，只是為什麼一定不可以，就不得而知了。
『肆』 APP開發流程有哪些
按工作的性質不同我先把App開發分成三個階段：售前、售中、售後，每個階段包括了多個步驟，循序漸進，最終完成項目的開發。
一、售前
1.需求溝通
在意向客戶提出有項目需求時，我們的產品經理會跟售前顧問一起跟客戶進行溝通。有些客戶對於自己的需求通常只是一個大方面的想法，這個時候就需要我們專業的產品經理幫他整理出項目的具體需求和功能列表清單，並幫客戶分析出沒有考慮到的或能否實現的需求。
2.項目可行性分析
客戶自身和產品經理都需要清晰了解該項目的功能特點、用戶痛點、行業需求和為用戶提供的服務內容等，每一點都要做出詳細的調查分析，尤其是客戶痛點這塊。如果開發出來的App存留很多痛點，那麼就算開發成功，也沒多長時間的存活時間。因為任何一個App最終的成功都是建立在用戶基礎之上的。
3.功能流程梳理
（1）整理架構
整理架構的過程就像是修房子打地基，產品經理會梳理產品整體功能架構，整理出核心內容，打造產品的地基，以確保客戶以後可以在這個原有的基礎上進行調整，更為方便、更具有擴展性。
（2）物森功能列表
接下來，產品經理會做出更詳細的功能列表，添加每個模塊的細節內容及具體功能，比如「注冊」用哪種注冊方式，簡訊驗證碼還是第三方注冊等。這部分就像你在裝修毛坯房時，首先要考慮加上門窗、水電改造等。
（3）梳理流程
產品經理會根據客戶的需求梳理出產品的核心業務，會幫客戶提前考慮到他們現有的流程是否可以在互聯網上進行操作，例如一些傳統行業轉互聯網的企業客戶，產品經理會站在移動互聯網的專業角度幫客戶梳理並優化流程。
4.量身定製實施方案
當需求文檔確認完畢之後，售前顧問會根據客戶需求量身定製一套App開發鋒螞掘方案和報價清單，包括項目組人員安排、時間節點安排和技術方案等，待客戶確認完之後就可以開始正式簽約合作了。
二、售中
1.產品設計
（1）原型設計與評審
喜望產品經理根據需求文檔設計出高保真原型圖，包括功能的結構性布局、各分頁面的設計、界面交互邏輯的設計等。高保真原型圖將需求文檔轉換為更直觀的軟體demo版本，這樣即可以確認更多的細節，保證項目研發的效果，也能避免溝通不暢或溝通不到位而引發的糾紛問題。
（2）UI設計與評審
原型圖設計確認好之後，UI設計師會根據產品的定位和原型圖設計UI界面效果圖了，相當於是在原型圖的基礎上加上顏色、確定產品整體風格、功能具象化處理、交互設計和排版布局等，使客戶更直觀的可以看到App的雛形，具有極高的還原度，能夠為用戶帶來更高的體驗度。一個完整的App需要一個吸引用戶眼球的創意，這就需要產品經理和UI設計師在創意策劃上有著獨到的見解。
（3）需求詳細講解
產品經理會跟項目經理對接需求和原型圖UI圖，講解客戶的詳細需求、功能板塊、跳轉頁面等，項目經理需要細化需求，將這些需求和圖片翻譯成工程師們能更好理解的語言。接著，項目組會搭配著原型圖UI圖來召開技術會議，統一進行項目需求講解。
（4）技術標准制定
項目經理在了解清楚整個項目的需求後提供易擴展、可持續迭代的技術框架方案，比如是原生開發還是混合開發、用Java還是PHP、還有第三方選型等。
2.敏捷開發
（1）迭代開發計劃
在正式進入項目開發之前，項目組會對項目本身進行評估，對研發周期、提測時間、預發布時間點進行初步的判斷。接著對項目功能進行分解，把項目需求劃分成4-5個節點，比如1號-9號做第一個功能模塊，10號-15號做第二個功能模塊項目組把迭代開發計劃發給客戶確認後，就開始按著這個計劃做節點研發了。
（2）節點研發
按照需求分析整理出來的功能數據處理情況，項目組會建立合理的資料庫表結構，優化數據演算法，提升數據的處理效率，保證後期App使用過程中數據的安全性、准確性、穩定性和及時性。
一個完整的App項目一般包含以下幾個模塊：
①伺服器端：編寫介面協議文檔，伺服器環境架設（國內一般都是用阿里雲伺服器，國外一般用亞馬遜），設計資料庫和編寫API介面，業務功能實現及介面封裝、管理後台的開發。
②App端：根據UI設計圖進行界面開發，UI開發完成後對接伺服器介面，通過服務端介面獲取數據，編寫功能上的邏輯代碼。
③Web管理端：根據前端的業務邏輯，後台會有相應的功銀核能與之匹配，同樣需要編寫功能上的邏輯代碼。
在項目研發階段，項目經理進行技術攻關，流程助理同時跟蹤進度，項目組也會每周向客戶進行開發進度匯報，並協助客戶申請軟著。
（3）單元測試
以前的開發流程就是工程師從頭寫到尾，把App功能全部開發完成後再進行系統測試，這樣就很容易出現以下幾個問題：修改了一處bug卻在另一處地方引發了新的bug、擴展新功能的同時導致舊代碼出現bug等等，這個時候就需要引入單元測試。
單元測試簡單來說就是工程師做一個節點研發，測試工程師就測試一個節點，這樣就能夠清晰的知道是否破壞了老的業務邏輯，容易排除掉一些非常低級的錯誤，大大減少回歸出錯的可能性和調試的時間，提高代碼質量。
（4）系統測試
App功能開發完成之後，測試人員會對整個項目進行系統性測試。而完成項目測試調試最重要的環節是問題的管理，追蹤各個bug的進度以及狀態，包括指派給誰、優先順序、修復狀態等，以便有質量地完成問題的處理。
產品面向的平台多機型同步測試，包括：App內容測試、App性能測試、App功能測試、App視覺測試，對BUG調試修復。測試合格，確認沒有bug後與客戶進行溝通，開始驗收，再由客戶進行測試，提出修改意見。
3.上線交付
01.用戶體驗測試
喜望在2018年新設了一個「創新性人才崗位」——用戶體驗官，這是移動互聯網行業首創的「從功能試錯服務到運營實踐服務」。
用戶體驗官的工作就是用戶體驗測試，從用戶體驗、產品、易用性、顏值、App設計還原度等多個維度進行體驗性測試，並通過後台上傳真實的前期種子數據，讓整個App的內容很豐滿，互動性強。用戶體驗測試是從項目本身的用戶群體和運營邏輯來幫助客戶打造好整個App的調性。
02.部署上線
在代碼開發和測試完成後，就進入了後期上線的階段。
（1）部署正式伺服器：將資料庫、後台系統部署到正式的伺服器上面，並錄入正式的上線數據到app系統後台。
（2）准備上架相關的資料：如軟體著作權、應用說明、App界面截圖和打包版等。
（3）發布App應用到市場：根據App埠選擇發布iOS或Android應用市場。
①Android：涉及的應用市場很多，主流市場是騰訊應用寶、手機網路助手、360手機助手、91手機助手，不同的應用市場的受眾屬性和流量會有所不同，需要根據客戶需求和項目實際情況來選擇。一般來說，1-2個工作日就可以通過審核上線。
②iOS：發布到AppStore，提交後一般最快都需要5個工作日左右才可以通過審核上架。因為AppStore審核比較嚴格，比如是否符合最新的上架要求、是否涉及到虛擬貨幣、是否支持最新環境等很多問題都會決定審核能否通過。
但有可能會遇到這種情況：比如某App存在3個導致不通過的問題，AppStore只要找到其中一個問題就不會通過，不會把3個問題都找出來告訴你為什麼拒絕，所以如果經驗不足，上架N次花費幾個月都是很有可能的。
③發布小程序到微信公眾號：需要把小程序發布提交給微信團隊審核並上架，一般1-2個工作日就可以通過審核上線。
03.源碼交付
APP開發測試上線後，要進行終驗交付，即按照合同規定，將源碼、說明文檔、操作文檔等所有項目的相關資料交付給客戶。
包括但不限於：
1前後端項目的所有最新源代碼（含注釋）
2資料庫設計文檔
3API設計文檔
4所有的開發者賬號資料
5測試文檔
6原型設計稿
7UI設計稿
8項目相關文檔等資料
04.項目運營培訓
在交付源碼時，喜望的項目經理會給客戶針對項目的所有功能操作進行培訓，比如優惠券怎麼發、司機怎麼核審、怎麼查看用戶注冊等。我們也會根據客戶需求，讓品牌設計師和新媒體運營官為客戶設計上線海報和新媒體運營方案。
三、售後
1.前期維護
一般的App開發完後都需要進行維護，即便是已經達到相對穩定的階段，也可能隨著手機系統的升級或長時間的使用等，出現一些小問題或隱藏得比較深的bug。
喜望會免費贈送客戶三個月的維護期，一個項目正式上線運營了3個月左右的時候就已經清楚了整體的運營模式和部分功能欠缺，接下來想要繼續運營app就需要迭代開發、優化功能模塊。
在此期間，我們會解答客戶的疑問、指導軟體的使用和內容的上傳等事項，以及修復程序Bug、突發情況發生後緊急維修等。
2.定製更新
在App投放到市場後，會得到用戶以及市場本身的一些反饋，從而知道該如何修正或者調整運營策略，當目前系統的功能無法滿足項目需求時，就需要規劃新一版本功能的迭代問題了，也就是開發項目2.0。
喜望會幫助客戶進行定製更新，也就是繼續App開發前期「售前」所做的工作：需求溝通、可行性分析、功能流程梳理以及量身定製實施方案。
這個迭代方案一般根據以下2點進行制定：
①未完善的BUG
比如上線後的App在運營過程發現的一些BUG，或者邏輯錯誤的一些地方，如果我們想要修復這些邏輯錯誤問題和功能BUG，就必須進行App的迭代。
②App數據分析
數據是極其重要的衡量標准，通過分析App的投放資源、用戶激活率、轉化率、留存率和用戶進入使用不同功能的佔比、各個環節的流失，尋找對App體驗影響較大的指標，分析自查功能設計上的優劣，以便進行功能上的版本迭代。
3.迭代開發
同樣的，當項目進行迭代開發時，也會重新經歷「售中」的全部過程，包含產品設計、敏捷開發和上線交付等所有的產品生命周期。
4.項目維護回訪
當項目運營過一段時間（免費維護期結束）後，喜望會對客戶進行回訪，詢問運營情況等。當然了，如果後續客戶需要我們繼續提供運維支持，我們也是很樂意的，因為在App運營的過程中需要與時俱進、維護更新，App才能長存。
5.新媒體運營
成功上線後的App可以通過企業的運營推廣，發展用戶數量，得以長久的運營。推廣運營的方式有很多種，比如進行線下推廣、投入廣告、新媒體運營推廣等。
貼心的喜望根據九年的從業經驗以及目前市場情況，會推薦客戶做成本相對較低的新媒體運營推廣。
從上面的App開發流程來看，每一個項目研發都要經歷以上3個階段22環節，這其實是一條完整的流水線，做到這樣往往能達到較高水準的項目質量。但是如何保證流程順暢進行？如何使項目成員的工作效率最大化？這就十分考驗開發公司的專業度和項目成員的規劃能力了。
之前有講到過，一款App開發的時間也會影響到App開發的價格，所以，了解一下App的標准開發流程還是很有必要的喲。