跳到正文
DEV Community· dmski1·· 3 小時前AI 評分62

AI 工具製作 Android 應用讓作者學到甚麼:Google Play 審核與建置前檢查

What shipping AI-built Android apps taught me about Google Play review (and the check I now run first)

AI 導讀

獨立開發者 dmski1 分享以 AI 工具製作 Android 應用的 Google Play 審核經驗,並提出動工前檢查政策風險、競爭者和產品差異的清單。較新的個人開發者帳戶申請正式上架前,須先完成有至少 12 名測試者連續 14 日保持選擇加入狀態的封閉測試;Google 亦會看測試者是否實際使用應用程式。

正文

Cover image for What shipping AI-built Android apps taught me about Google Play review (and the check I now run first)

dmski1

I build small apps on my own, mostly with AI app builders like Rork and Replit. The code now shows up fast. The hard parts have moved to either end: picking the idea, and getting it through the store.

Here's what I've learned taking apps through Google Play, and the habit I changed because of it.

  1. New personal accounts must run a 14-day closed test first On newer personal developer accounts, Google won't let you apply for production until you've run a closed test with at least 12 opted-in testers for 14 days in a row. Two things caught me out:

Testers have to stay opted in. If one drops off, you're under the bar. Recruit a few extra.
Hitting the numbers isn't enough. Google looks at whether testers actually used the app, not just whether they opted in. If engagement is thin, you can be asked to run another 14 days. "Apply for production" asks how you recruited testers, how you collected feedback, and what you changed. Recruit people who will actually open the app, give them something specific to try, and keep notes as you go so you can answer honestly.

  1. Data safety and privacy have to match what the app really does
    AI apps send user text or photos to a model provider. Your Data safety form, your privacy policy, and your actual network calls need to tell the same story. I now write the privacy policy before I build, because it forces me to decide what data the idea really needs.

  2. Secrets don't belong in the app bundle
    With AI builders it's easy to end up with an API key in a public env variable that gets compiled into the app. Treat anything in the client as public, keep provider keys on a server, and scan your build for keys before you upload.

  3. A lot of review risk is decided before you write code
    Some ideas carry extra review work no matter how well they're built: apps that lean on user-generated content without a moderation plan, apps that copy a category leader too closely, or a subscription in a category full of free apps. Those are cheap to spot on day one and expensive to discover after you've built.

The check I run now, before building
For every idea, I write three sentences: what it does, who it's for, and how it makes money. Then I ask:

Policy: Does it touch user content, health claims, kids, finance, impersonation, or faces? Each of those adds review work.
Competition: Who are the top 3 to 5 apps in the category, and what do they charge?
Difference: In one line, why would someone switch?
I got tired of doing that by hand, so I built a small app for it, AppScore. You describe the idea and it gives you rough approval odds for Google Play and the App Store with the likely rejection flags, a ballpark revenue range, the main competitors, and what to change. It's an estimate, not a ruling from Google or Apple, but it gets me to "don't build this version" a lot faster. It's Android-only. Free with 3 idea checks a month, optional Pro subscription: https://play.google.com/store/apps/details?id=app.rork.app_idea_score_potential

Whether or not you use it, steal the checklist above. The cheapest rejection is the one you catch before you build.

What's caught you out on Play review? I'm collecting real cases.

來源:DEV Community · dev.to