How Cloud Policies and Store Verification Stalled My Mobile App Launch

When I finally got the codebase for Kotohira Digital Residents to a green state—Expo, React Native, TypeScript, and even a full test suite crawling every screen—I felt a wave of relief. The app was supposed to let residents of a tiny Japanese town pay ¥5,000 a year for a digital resident card, and the logic was solid: you only get the card after helping three locals.

But then the clock started ticking for reasons that had nothing to do with bugs. Every step forward hit a wall that asked, “Who are you, and can you prove it?” Those walls weren’t mentioned in any SDK readme, because they live outside the SDK entirely.

The first snag was a missing Google Play service‑account key. RevenueCat, the subscription manager I was using, insists on a JSON key file to read subscription status. The docs are clear: download the credentials JSON and drop it in the project. I followed the steps, clicked “Create key,” and Google replied with a terse “Service account key creation is disabled.”

Turns out my organization had the iam.disableServiceAccountKeyCreation constraint turned on by default—a “secure by default” setting that blocks long‑lived private keys. The advice on forums was to switch to Workload Identity Federation, but RevenueCat only accepts the JSON file, so that didn’t help.

What eventually worked was a little policy override. I granted myself the Organization Policy Administrator role (the Japanese console calls it 組織ポリシー管理者), then went to the specific project, overrode the parent constraint, and turned enforcement off just for that project. After creating the key, I re‑enabled inheritance so the rest of my projects stayed locked down. The tricky part? I spent almost an hour hunting the role by its English ID orgpolicy.policyAdmin because the Japanese translation didn’t match what the search suggested.

Next up was Samsung’s Galaxy Store. Shipathon counts a Galaxy Store release the same as Play Store or App Store, so I thought it would be a cheap backup. Samsung asks for a “Commercial Seller” account and, crucially, a payout destination. I entered our corporate bank’s details and was asked for a SWIFT code. A quick search on the bank’s support site gave a blunt answer: “We do not have a SWIFT code.” The bank is a modern Japanese online institution that can send money abroad via a partner, but it can’t receive inbound international transfers.

This wasn’t a technical glitch—it was a category error on my part. I assumed a business account could do both inbound and outbound international payments, when in reality those are separate services. Without a SWIFT/BIC, Samsung refused to let me register the app.

In hindsight, the whole episode felt like a lesson in reading the fine print of cloud and store ecosystems. The policies that keep your organization safe can also lock you out if you’re not aware of them, and the banking details you take for granted may not be universal.

If you ever find yourself staring at a silent “nothing happened” button in the Google Cloud Console while automating clicks, take a step back. Hand the URL to a human, or simply move on. I wasted more time trying to convince a script to click than the click was worth.

Bottom line: the app was ready weeks ago. It only launched after I untangled a cloud policy, overrode a project‑level constraint, and discovered that my bank couldn’t receive a SWIFT transfer. All of that, while the code was already perfect, adds a human layer of delay that no CI pipeline can predict.