ios app 上架時app icon要注意事項

按照apple ios app icon標準(App Icon Attributes):
All app icons should adhere to the following specifications. 所有app icon須符合下列:

-Format： PNG  , 一定要png...但全彩png size很大 ..
-Color： 注意24bit不要有透明色在上面.
-Layers： Flattened with no transparency.
絕不可以有alpha透明色.
-Shape Square with no rounded corners
不可以有圓角,之後apple會統一用圓角特效上去.

-Resolution:
-iPhone X, iPhone 8 Plus, iPhone 7 Plus, and iPhone 6s Plus @3x
-All other high-resolution iOS devices @2x

ps: 建議不要使用 PDF 檔案..
pdf內是一個向量圖,本來是用來減少png的size太大問題.
但對於較複雜的圖像而言 PNG 的表現實際上是優於 PDF 的.
iOS系統會自動把 30x30 的 PDF 圖檔做成 @2x 60x60 的 PNG 圖檔.


很複雜的官方說明：



Image Size (px)
File Name
Used For
App Store
512x512
iTunesArtwork
App list in iTunes
Do not include
1024x1024
iTunesArtwork@2x
App list in iTunes on devices with retina display
Do not include
120x120
(最重要!)
Icon-60@2x.png
Home screen on iPhone/iPod Touch with retina display
Required
180x180
Icon-60@3x.png
Home screen on iPhone with retina HD display
Optional 
76x76
Icon-76.png
Home screen on iPad
Optional 
152x152
Icon-76@2x.png
Home screen on iPad with retina display
Optional
167x167
Icon-83.5@2x.png
Home screen on iPad Pro
Optional
40x40
Icon-Small-40.png
Spotlight
Optional 
80x80
Icon-Small-40@2x.png
Spotlight on devices with retina display
Optional
120x120
Icon-Small-40@3x.png
Spotlight on devices with retina HD display
Optional 
29x29
Icon-Small.png
Settings
Recommended 
58x58
Icon-Small@2x.png
Settings on devices with retina display
Recommended 
87x87
Icon-Small@3x.png
Settings on devices with retina HD display
Recommended 

重要！icon尺寸太多,輸出非常麻煩.
因此我們只要建一個最大的1024x1024. photoshop 輸出png 24bit 無透明層.其餘size交給網站.
https://appicon.co/


我是不喜歡要輸入email才能下載的,這網站不用輸入.
zip解開直接取代Assets.xcassets資料夾.
連icon拖都不用拖,如果看到有”緊告號！“的話把那個單獨有問題的icon移除.

 結果:



最後是上架後,螢幕快照.
5.5, 12.9兩張... 用模擬器跑, 抓圖後需要resize成正確大小.

APP 預覽和屏幕快照

屏幕快照規範

您必須為每個設備類型提供一組屏幕快照。針對iPhone，您需要一組用於5.5 英寸顯示屏的屏幕快照；而針對iPad，您需要一組用於12.9 英寸顯示屏的屏幕快照。
針對iPhone X 5.8 英寸顯示屏的素材是可選的，且無法縮放至其他設備尺寸。您向App Store Connect 上傳的iPhone X 屏幕快照會帶有圓角顯示。
設備尺寸或平台
屏幕快照尺寸
必填項
5.8 英寸超視網膜顯示屏
縱向分辨率為1125 x 2436 像素
橫向分辨率為2436 x 1125 像素
可選
5.5 英寸視網膜顯示屏
縱向分辨率為1242 x 2208 像素
橫向分辨率為2208 x 1242 像素
必填

12.9 英寸視網膜顯示屏
縱向分辨率為2048 x 2732 像素
橫向分辨率為2732 x 2048 像素
必填

最後！等兩天～等上架結果！
歡迎大家多支持台灣本土開發者！

https://itunes.apple.com/us/app/stopwatch-classic/id1398815464?l=zh&ls=1&mt=8



留言

張貼留言

這個網誌中的熱門文章

最爛的銀行服務-玉山銀行

圖片
今天寫信給玉山銀行,問他說能不能給予我免費跨行轉帳次數, 我是他們大客戶....常常需要轉帳跟提款.發現這樣被扣手續費很不划算. 玉山銀行的atm又很少見. 但是得到的回應是這樣： 看完這信,有回答等於沒回答,當下我就決定要轉到其他家銀行了, 只是有點麻煩,股票帳戶,外幣帳戶,黃金存摺帳戶... 玉山銀行在我家附近連一台提款機都沒有，每次都要借台新銀行或中信銀行的atm. 把錢放在這裡實在不方便,不斷被扣轉帳手續費跟提款手續費． 你看台新銀行richard給我五次免費額度. 使用其他家例如合作金庫與兆豐銀行都有台灣pay可以免手續費. 玉山銀行？？？？ 今天開始要開始廢棄玉山銀行了．．．． 而且看這回信後,我也覺得玉山銀行很爛,自己不建atm,又不給客戶免費跨行提款次數,叫我跑大老遠自己搜尋ATM. 建議大家他的股票: 玉山 金控 ( 2884 ) 也不要買, 股價一定會慢慢下跌的,看他們家的服務讓客戶一個一個跑掉，就知道了 . 未來不是有很多純網銀出來嗎？ 他們都會給予更多免費跨行轉帳次數. 感覺未來這種服務不佳的銀行都準備被淘汰吧. 對於app設計師來說： 這種回答也是最不佳的. 我們要對user友善點,使用者反應app會當機,有問題時， 回答要能解決他們的問題. 千萬不能像玉山銀行客服人員這樣回答. 使用者都是很厲害的,他發現你沒鳥他，明天開始就刪除app了. PS:後來去辦了兆豐銀行.行員說只要辦個數位帳戶就有10次跨行提款...而且已經有一般非數位帳戶也可再申請一個數位的. 相比玉山銀行還限制如果有玉山帳戶者再申請數位帳號也沒有跨行轉帳提款優惠,玉山真的好差... 除此之外,台新銀行也給我各5次免費跨行轉帳+提款次數 真的好好..(以上都不用薪轉戶,一般人都有資格可以申請) 有了15次轉帳跟跨行提款免費,就不用到處找ATM.... 心情好多了,現在欠缺的就是錢了
閱讀完整內容

更改google drive預設存放目錄位置Change Google Drive Default Folder Location in Windows

圖片
Google drive預設存放位置是放在C:\Users\username\Google 雲端硬碟.有些人c槽是ssd,空間有限.如果一不小心,像google drive空間有1TB的人. SSD就被塞爆...需要改放在其他磁碟機..(例如c是ssd, D是一般硬碟..可能有幾TB) 1.如果之前已經安裝的人,首先先解除帳戶連結.解除後再刪除掉目前的舊的Google Drive 目錄.釋放已占空間.(不用擔心,因為已經備份到雲端,待會會自動再下載回來.) 2.再次登入帳戶,在最後一頁時.不要那麼快按確認,這裡有個"進階設定". 3.這邊可更改預設資料夾...我們把他改到D槽...或其他槽. 建一個新目錄,取個好記的名字,例如"[GoogleDrive]",加上特殊字元"[" "]"可讓資料夾排在最前面,將來比較好找.更改好之後,再選擇這新資料夾.   PS: 也建議大家不要把Google drive預設資料夾放在C:\Users\username\Google 雲端硬碟. 一則不方便找.二則重灌電腦時,會忘記這邊有資料,整理起來很麻煩.三是C通常是SSD,容量小,設在D槽(如果是HDD的話),可避免塞爆SSD.
閱讀完整內容

SMR疊瓦式hdd致命缺陷被解決????!!!

圖片
新聞來源: https://tech.sina.cn/2019-12-25/detail-iihnzahi9980174.d.html 現在90%所有的硬碟 … 除了SSD 之外都是採用PMR 技術，但為容量增長而發展的SMR( 疊瓦式磁紀錄)會比較便宜不要踩地雷 。 PMR、SMR 硬碟分別是什麼？ PMR (perpendicular magnetic recording，垂直磁性記錄). 寫入磁頭會比讀取磁頭來得大，因此硬碟供應商若要增加磁錄密度，就會儘可能讓寫入磁頭的尺寸縮小至物理極限為止。 SMR (shingled magnetic recording，疊瓦式磁性記錄). SMR 採用的技術是讓資料循序寫入，如其名稱所示，磁軌會如瓦片般堆疊在另一磁軌的部分面積上，藉此達到增加磁錄密度的目的。在此情況下，讀取磁頭仍可從磁軌上未被覆蓋的部分來讀取資料。   玩家對SMRHDD避之唯恐不及，因為這種HDD性能、可靠性都有問題，但它能提升HDD存儲密度大約1/4 PMR 與 SMR 的差異 當 SMR 硬碟上循序寫入新資料時，這些如瓦片般堆疊的磁軌仍可正常讀取， 並不影響讀取效能。 不過，一旦已寫入的資料要修改或覆寫時，寫入磁頭並不會直接在既有的磁軌上進行磁錄，以避免毀損相鄰的磁軌。 編輯後的資料會先在磁碟上的空白處寫入，原先舊資料的磁軌會暫時維持不動。 等到硬碟閒置時才會進行重新整理的機制，將原先磁軌上的舊資料自動清除，並重新成為可用空間以供新資料寫入。 就前述的重新整理機制而言， SMR 硬碟的閒置時間就顯得相當重要。如果 SMR 硬碟長時間進行密集的覆寫任務，則會沒有足夠的閒置時間來重新整理磁軌，暫時不動的既有資料磁軌數量會越來越多。接著導致 SMR 硬碟必須一邊寫入新資料，一邊重新整理舊磁軌，進而對讀寫效能造成某種程度的影響。 WD他們開發了名為Zonefs的文件系統，有望解決SMR HDD寫入數據時的弊端，同時也適用於SSD。 WD近年來一直在研究分區存儲（Zoned Storage），它將 HDD的LBA空間分成多個區塊，只能從每個區塊的開頭順序寫入數據，而且數據不能任意覆蓋。這種數據存儲技術可以改變SMR、SSD HDD存儲、寫入數據的方式，不會再像現在這樣有很多隨機
閱讀完整內容

google play 正式發布前測試報告...非常好用.

圖片
Google developer console內的 正式發布前測試報告(Pre-launch report)...非常好用. 要產生應用程式的正式發佈前測試報告，要請將應用程式發佈至開放式beta、封閉式alpha或內部測試群組。 它有 三個版本. 到底該用那一個? 我是用 內部測試 之後會升到 alpha. (內部測試群組--> alpha --> 正式release.) 內部測試: Fast: You can distribute apps via the internal test track much faster than the open or closed tracks. When you publish a new APK or app bundle to the internal test track, it will be available to testers within a few minutes.  (幾分鐘之內會生效給測試者) 但我主要是要他幫我跑"正式發布前測試報告".  會發現很多自己在測試時沒發現的問題. 不過因為一直出現紅字,但我自己又測不到問題在那. 因為改了一些我認為有問題的code. 一直上傳請他幫我測試,不知道這樣會不會是違規?  google play審核人員看你一直上傳,不生氣才怪, (這會浪費他們時間,可能下次審核時間給你延長幾天.等你確定後不再上傳才一次審核完 .) 目前我是先用"內部測試群組",這樣就不用經過google play審核人員審核.等都all pass都是綠色後,才升版到alpha. 發生bug..他告訴我大概位置： Caused by: java.lang.IllegalStateException: The application's PagerAdapter changed the adapter's contents without calling PagerAdapter#notifyDataSetChanged! Expected adapter item count: 100, found: 5 Pager id: com.mark.TOEICtes
閱讀完整內容

關於google play console app應用程式簽署

圖片
應用程式簽署 只要加入 Google Play 應用程式簽署計畫，您就能以安全的方式為新的和現有的應用程式管理應用程式簽署金鑰。系統會透過安全的基礎架構 (與 Google 用來儲存自身金鑰的基礎架構相同) 妥善存放金鑰。 如果您遺失了金鑰庫，或認為金鑰庫遭到破解，Google Play 應用程式簽署計畫可以讓您提出重設上傳金鑰的申請。如果您在沒有註冊加入 Google Play 應用程式簽署計畫的狀況下遺失了金鑰庫，則必須使用新的套件名稱重新發佈應用程式。 當然要加入啦, 但加入後就有很多問題產生了,會有三個SHA1金鑰產生,不同的sha1.用的地方不同. debug跟release 跟 google play 會自動二次簽章. 上傳APK後,就是不同的SHA1. 要去Google play console看. 如圖上,紅框處:就是真正user下載到的app的實際sha1. 填錯,firebase 就不能用喔~~~ -->用這指令只是看目前你手上的KEYSTORE他的SHA1,在DEBUG時期用的. 指令: (紅色改成你的) keytool -exportcert -list -v -alias YOUR_KEYSTORE_ALIAS -keystore YOUR_KEYSTORE 輸出: 輸入金鑰儲存庫密碼: 別名名稱: --- 建立日期: 201-- 項目類型: PrivateKeyEntry 憑證鏈長度: 1 憑證 [1]: 擁有者: --- 發行人: --- 序號: --- 有效期自:--- 憑證指紋:          MD5:  90:3E:----E3:8D          SHA1: E1:3F:3---5A:96          SHA256: 40:F8:0----2:F6:10 簽章演算法名稱: SHA256withRSA 主體公開金鑰演算法: 2048 位元的 RSA 金鑰 版本: 3 擴充套件: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ ---                                ,... ]
閱讀完整內容

舊有app在Android 12 閃退問題& app Splash screens

圖片
現在越來越多手機開始轉成android 12. 於是我就把target sdk = 31 試試看. android {       compileSdkVersion 31      defaultConfig {           targetSdkVersion 31      } } 結果舊有的app都開始發生了閃退現象. 就有使用者跟我反映app當機問題出現.因為這屬於不可歸咎app設計的問題..必須要在android 12的機器上跑才會發生,而且android developer console中Pre-launch report 也沒測試出問題. 但一跑android 12模擬器就會發生當機,所以真的會有問題. 只能說寫app要處理的突發情況有很多,這是其一. android app發佈控制台好的地方是當你上傳apk時,他都會幫你自動做Pre-launch 測試. 這次android 12會突然當機的問題,理應要先被Pre-launch 被發現才對. 我檢查後才發現,原來連Pre-launch都沒測試到最新的android 12. 他只測試到android 11. 但目前很多新機子已經開始系統更新到android 12去了.這就是問題會發生的原因. ---- error message: java.lang.IllegalArgumentException: com.mark.electricitybillcalculator: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.     Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles. Solution: 修正android 12上當機閃退問
閱讀完整內容

Mark App Design Apps - Terms and Privacy Policy (服務條款,隱私權政策)

Privacy Policy The Privacy Policy when you use "Mark App Design" Apps: This policy is effective as of 2020-05-19 This page is used to inform visitors regarding my policies with the collection, use, and disclosure of Personal Information if anyone decided to use my app. If you choose to use my app. then you agree to the collection and use of information in relation to this policy. The Personal Information that I collect is used for providing and improving the Service. I will not use or share your information with anyone except as described in this Privacy Policy. -Packet TV apps use Youtube API Service (terms link: YouTube API Services Terms of Service ), when you use this app,  you are agreeing to be bound by the YouTube Terms of Service. and Google private policy please also see Google Privacy Policy Mark app design built the Pocket TV app and my most app as a Free app. These apps are provided by "Mark app design" at no cost and is intended for use as is. 使用app需受 G
閱讀完整內容

寫APP真的是好工作嗎? Firebase host與我對Kotlin的感想

圖片
最近在找工作,經過1個多月後,還是沒找到,有點不順利,收到很多無聲卡, 難過了好幾天,然後我感覺.... 1.寫APP真的是好工作嗎? 台灣好像不缺app軟體工程師....(現今在網路上或補習班，能找到大量手機 App 或網頁之類的前端開發課程。但一套應用系統，需要前端與後端整合才完整。很多資深工程師(well-trained)像我,不得不必須要跟新人競爭,但通常公司不太會分辨何謂新手與老手?) 2. 感覺上,IOS工程師似乎比ANDROID 工程師更稀少與缺乏,更好找工作. 3. Covid-19疫情風暴下,能不能去面試都是一個大問題. Delta 變種病毒來勢洶洶,如果去台北面試時中途被感染,可能又會害到面試官跟自己.... 4.竟然還有公司開app工程師4萬多的薪水,好多雇主都不懂行情啊~一位app工程師多難培養阿,要賺四萬多薪水我還不如去作一些不需要如此花費腦力的工作.薪水雖低一點但不用像app工程師寫程式寫到累的半死.... ----- about Kotlin  Kotlin Playground:   https://developer.android.com/training/kotlinplayground 現在找工作android都要求Kotlin, 但其實Kotlin造成更多混亂... 混亂1: Java 8現在也支援lambda與很多其他新功能...不會比Kotlin差 混亂2: android 工程師需要會java外,又要多學一套Kotlin,當然有時還要會swift/ios, dart/flutter, 基本的c/c++也都要記得. 腦容量不足.目前在google的android官方文件範例中,已經可以見到這種兩種語言並行時產生的混亂,每個重要功能的解說範例,變成需要有java的example, 也需要有Kotlin的範例,缺少任何一種,都會導致對方的擁護者抗議. 這在Stack Overflow上更是產生極多的類似抗議. 混亂3:  在開源社群中 GitHub source code 多了Kotlin分類, 導致原來java的open source 感覺低人一截,開發者對於要開發新版本時,不知道要用java還是Kotlin.....導致open source原始碼產生分支,不統一. 由Kotlin編寫的open source,對原有的j
閱讀完整內容

Google Play badge徽章產生器

圖片
Welcome to the Google Play badge page  千萬不要自己設計Google play 標籤,這裡有官方網站可產生之: https://play.google.com/intl/en_us/badges/ deliverable type: 選擇digital badges,可產生 HTML 連結 就可貼到其他地方. 選擇print 的話,只有 一張高畫質EPS圖,可在Photoshop處理,不需要再從別地方找了. 就像這樣:點了會到google play store:
閱讀完整內容