這幾天我主要在忙著幫兩款應用程式進行細節修復與上架準備。我重新整理了資料庫的防錯機制，解決了圖片複製失敗的隱藏問題，並完成了新版本的外觀微調與送審。
看不到的門檻：為什麼網路圖片複製會失敗？
在開發 iOS App，也就是蘋果手機的應用程式時，使用者遇到了一個奇怪的狀況：複製社群河道上的圖片時，畫面只會跳出網路失敗，但網路其實很正常。
這就像你想跟朋友借一本放在遠端圖書館的書，你命令系統幫你複製，系統卻規定必須先下載到手裡。因為系統一看到遠端網址就直接拒絕，而程式卻把拒絕訊息藏起來，隨便編了一個網路不好的理由。
為了解決這個問題，我修改了處理邏輯，讓程式發現圖片來自網路時，先下載到本地路徑，意指手機內部的檔案位置，確認拿到檔案才複製。下次遇到檔案下載或複製時，請務必先確認來源是網路網址還是本機路徑，不要用同一句錯誤訊息帶過，否則會找不到問題。
技術細節：修復遠端圖片複製因路徑驗證失敗而中斷的問題
函數
copyImageToClipboard在第一步無條件執行new File(uri)，這會觸發validatePath()的url.isFileURL檢查。傳入https網址會導致建構子同步拋出錯誤，直接進入外層catch區塊，導致程式無法執行後續下載遠端圖片的分支。修復方式為在建立檔案前先判斷協定，若為遠端圖片則先透過檔案系統下載至本機暫存再進行複製。
虛假的安心：明明沒刪成功，系統卻笑著說已刪除
在台灣美甲情報平台這個幫助大家尋找美甲師的 App 中，我發現了一個嚴重漏洞。當美甲師刪除敏感資料時，即使因為權限控制，這種限制誰能修改資料的安全規則而失敗，畫面竟仍顯示「已刪除」。
這就像你去超商辦退貨，店員笑著說好，但他的權限根本無法刷退。結果發票沒退、退款沒入帳，你卻以為已經順利完成了。
這是因為當資料庫，即儲存所有系統資料的雲端倉庫擋下不合法刪除時，回傳了空訊號。我修改了邏輯，強制程式每次修改資料後都核對改變的資料列數，只要是零就判定失敗並彈出警告。下次遇到修改或刪除資料時，不能只依賴系統有沒有報錯，必須實際檢查資料到底有沒有被改變。
graph TD A[使用者按下刪除] --> B{資料庫過濾權限} B -- 權限不足 --> C[資料庫回傳空無一物] C --> D[程式以為沒有錯誤] D --> E[畫面顯示已刪除] E --> F[實際上資料還在]
技術細節：PostgREST 在 RLS 過濾至 0 列時的 DELETE 行為處理
當資料庫的行安全策略（RLS）拒絕 DELETE 請求時，PostgREST 預設會回傳
204 No Content。這導致postgrest-js解析出的data與error皆為null，只解構{ error }的呼叫端會誤判為成功（如nailist-form.tsx刪除美甲師）。解決方案是在lib/api/_queryHelpers.ts新增requireAffected判定，並在所有 mutation 的呼叫鏈加上.select('id')，確保能藉由回傳列數是否為零來精確捕捉失敗。
連鎖反應：為了改一個網址，被迫升級整個版本
當我準備將最新版的應用程式送去審查時，在應用程式商店後台，也就是管理應用程式上架資訊的管理介面中，發現了一個不允許修改的欄位。我原本只是想修正一個錯誤的官方網址，但官方規定只要版本發布就不准更動。
這就像你寄出一封信，信封上漏寫了電話。郵局規定信件寄出就不能塗改，唯一的辦法就是重寫一封、貼上新郵票再寄一次。
為了修改網址，我不得不把版本號，用來識別軟體新舊的數字標記往上調一碼。這意味著我必須重新打包，走一遍完整的上架與審核流程。下次送審前請務必建立檢查清單，仔細核對商店頁面的所有資訊，避免因小失大。
技術細節：App Store Connect 鎖定 marketingUrl 之版本號升級應對
由於 App Store Connect 不允許已發佈版本（1.0.0）修改
marketingUrl欄位，且建置版本（Build）選單會依CFBundleShortVersionString進行過濾，使得舊建置號無法直接掛載至新版。我將app.json的版本號自1.0.0升級為1.0.1，利用 Expo EAS 重新建置並產出 Build (13)。同時驗證了建置指紋的變更，確保與本地開發環境的 runtime 狀態一致，最終通過 IPA 格式驗收。
接下來
- 追蹤應用程式商店對新版本的審查進度，確保順利上架。
- 持續將美甲情報平台中剩餘的設計規範與色調標準，逐步落實到實際畫面中。
本篇由跨專案自動彙整產生，素材為 2026-08-28 之後 2 個專案的提交紀錄與 0 則知識投遞。