蘋果 App Store 收費模式的改變

在「APP STORE 2.0」這邊提到了正式的訪談:

In a rare pre-WWDC sit-down interview with The Verge, Phil Schiller, Apple’s senior vice president of worldwide marketing, said that Apple would soon alter its revenue-sharing model for apps.

70/30 的拆分方式有改變,並且擴大開放的範圍:

While the well-known 70 / 30 split will remain, developers who are able to maintain a subscription with a customer longer than a year will see Apple’s cut drop down to 15 percent. The option to sell subscriptions will also be available to all developers instead of just a few kinds of apps. "Now we’re going to open up to all categories," Schiller says, "and that includes games, which is a huge category."

這張圖清楚的道出了這次的改變:

另外在 John Gruber 跟 Phil Schiller 的電話訪談「The New App Store: Subscription Pricing, Faster Approvals, and Search Ads」提到了更多項目。

用 Pushover 當簡訊...

很久之前被 ccn 介紹 Pushover,可以很簡單的透過 API 送推播,這樣就可以用來代替簡訊發給自己。

第一次申請有七天的試用期可以用,試用期滿後每個 device 的費用是一次性的 USD$4.99,在 iOS 裝置上可以透過 IAP (Apple) 購買,Android 裝置則是透過 IAB 購買。

官網上可以看到 API 設計很簡單,user token + application token 用 POST 帶進去就可以發出去了。

就算不透過 API 寫,也可以透過 IFTTT 串接起來,像是我設定中文維基百科上的條目「Kalafina」,有修改就通知我:

Basecamp 對「請使用者評價五顆星」的作法

由於 app 排序受到評價影響,現在幾乎都把這塊當作是重點。

Basecamp 的人寫了一篇他們怎麼做的方法:「Getting from ⭐️⭐️ to ⭐️⭐️⭐️⭐️⭐️」。

傳統的作法類似這樣,使用者沒有太多動力,而且看到時頗煩人:(因為每個 app 幾乎都這樣做)

而 Basecamp 決定告訴使用者新版本有哪些新功能,然後邀請他評價:

這成功拉高了評價分數,並且也推廣新功能。

Google 推出 iOS 上的搜尋輸入法 Gboard

Google 推出了 iOS 上的搜尋輸入法 Gboard:「Meet Gboard: Search, GIFs, emojis & more. Right from your keyboard.」,可以在 App Store 上下載「Gboard — Search. GIFs. Emojis & more. Right from your keyboard.」,目前只有英文版可以用,其他語言還要等:

Get it now in the App Store in English in the U.S., with more languages to come.

可以參考 Google 做的 GIF 動畫,把搜尋的功能結合進去了:

John Gruber 寫了一篇「Gboard」關於隱私問題的討論,看起來還頗正面的。除了搜尋結果當然會需要傳到 Google 的系統裡以外,只有 crash log 會匿名傳回去。

Apple 要求六月開始的 iOS 程式都必須能在 IPv6-only network 運作

Apple 對 iOS 程式的新政策:「Supporting IPv6-only Networks」。

也就是說,在 ISP 提供 NAT64 的環境下 client 想要連 210.61.183.31 時會連 IPv6 的位置 ::d23d:b71f,ISP 會幫忙 NAT 出去。而client 端的應用程式要能夠在這樣的網路環境下正常運作。

這測試環境沒建過,不知道會遇到什麼問題... @_@

結合 Malware 與 Social Engineering 的詐騙

在「Malware scam appears to use GPS data to catch speeding Pennsylvania drivers」這邊看到新的詐騙方式。

手機的 malware app (藏有惡意程式的 app) 會要求 GPS 資料 (現在智慧型手機上 app 的常態),而當 malware app 偵測到你超速時,詐騙集團就會發出假的超速罰單,像是這樣:

From: Speeding Citation
To: (Accurate Email Removed)
Date: 03/11/2016 03:08 PM
Subject: [External] Notification of excess speed
First Name: (Accurate Name removed)
Last Name: (Accurate Name removed)
Notification of excess speed
Route: (Accurate Local Township Road –removed)
Date: 8 March 2016
Time: 7:55 am
Speed Limit: 40
Detected Speed: 52
The Infraction Statement contains an image of your license plate and the citation which must be paid in 5 working days.

文章提用的標語「ACCURATE SPEEDING DATA, FAKE EMAIL」好讚... XD

透過你用的 App 猜測你的性別、婚姻狀態與收入範圍

在「Quiz: Can we guess your age and income, based solely on the apps on your phone?」這篇給了一個測驗,透過回答 32 題 Yes/No 的答案來猜測你的性別、婚姻狀態與收入範圍,大約是 61% 到 82% 的準確率:(為什麼會是一個範圍?)

Based on those models, they then found that they could predict a user’s gender, age, marital status and income with between 61- and 82-percent accuracy.

會猜測四個答案,所以是 16 種組合:

There are 16 possible results, based on your gender (male/female), your age (over/under 32), your marital status (married/single) and your income (over/under $52,000).

做完後很不準 XDDD

我猜測用的方式與很久前 pest 講的「網路廣告商怎麼知道你是誰? 從 ClickStream 來判斷用戶資料」的方法類似,用已知的資料去 train 出一個模型,再丟進去判斷...

印度的 Uber 將會有「Panic Button」提供給乘客

在「Uber has a panic button in India. But don’t expect it to come to the U.S.」這邊看到印度的 Uber 將會有 Panic Button 給乘客使用,馬上想到這種按鈕 XDDD

不過實際讀了文章以及官方的說明「Uber Upgrades In-App Safety Features in India」後,發現是 app 裡面的緊急通報:

這應該是因應先前印度發生好幾起 Uber 司機犯罪事件所做的改變 (參考「India Uber driver guilty of rape」)。

Zite 消失後的方案:Nuzzel

在去年十二月七日 Zite 被幹掉後,本來是流竄到 Prismatic 上,結果十二月二十日也關掉了... 之後就找不到能用的推薦引擎了。

用推薦引擎的目的是希望看到更多不同種類的內容:用 Feedly 看 RSS feed,而用 Twitter 追蹤短則的想法,或是用 Facebook 看同溫層的想法。但這些都是「已知」的來源所提供的資訊,沒有辦法發覺其他的文章。

其中一個變通的方法是找像 Hacker News Daily 這樣的 RSS feed 來讀,作者用程式每天算出 Hacker News 上的十大熱門文摘出來,對一般人應該也夠用,但我還是想要找到更多資訊。

Zite 與 Prismatic 是以 Recommendation System 來計算並且推薦,是個還不錯的方法。不過這兩個 app 都已經不在了...

Nuzzel 走了另外一個方向,你可以用 Twitter 與 Facebook 帳號連結,然後提供「朋友」以及「朋友的朋友」發表了什麼連結,依照時間或是數量排序出來:

相較於推薦系統,這樣的演算法雖然簡單很多,但解決了想要看更多資訊的問題。

不過還是覺得有些 app 上的操作怪怪的,但也沒辦法 (?),先用用看吧...

微軟的 CodePush

看到微軟推出的 CodePush,針對 CordovaReact Native 類透過 WebView 跑的程式提出的方案。原因是 Apple 的 App Store 審核都要很久,透過 CodePush 可以直接更新程式:

CodePush is a cloud service that enables Cordova and React Native developers to deploy mobile app updates directly to their users’ devices. It works by acting as a central repository that developers can publish certain updates to (e.g. JS, HTML, CSS and image changes), and that apps can query for updates from (using our provided client SDKs). This allows you to have a more deterministic and direct engagement model with your end-users, while addressing bugs and/or adding small features that don’t require you to re-build a binary and/or re-distribute it through any public app stores.

FAQ 文件裡提到了這點:(Frequently Asked Questions · CodePush)

Does the Apple App Store allow developers to perform these types of updates?

According to section 3.3.2 of Apple’s developer agreement, as long as you are using the CodePush service to release bug fixes and improvements/features that maintain the app’s original/presented purpose (i.e. don’t CodePush a calculator into a first-person shooter), then you will be fine, and your users will be happy. In order to provide a tangible example, our team published a (pretty cheesy!) CodePush-ified game to the Google Play Store and Apple App Store, and had no problems getting it through the review process.

Because Cordova apps are executed within a WebView, and React Native apps are executed within JavaScriptCore, from a technology perspective, these runtimes are unique in their ability to leverage dynamic code downloads according to the aforementioned Apple developer agreement.

同樣的想法如果真的可行,應該會有其他更開放的 open source 方案可以用 (而非綁定性的服務,而是可以掛到自己的 CDN 上下載更新),先觀察一陣子...