小程式出來之後，各界存在這些疑問：
App 和服務號碼會不會消失；是否會顛覆App Store；安卓、iOS 工程師要面臨下崗？
蘋果為何不讓叫「應用號碼」；小程式如何獲利；小公司是否能享受到流量紅利？
什麼樣的產品適合用來存取小程式；HTML 5 的小程式體驗不如原生 App？
小程式是否會取代App：
潘欣：
我不覺得微信應用程式和App 之間是非此即彼的二選一關係。對絕大多數企業來說，必然是兩手抓兩手都要硬的。資源相對匱乏的新創公司更適合從低成本微信應用程式切入會更快速。
很遺憾看到各路評論家一邊倒的激動地謳歌微信小程序顛覆 App Store，以及顛覆這顛覆那的，總之顛覆了全世界。我深深的懷疑你們絕大多數人肯定沒經營過一個企業，我也深深的懷疑張小龍自己是否有你們一樣的「小程式大夢想」。
QQ 也曾經探索過 Widget 類似的模式甚至 QQ 桌面，從結果看不是很成功。相較於當年，我肯定更看好微信小程式的前景。但談顛覆，現在還為時過早。
小程式和服務號碼的關係；是否會開放給個人？
laurence：
服務號碼是否可以轉換為應用程式號碼？這個不得而知，但我相信肯定有大批的服務號是想轉變為應用號的，一些服務號的功能屬性遠大於媒體屬性，例如有硬體設備連接需求的服務號、京東購物的服務號碼、滴滴出行等服務號，如果讓這些服務號主體再去開發小程式未免太折騰，主體下的服務號和小程式之間功能也會有重疊，浪費資源，也佔用用戶的資源，所以我的猜測是認證的服務號是可以轉（升級）為小程式的。在之前訂閱號碼是可以「升級」為服務號碼的，如果有這個可能，微信可能也會給出是否「升級」的選擇；因為從得到的訊息來看，微信的態度是訂閱號碼、服務號碼、企業號、小程式是完全並行的四種形態，所以服務號的繼續存在一定還有其服務號的意義，但如何升級不得而知，例如粉絲遷移？
小程式是可以與APP 打通，但並沒有提與服務號的打通，其實與服務號的打通是完全沒有問題的，但微信並沒有提這一點，猜測服務號碼是可以升級小程式的。但不支援小程式與 App 的直接跳轉。 （能做的都在小程式內做就好了，搞那麼多跳轉沒有意義）
小程式是否開放給個人？
在全面開放申請之後，主體類型包括個人、企業、政府、媒體或其他組織，這一點很有意思，小程式是有個人主體類型的，我們知道訂閱號碼是可以申請個人主體的，但服務號不可以為個人主體的，對此我有很多的疑問，小程式是有微信支付能力的，而小程式可以面向個人開放？稅務問題呢？對於個人來言的可信度整體來說一定要小於企業的可信度的，或者小程序的開放也是對不同組織有區別對待？例如個人開發者是沒有微信支付功能的，不然收款到哪裡？個人帳戶？服務號碼的微信支付都是關聯企業對公帳戶的，微信不會提供你逃稅的能力。
「應用程式號碼」無法通過的原因
張驍懿：
據悉，應用號碼的入口是在發現tab 購物遊戲下面，之所以叫小程式是因為App Store 審核不通過應用號三個字，並且已經和蘋果約法三章應用號不能做遊戲產品，以及，一個用戶只能新增20 個。
作為一個只寫 Script 語言的人我是很支持騰訊幹掉 PhoneGap/Cordova/Ionic。不過我就想問一件事，蘋果能允許麼？
小程式安裝或升級的話要不要蘋果再審核一次？這就跟用ReactJS Live Update 一樣，屬於蘋果的灰色地帶，一個普通App 這麼做可以睜一隻眼閉一隻眼，有潛力做成OS 的話蘋果能答應麼？
Apple's guidelines explicitly permit you to push executable code directly to your app, bypassing the App Store, under these two conditions:
The code is run by Apple's built-frame or JavascriptCore.
The code does not provide, unlock or enable additional features or functionality.
安裝一個App 就相當於微信不用蘋果審核就*增加*一項功能，這比加個Patch 快速修復一個Bug 可*過份*多了。
鑑於微信在蘋果發表會上出現的頻率，微信團隊很可能跟蘋果溝通過了，所以像360 那樣被下架的可能性比較小，不過如果別的廠子看見了也蠢蠢欲動，那可是動搖了App Store 的根基啊【反X 亡A，不反X 亡B 的感覺】
# 關於小程式商業化
#laurence ：
小程式是否會對開發者收費？對比iOS 開發者，iOS 開發者是收費的，兩者都是需要經過審核的，雖然現在沒有任何關於小程式是否面相開發者收費的消息，但這並不是不可能，服務號碼、訂閱號的認證是收費的，認證之後獲得了未認證所沒有的能力，例如微信支付；我猜測小程式是會有收費的通道，類似認證費一樣（但可能不會叫認證費），然後獲得未認證所沒有的能力，或叫其他名字的費用，按年收取。
潘欣：
各路安卓應用程式市場已經被商業化玩爛了，App Store 也開始了廣告的探索。未來，微信小程式會不會也如此商業化呢？估計會的，但相信不會像安卓市場那樣的氾濫。
小程式紅利先到誰手上？
三堂課：
大家最期待的，是微信的關係鏈，而關係鏈本身，則是微信的命根子，這次的小程式關係鏈會開放嗎？
首先，關係鏈並非不可以開放，是有條件的開放。下圖可以看到，大致上就屬於微信的三個開放邏輯。
只開放公開資訊：暱稱、頭像，其實也就是登陸 ID，所有的開發者都可以接入，例如航旅縱橫。
有條件開放：開放共同使用的好友。例如大眾點評。所以基於大眾點評，你可以看到有好友去哪。例如美團外賣，可以看到好友頭條，例如 58 同城旗下的轉轉，能看到好友在賣，但很抱歉，這個關係鏈的開放，目前只有騰訊投資的公司，才能享受如此特權。
更大程度的開放：除了登陸和好友關係，還開放了朋友圈權限，能把一些操作直接輸送到朋友圈做動作，這個很抱歉，只有騰訊自由的產品才有，例如，QQ 音樂、騰訊影片等。
大概的邏輯是：
所以，大家先別激動的太早，小程式目前的開放程度還是很低的，離 Facebook 的全能力開放還是有差距的。
潘欣：
微信小程式一定還是有紅利期的，我做出這樣的預測：
第一波紅利的得獎者是昨天和今天寫評論文章的微信訂閱號上的自媒體們；
#第二波紅利的獲得者是乾微信小程式培訓的「老師」們，他們應該大多數是從微信行銷培訓迅速轉型過來的；
第三波紅利的獲得者應該是那些獲得內測邀請資格的人們，畢竟上架時間早啊。
再往後，就難說。任何好東西拼得都是執行力。
當然，好東西永遠是稀少的。我不相信你開發一個 App 是垃圾，現在開發一個微信小程式就不是垃圾了。 App Store 和微信平台都只是載體，你的產品是不是使用者需要的，是不是使用者喜歡的才是核心。以微信小程式遠低於 App 的開發成本，可以想像未來提交審核的小垃圾程序是多如牛毛的，衷心希望微信能有比 App Store 更加嚴格的審核程序，否則，微信用戶真的要遭殃了。
什麼類型的產品適合用來存取小程式
李明駿：
這就和Native App 時期有了一定的差別，小程式更歡迎的是服務性App，也就是張小龍所說的用完即時走。微信要做的是長尾市場，聚合那些無法承擔成本獨立做成 App 的服務。就像當年的亞馬遜一樣，幾乎沒有任何商品你在亞馬遜上找不到一樣。而現在微信就等於把商品變成了服務這種非標的東西。
「小而美」的產品更適合應用號，能獲取較多的紅利，真正高頻常用的還是在原生App 那邊更好，當然像同程旅行火車票這種剛需路徑短的還是很適合微信生態的。
小而美的服務是什麼？低頻、非剛需基於場景的服務，在特定場景下（也就是夠垂直）可以較好得解決使用者需求。許多付費的服務可能藉力因此煥發出第二春，教育、醫療、家政、求職招聘、二手買賣、旅遊、票務、金融理財、汽車後市場等等。
三節課：
不是所有的服務都適用小程序，但大部分的服務和幾乎所有的新創業務都是可以接入小程序的。
哪些服務是可以接入，哪些又是不可以接入的呢？我先看一個模型。依照重要/不重要，高頻/低頻，我們將網路產品分別放入四個像限。
然後，我們分別看這4 個像限的擁抱策略，應該說，如果你的服務是很高頻的，而且對於互動和介面體驗的要求很高的話，還是要用原生（Native）來做。但如果你是低頻/中頻且重要的服務的話，你應該毫不猶豫地加入微信小程式的申請隊伍。
象限 1：大玩家、高頻應用程式不應該存取和擁抱小程式。如，3BA（360、百度、阿里巴巴）。
因為使用者經常打開，而且互動頻次很高，對應用程式的體驗要求很高，例如直播、遊戲、影片等。對資料安全度比較高的不應該接入。雖然微信只是讀取了介面，不會直接讓服務者提交數據，但因為小程式一定會提供快取功能，開發者的服務雖然基於H5，但你是跑在微信這個原型框架內的。
象限 2：應該毫不猶豫擁抱小程式。
這個象限包含了大量的服務類別產品。教育、醫療、家事、求職招募、二手買賣、旅遊、票務、金融理財、汽車後市場.
總之，但凡用戶一年用個一兩次之後就再也想不起來的，是不應該用一個原生引用的方式讓使用者下載，而應該是透過微信小程式來解決。新創企業也應該透過小程式來試探MVP 產品，因為微信擁有天然的傳播能力和獲客能力，而原生應用除了開發比較複雜外，推廣成本極高，獲客成本極高，這些都阻礙了MVP的產品探索。
從這個角度來說，小程式能讓中國新創的網路公司減少試錯成本，提升成功機率。
象限 3：慎重接入，利用微信的開放能力，引入用戶到自有產品中。
MVP 後，盡快引導到自由產品，因為自有產品能提供更好的服務，並且能留下用戶，例如知乎、網易雲音樂。內容型的產品，透過微信獲得新用戶，然後轉移到自有平台，也是一個很好的策略。
象限 4：視情況接入，主要看開發能力。
基本上很多都是個人興趣產品、工具產品，可以從MVP 的角度來做，或是以興趣的角度來做，不考慮太多的商業產出，只考慮情懷，但這些開發者有個明顯的問題，就是產品設計能力和開發能力有限，所以，如果你的人是做APP 的，那就還是APP 吧，如果是H5 的，那就微信小程式唄。
小程式與Native App 的優劣之爭
yseternal ：
HTML 5、JS 以及相關技術替代原生大家喊了很久了，就是大熱的React Native 目前看來也依然很不完善。微信的應用應該都是運行在騰訊瀏覽器的X5核心裡，這東西怎麼樣大家心裡都有數。我感覺還是只能做一些低互動的應用，大概也就是比網頁快捷方式高一級別，要利用OS 的酷炫特性，原生還是跑不掉，而且目前原生開發很成熟了，框架庫很多，門檻也很低。
三堂課：
小程式不同於服務號，服務號的功能需要全部在Web APP 中提供，而小程式是微信中的Native 程序，是有快取能力的，C 端使用者訂閱（暫且這樣說）某小程式後，當有快取的時候不僅會提高使用者體驗，同時也加快了程式載入速度，使用者在網路速度不佳的時候的等待時間將大大減少。
小程式是基於H5 開發的程序，但用了類似JS-SDK 的框架（百度以前是clouda框架），提供了更多的介面和元件，讓程式更加流暢，體驗接近Native App。能夠在雲端發布程式（當然也需要微信審核），同時也能快取資料，實現了借助微信這個最大的 Native App 來讓 H5 App 更強大的目的。
以上是大家最關注的幾個「微信小程式」主題的詳細內容。更多資訊請關注PHP中文網其他相關文章！
