SnapPress
SnapPress 2.0.1 剛剛送審，而這次的主角不是新功能，而是把 App Store 中介資料完整本地化到九種語言，外加一整套讓它能持續維持下去的技術管線。這篇文章就是這個版本背後的故事。
背景
SnapPress 在 2026 年 3 月推出。產品定位很單純：別再花 30 分鐘把照片一張一張上傳到 WordPress，直接用 iPhone 在 10 秒內把 20 張照片送進媒體庫。4 月底的 2.0 版加入了 freemium 機制、終身買斷方案，以及更穩定的 Share Extension。銷售量不算大但確實有，主要是日本的 WordPress 部落客直接從日本 App Store 購買。
意外
有兩筆購買來自澳洲。沒投廣告、沒做媒體曝光、也不是我認識的人。這些買家是自己透過 App Store 搜尋找到 SnapPress 的——而那時候我才意識到，我的中介資料其實幾乎沒有在地化。
那一刻，我用一個外部使用者的視角重新打開 App Store Connect 的後台。然後看到一件事，把當天剩下的優先順序整個翻過來。
問題
App Store 副標題欄位——也就是 App 名稱底下那行 30 個字、會出現在搜尋結果與分類瀏覽中的副標題——是空的。每一個語系都是空的。App Store 提供的九個本地化語系欄位全部空白，包括既有使用者最多的英文與日文兩個市場。
副標題是 App Store 搜尋排序中權重最高的欄位之一。Apple 給它的可索引權重，跟 App 名稱本身幾乎同一個量級，而且它是搜尋使用者點進產品頁前看到的第一段補充文案。把它留白，等於每個語系都自願放棄 30 個關鍵字字元，再乘上 9 個語系，再乘上每一個重要的搜尋字。
關鍵字欄位則只填了一部分，而且只有英文與日文，連「bulk」、「iPhone」、「blogger」這些核心字都沒進去。產品描述也只有英文跟日文。宣傳文字全部空白。唯一在所有語系都填滿的，諷刺的是之前順手設定過的更新說明。
修法
我用一個週日下午寫了兩套小型 CLI 工具。
第一套接 App Store Connect API：讀取目前所有語系的本地化狀態、產生新的 App 版本、透過 appInfoLocalizations 端點把副標題推上去、再透過 appStoreVersionLocalizations 端點把關鍵字／描述／宣傳文字／更新說明／支援 URL／行銷 URL 推上去，最後綁上剛 archive 出來的新 build。認證用 App Store Connect API key，整個流程不用人在中間，也不會中途跳出雙因素驗證視窗。
第二套接 Apple Search Ads Advanced API。模式相同：ES256 簽章 JWT、OAuth client credentials grant、加上 X-AP-Context header 的 Bearer token。憑證統一透過 1Password CLI 取出，所以任何 secret 都不會以明文形式落到磁碟上。最後的成果是「建立廣告活動」、「列出關鍵字」、「拉昨天的報表」這些操作，都變成一行 shell 指令，而不是在後台點一堆按鈕。
把新中介資料推到 9 個語系的總執行時間：不到 3 分鐘。連同新版本 build 的 archive 與上傳：大約 10 分鐘。整個 2.0.1 版的組裝與送審，從頭到尾都在命令列完成。
9 種語言版本長這樣
新的副標題，全部都壓在 30 字元的限制以內：
- English: Bulk Upload to WordPress Media（批次上傳到 WordPress 媒體庫）
- Japanese: WordPressに写真を一括アップロード（批次上傳照片到 WordPress）
- Spanish: Sube fotos a WordPress en masa（批次上傳照片到 WordPress）
- German: Foto-Upload für WordPress（為 WordPress 上傳照片）
- Portuguese (Brazil): Upload em massa para WordPress（批次上傳到 WordPress）
- French: Photos en masse vers WordPress（批次照片上傳到 WordPress）
- Korean: 워드프레스 사진 일괄 업로드（WordPress 照片批次上傳）
- Italian: Foto in blocco su WordPress（批次照片上傳到 WordPress）
- Traditional Chinese: 批次上傳照片到 WordPress（批次上傳照片到 WordPress）
每個語系也各自有量身寫過的描述（英文與歐語系大約 1,400 字元，日文、韓文、中文則因為文字密度自然壓縮）、針對該市場搜尋習慣最佳化的 100 字元關鍵字字串、寫出當地貨幣價格的宣傳文字，以及一段宣告多語系上線的更新說明。
學到的事
如果你也在做 App Store 上的 App，但從來沒有親自去檢查每一個上架語系的副標題欄位，那這篇就是給你的提醒。實際確認只要 5 分鐘，而空白的副標題大概是 Apple 讓你浪費的最便宜的一塊版位。同樣的邏輯適用於關鍵字、宣傳文字，以及每一次發版時的更新說明。
另一個體會是：App Store Connect 與 Apple Search Ads 都有完整的 API，認證設定一次做好之後，操作速度遠遠超過網頁後台。如果你一年要出超過幾次版本，把 API 包進一段一百行的 bash 腳本，每次發版都能省下好幾個小時，也能避掉那種「手動點 27 個下拉選單」會慢慢累積的、可逆但難察覺的小錯誤。
接下來
Apple 審查通常 24 至 48 小時。等 2.0.1 上線後，第一階段是日本市場的小額 Apple Search Ads 廣告活動：每月預算 7,500 日圓、目標 CPI 約 250 日圓、十組以「ワードプレス アプリ」「wordpress 写真 アップロード」為起點的日文關鍵字。目標不是放量，而是拿到每個取得使用者的真實 LTV 與 ROAS 數字，讓下一次的預算決策建立在數據上，而不是樂觀預期上。
數字看起來沒問題的話，同一條自動化管線就會把廣告擴展到美國，再擴展到下兩三個 ASO 流量看起來有機會的語系。如果數字不行，預算就先暫停，回頭認真檢視截圖與定價，並用更便宜的方式繼續實驗。
一個人營運小產品的有趣之處，在於這種事可以在一個下午就出貨。比較無聊但其實才真正重要的，是接下來 60 天，當資料慢慢回流時的那一段。