Pages

Monday, December 26, 2011

App Store Review Guidelines 送審前十項常犯必檢查項目表

App Store Review Guidelines
一個 iOS App 在送審過程會經歷的階段有:
  • Waiting for upload
  • Upload received
  • Waiting for review
  • In review
  • Ready for sale.

這是一個順利的轉換過程,但是如果不幸的審核沒過,就得再來一次。在 Apple Developer Center 裡面有一分相當重要的文件叫做 App Store Review Guidelines。不知道身為時常送審的  iOS App developer 您閱讀過這份文件了嗎?
以下為我們和其他同樣開發 iOS App 送審經驗朋友們,收集過去送審前一定要檢查的十大重要項目,根據過往經驗ㄧ犯規就是會被退審的項目,而這些項目在這份文件裡面都有清楚重要聲明:
  1. Apps 如果在審核過程操作上會 Crash,是會被退審的。
  2. Apps 如果有功能是非文件上記錄,或是 App 描述上沒有寫出來出現的隱藏功能,是會被退審的。
  3. Apps 如果用了非 Apple 公開的 APIs 也就是 private APIs,是會被退審的。
  4. Apps 如果單純是市場調查工具或是純廣告的,會被退審。
  5. Apps 如果單純只是歌曲或是電影,請送到 iTunes store,Apps 如果單純只是書籍,請送到 iBookstore。
  6. Apps 分類項目如果跟 App 本身內容呈現不符合,會被退審。
  7. Apps 如果只呈現空白的廣告區塊,卻沒有廣告,是會被退審。
  8. Apps 如果引用了第三方的內容 (版權、商標等) ,必須要檢查是否有符合使用規定。
  9. Apps 如果用了 Google Map, Google Earth 圖片,卻擅自隱藏或是修改 Google 的 logo 或是版權所有標誌,是會被退審的。
  10. Apps 如果設計上用了跟 iOS Human Interface Guidelines 規範相反或是錯誤行為,是會被退審的。
這禮拜日子很特別,有中國人的冬至,有西方人的聖誕佳節,尤其 Apple 要過年放假,所以在一個月前就寄信出來給所有 iOS 開發人員:
iTunes Connect will be temporarily shut down from Thursday, December 22 to Thursday, December 29 for the winter holidays. During this shutdown, the following functionality will be unavailable:
  • Access to iTunes Connect
  • The delivery of any apps or updates.

意思是在美國時間 12/22~12/29 這段時間,iTunes Connect 會關閉,任何跟 App 更新送審都會不受理。對於 Polydice Inc. 的 iOS Team 過去這週也在這波趕開發送審的時程下,搶灘拼送審。您是否也跟我們一樣在這聖誕佳節的氛圍下搏命一擊呢!

本篇最原始由 Edward 發表於 thepolydice.com 的部落格文章 App Store Review Guidelines 送審前十項常犯必檢查項目表

Tuesday, December 20, 2011

Share Archives to Teammates in Organizer

Share from been archive
每當我們將 Xcode 專案寫好想要 Archive 起來作為後續釋出的流程,都可以成功的包裝即顯示在 Organizer 裡面,Xcode 會幫我們自動導引到 Organizer 的 Archives 區域,看到過去所有的紀錄。在 Xcode > Window > Organizer - Archives 區域,時常可以做事情有:
  • 在該建立的記錄按下 Comment 區塊,記錄些重要事情,為何這份 Archive 有它不同處,跟過去歷史記錄作區別。
  • 如果要送審會選擇右上方的主要按鈕:Validate 和 Submit。
  • 如果要分享出去,匯出成某種形式,則選擇 Share。
在 Share 裡面,關於匯出的內容本身 (Contents) 可以分為 iOS App Store Package (.ipa)、Application、Archive。在 .ipa 對於我們用 Ad Hoc 方式來發佈是最常用的。

這邊想要特別記錄 Archive 幫助了我怎麼樣的突破難關。過去因為在開發上想要體驗最新最酷的功能,所以也安裝 Apple 在 Developer Center 釋出的 beta 版本 Xcode,而也安裝了該開發工具,但是當最後專案完成,準備要提交給 Apple 送審時候,才發現不管怎麼弄,在第一關驗證 (validate) 就是無法過關,看了關鍵字句,才發現真正的原因。
Xcode 4.3 Developer Preview 2 cannot be used to submit apps to the iOS or Mac App Store. Continue to use the publicly released version of Xcode to compile and submit apps to the App Stores.
也就是在 Apple 網站上有特別聲明了,用該最新 Xcode 來開發測試是沒問題,但是目前不允許透過這版來提交 Apps 給 App Store,還沒開放問市的意思,請多多配合。

慶幸的是我們的夥伴是有安裝正式版的開發環境,馬上請他幫忙將要送審的專案 Archive,再透過 Share Archive 將該專案包裝起來匯出來給我這台卡住不能送審的環境。因為可能環境上我才有送審所需要的各種資源,包含密碼、private key、certificate、provisioning profile 等種種,需要從一台沒法送審的 Xcode 來提交送審。

於是透過這樣的步驟,解決了無法送審的方式:
  1. 用 Share Archive 方式將專案程式匯出。
  2. 將 Archive 點選兩下,即可匯入想要匯入的 Xcode > Organizer - Archives 裡頭。
  3. 這時候就可以繼續後續動作,不論是 Validate、加上 Code sign、Submit 提交給 Apple 等流程。
藉由我們少用的 Archive 步驟,來完成某時候緊急所需要的解決方法。

當問題出現、時間緊急不是 Xcode 重新下載重新安裝所可以接受的情境下,透過對於專案匯出送審有更明確瞭解,即能協助我們自己度過緊張時刻,另外當然有些重要規範平常也是要多多注意來避免狀況發生。

Sunday, December 11, 2011

改造優惠類型 iPhone App 藉由資訊整理做起

改造優惠 For iPhone App
我想做個挑戰,我不相信做優惠做促銷的 iPhone App 一定要搞的花俏無比,資訊多到很雜亂、功能多到不知道提供了哪些功能,讓人們不覺得這是它們所要的 App。

讓我們回到為使用者設計。

以下列出設計上常犯的盲點:
  • 資訊充足,但是卻提供太多動線選項讓使用者選,就會讓使用者覺得資料很雜亂,沒有整理過的反效果。
  • 首頁提供太多動線給使用者,讓使用者無從著手哪個是起點。
  • 資訊因為五花八門,而必須提供篩選功能給使用者篩選,造成反效果。
  • 因為廣告就一定要花俏,要花俏就必須要很多動畫與誇張特效

讓我們回到使用者想要的是什麼,這邊列出根據過去接觸過手持 iPhone 臺灣朋友特性條列:
  • 他們希望乾淨、有質感的 App,也許他們說不出原因,但是他們比較得出來 5 顆星和 3 顆星的差別。
  • 他們希望這個 App 是有個人化的,不論是資料分析、個人喜好等等。
  • 他們希望動線越少越好,好用比較重要。
  • 他們希望每天打開來可以有驚喜。

於是開始做了規劃,App 名稱叫做改造優惠 for iPhone App,描述:提供一個根據您所需要各種優惠訊息,讓繁忙的你、每天外出想要找尋新消息的 iPhone APP。功能特色支援使用者位置定位、透過個人化習慣傳遞優惠訊息、收藏優惠訊息和優惠券等等功能。

Wednesday, December 7, 2011

Opened pull request on GitHub

點圖放大
本篇最原始由 Edward 發表於 thepolydice.com 的部落格文章 Opened pull request on GitHub
 
GitHub 首頁上有個很顯目的 Banner,它告訴我們 Developers 如何參與 GitHub,簡單四步驟:
  1. 建置開發 Git 環境。
  2. 建立一個 Repository 作為程式碼控管儲存的地方。
  3. 從某個 Repository 建立分支 Fork,可以視複製或者是建立全新的。
  4. 多點社交,可以從追蹤朋友和監看關心某個 Project。
我們在 GitHub 上面最大的驚喜不外乎是我們挖到寶了,所謂挖到寶是找到很酷炫的某個元件功能、可能是某個已經整合好的套件、可能是已經完成自己即將開發功能。接下來將該 Repository 引用回來,並且透過 Sample code 做火力展示,這種喜悅我們很常發生。但是是否發現專案需求改變,新功能不但要達成,可能甚至要擴充,那麼我們原來下載回來的或是引用回來的 Project 該怎麼使上力呢?甚至未來如果我自己改了 Code,但是原出處有更新版,想要享用,有什麼配套措施可以用呢?