自己动手
$109 每个平台,一次性付费
WebViewGold 许可证:一个现成的 Xcode 或 Android Studio 项目。粘贴您的 URL,设置名称和图标,开启所需功能,构建并提交。永久免费更新。
在主页查看方案Kiro
Kiro 会把一条提示词变成一份 spec:带有可测试验收标准的需求、一份设计,以及一份随后由代理执行的任务清单。上架就绪很适合这种形式,因为 Apple 和 Google 公布了具体的规则,您可以把它们转化为验收标准。下面提供:一个针对 WebView 背景的 steering 文件、一份可以直接粘贴的原生应用就绪需求文件,以及如何在不失控的情况下执行这份 spec。
每个平台一次性 $109 起,或由我们的团队全程代劳,$698 起。
Kiro 是 AWS 推出的规格驱动代理式 IDE(也提供 CLI 和 Web 版),它分两层工作。Spec 位于 .kiro/specs/<spec-name>/ 中,由三个文件组成:requirements.md,包含用户故事和以 EARS 表示法书写的验收标准(“WHEN [condition] THE SYSTEM SHALL [behavior]”);design.md,包含架构、时序图、错误处理和测试策略;以及 tasks.md,一份由离散、可跟踪的实施任务组成的清单。修复 bug 时使用 Bugfix spec,用 bugfix.md 代替需求文件。您可以一次运行一个任务,也可以全部运行;全部运行时,Kiro 会构建依赖关系图,并以并行“波次”(waves)运行相互独立的任务。
Steering 文件为 Kiro 提供关于项目的长期知识。它们位于 .kiro/steering/ 中(或全局的 ~/.kiro/steering/;发生冲突时以工作区规则为准)。Kiro 可以为您生成 product.md、tech.md 和 structure.md,它也会读取 AGENTS.md。每个 steering 文件都在 frontmatter 中选择一种包含模式:always、fileMatch、manual 或 auto(steering 文档)。
对于上架就绪来说,这种划分恰到好处。Steering 承载永久不变的事实(应用运行在 WebView 中,这些规则始终适用);spec 承载让应用通过审核这个一次性项目。Spec 文件是纯 Markdown,所以如果您以后更换代理,它们也可以作为 Claude Code 或 Codex 的任务说明;AI 编码代理概览比较了各种选择。
frontmatter 必须位于文件的最开头。#[[file:...]] 会把另一个文件拉入上下文;如果您还没有审核备注,就删掉这一行。对于只在编辑原生项目时才相关的规则,请创建第二个文件,设置 inclusion: fileMatch,并为 ios/** 和 android/** 设置 fileMatchPattern。
---
inclusion: always
---
# Native app context (WebViewGold)
This web app is published as iOS and Android apps built with WebViewGold.
The apps load https://app.example.com in a WKWebView (iOS) / Android WebView,
so every deploy is live in both apps without a store update.
- Detect the app with isNativeApp(): navigator.userAgent contains "WebViewGoldApp"
(set via useragent_iphone / useragent_ipad in Config.swift, USER_AGENT in Config.java).
- Native features are URL schemes handled by the wrapper. Use only schemes listed in
https://www.webviewgold.com/llms-full.txt and always keep a browser fallback.
- No window.open popups for sign-in or payment inside the app.
- Store rules: Apple 4.2 (more than a website), 4.8 (Sign in with Apple next to other
social logins), 5.1.1 (privacy policy, in-app account deletion), 3.1.1 (digital
goods use in-app purchase on iOS). Google Play: account deletion + Data safety.
- Never edit signing, provisioning, keystores or the purchase code in ios/ or android/.
#[[file:docs/store-review-notes.md]]用 Requirements-First 工作流创建一个 Feature spec(在 Kiro 面板中点击 Specs 下的 + 按钮,或在聊天中选择 Spec),然后用下面的内容替换生成的文件,并根据您的路由加以调整。接着运行 Analyze Requirements,在设计开始之前找出遗漏和矛盾之处。
# Requirements: Native app readiness
## Introduction
Prepare the web app for publication as iOS and Android apps built with WebViewGold,
so that it can pass App Store and Google Play review on the first submission.
## Requirement 1: Mobile layout
**User story:** As a phone user, I want every screen to fit and respond to touch.
1. WHEN any route renders at a viewport width of 320 px THE SYSTEM SHALL show no horizontal scrolling.
2. WHEN a fixed header or tab bar renders THE SYSTEM SHALL pad it with env(safe-area-inset-top) or env(safe-area-inset-bottom).
3. WHEN an interactive element renders THE SYSTEM SHALL give it a touch target of at least 44 x 44 px.
## Requirement 2: Account deletion
**User story:** As a user, I want to delete my account inside the app.
1. WHEN a signed-in user opens Settings THE SYSTEM SHALL show a Delete account action.
2. WHEN the user confirms deletion THE SYSTEM SHALL delete their data and auth record server-side, sign them out and show a confirmation.
3. WHEN anyone opens /delete-account THE SYSTEM SHALL explain how to delete an account in the app and by email.
## Requirement 3: Sign-in
**User story:** As a user, I want to sign in the way I prefer without leaving the app.
1. WHEN the sign-in screen offers Google or another third-party login THE SYSTEM SHALL offer Sign in with Apple as an equivalent option.
2. WHEN sign-in runs inside the native app THE SYSTEM SHALL complete without opening a popup window.
## Requirement 4: Legal pages
**User story:** As a reviewer, I want to find the privacy policy and terms quickly.
1. WHEN /privacy or /terms is requested directly THE SYSTEM SHALL return the page with HTTP 200.
2. WHEN the user opens Settings THE SYSTEM SHALL link to both pages.
## Requirement 5: Resilience
**User story:** As a user on a weak connection, I never want to see a blank screen.
1. WHEN a data request fails THE SYSTEM SHALL show an error message with a retry action.
2. WHEN a list has no items THE SYSTEM SHALL show an empty state.
## Requirement 6: App-only presentation
**User story:** As an app user, I do not want to be told to download the app I am using.
1. WHEN the user agent contains WebViewGoldApp THE SYSTEM SHALL hide download-our-app banners, builder badges and links to store listings.
2. WHEN the user agent does not contain WebViewGoldApp THE SYSTEM SHALL keep the website unchanged.
## Requirement 7: Native value
**User story:** As a returning user, I want to be notified about things that matter to me.
1. WHEN a signed-in user finishes onboarding in the iOS app THE SYSTEM SHALL offer an Enable notifications button that calls registerpush://.
2. WHEN the app exposes a push subscription ID (onesignalplayerid) THE SYSTEM SHALL store it on the user profile.
## Requirement 8: Secrets
**User story:** As the owner, I want no secret key to reach a device.
1. WHEN the production bundle is built THE SYSTEM SHALL contain only publishable keys.
我的iOS WebView应用终于通过审核了。谢谢!!
在审阅完 requirements.md 之后使用。它会迫使 Kiro 基于您的真实代码进行设计,并让任务保持在便于审查的大小。
阅读 .kiro/steering/ 和 AGENTS.md,然后阅读 native-app-readiness spec 的需求。在写任何东西之前先检查代码库:每一项设计决策都要基于这个项目实际使用的路由、身份验证提供商、数据库和托管平台,并列出需求中假定存在、但您没有找到的任何内容。 设计:描述 isNativeApp() 工具函数及其使用位置、账户删除逻辑在服务器上的哪里运行以及它如何验证调用者的身份、推送订阅 ID 如何到达用户资料、共享的加载/空/错误状态组件,以及 Sign in with Apple 如何融入现有的身份验证设置。为账户删除添加一张时序图。设计中的任何内容都不得把机密密钥移到客户端代码中。 任务:每个可审查的改动对应一个任务,每个任务都引用其需求编号,并以 375 px 宽度下的手动测试步骤结尾。第一个任务设为只报告的支付清单(哪些地方销售数字商品或订阅),不做任何代码改动。不要创建涉及 ios/ 或 android/ 中签名、描述文件、keystore 或 Bundle ID 的任务。 写完 design.md 后停下,等我审阅之后再编写 tasks.md。
spec 的质量,取决于您保留了多少审查关卡。
生成基础文件(product、tech、structure),然后添加上面的 native-app steering 文件。没有它,Kiro 会按桌面浏览器来做设计。
使用 Requirements-First 工作流的 Feature spec,而不是 Quick Spec:Quick Spec 会一次性写完需求、设计和任务,中间没有审批关卡。用 Markdown Review 对具体段落发表评论,并运行 Analyze Requirements。
检查三件事:删除在服务器上进行并移除身份验证用户,应用内的任何登录路径都不会出现弹出窗口,没有机密密钥被移到客户端。其余的都只是个人偏好。
一个好的任务看起来像 - [ ] 4. Add server-side account deletion (Requirements 2.2)。在布局和身份验证任务合并之前,请逐个运行;编辑相同组件的并行波次会产生冲突,让您不得不审查两遍。
部署 Web 应用,然后在 WebViewGold 测试构建版本中打开它。需求 3.2、6 和 7 只能在那里验证。
在 Config.swift 和 Config.java 中设置 URL、User-Agent 标记和推送开关。如果 fileMatch steering 文件规定只能修改值,Kiro 就可以编辑这些文件;签名仍由您负责。
| 需求 | Apple | Google Play |
|---|---|---|
| 1. 移动端布局 | 4.0 设计 | 功能故障 |
| 2. 账户删除 | 5.1.1(v) | 账户删除要求 |
| 3. 登录 | 4.8 登录服务 | Android 上不要求 |
| 4. 法律页面 | 5.1.1 隐私 | 用户数据政策、隐私政策链接 |
| 5. 稳健性 | 2.1 应用完整性 | 功能故障 |
| 6 和 7. 仅限应用的 UI 和原生价值 | 4.2 最低功能要求 | 最低功能要求 / WebView 垃圾应用 |
放在 .kiro/specs/ 中,每个 spec 一个文件夹,包含 requirements.md、design.md 和 tasks.md。请提交它们;它们记录了应用为什么会呈现出审核人员看到的那种行为,也能帮助下一个代理或开发者。
Spec 和任务执行在 IDE、CLI 和 Web 版中都可用。Analyze Requirements 列明适用于 IDE 和 CLI,基于属性的正确性测试则仅适用于 IDE,所以请在这两者之一中进行需求审阅。
即 Easy Approach to Requirements Syntax(简易需求语法)。每条标准都写明一个触发条件和一个预期行为(WHEN something happens THE SYSTEM SHALL do something),这让它可以测试,也便于代理把它转化为代码和检查。
会。Kiro 会读取工作区根目录、子目录以及全局 steering 文件夹中的 AGENTS.md。这些文件总会被包含,不支持包含模式,所以请保持简短,把有条件的规则放进 steering 文件中。
让 spec 专注于 Web 应用。原生这一侧只是少量配置值,而不是一个功能;一份简短的检查清单,再加上对 Config.swift 和 Config.java 的一次经过审查的编辑,就足够了。
结果相同,只是您需要投入的工作量不同。三种方式都附带审核通过保证和 7×24 小时人工支持。
$109 每个平台,一次性付费
WebViewGold 许可证:一个现成的 Xcode 或 Android Studio 项目。粘贴您的 URL,设置名称和图标,开启所需功能,构建并提交。永久免费更新。
在主页查看方案$349 每个许可证,一次性附加购买
无需 Mac、Xcode 或 Android Studio:在浏览器中完成配置,我们在云端构建两个应用,并将其交付到 App Store Connect 和 Play Console。
Cloud Builder 如何运作 试用免费演示$698 每个平台 $798
把您的 URL 和图标发给我们。我们的团队在 72 小时内完成配置、构建并交付您的应用,白标,附源码项目。两个平台共 $1,158。
Full Service 详情 服务提供方:冬季特惠价格有效期至 2026年12月31日。
App Store & Google Play 审核通过保证 – 否则 14 天内退款
想直接交给我们?Full Service:我们在 72 小时内完成配置、构建并交付,每个平台 $698 起。有疑问?通过 7×24 小时在线聊天联系我们。
退款依据我们 FAQ 中列出的条件:应用因非内容原因被 Apple 和/或 Google 拒审,并在购买后 14 天内提出申请。