跳至内容
WebViewGold 从 Vibe Coding 到 App Store
中文
获取 WebViewGold

Kiro

Kiro 规格驱动开发:为您的 Web 应用编写一份原生应用就绪 spec

Kiro 会把一条提示词变成一份 spec:带有可测试验收标准的需求、一份设计,以及一份随后由代理执行的任务清单。上架就绪很适合这种形式,因为 Apple 和 Google 公布了具体的规则,您可以把它们转化为验收标准。下面提供:一个针对 WebView 背景的 steering 文件、一份可以直接粘贴的原生应用就绪需求文件,以及如何在不失控的情况下执行这份 spec。

每个平台一次性 $109 起,或由我们的团队全程代劳,$698 起。

  • 审核通过保证 – 否则 14 天内退款
  • 无需编程
  • 一次性付费,免费更新
  • 7×24 小时人工支持
  • 2014 年起德国出品 · ISO 27001

Kiro 的 spec 和 steering 是如何工作的

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 编码代理概览比较了各种选择。

Steering 文件:.kiro/steering/native-app.md

frontmatter 必须位于文件的最开头。#[[file:...]] 会把另一个文件拉入上下文;如果您还没有审核备注,就删掉这一行。对于只在编辑原生项目时才相关的规则,请创建第二个文件,设置 inclusion: fileMatch,并为 ios/** 和 android/** 设置 fileMatchPattern。

markdown
---
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.md:原生应用就绪

用 Requirements-First 工作流创建一个 Feature spec(在 Kiro 面板中点击 Specs 下的 + 按钮,或在聊天中选择 Spec),然后用下面的内容替换生成的文件,并根据您的路由加以调整。接着运行 Analyze Requirements,在设计开始之前找出遗漏和矛盾之处。

markdown
# 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应用终于通过审核了。谢谢!!

塔哈·法鲁基(Taha Farooqui) · CodeCanyon

生成设计和任务的提示词

在审阅完 requirements.md 之后使用。它会迫使 Kiro 基于您的真实代码进行设计,并让任务保持在便于审查的大小。

在打开 spec 的情况下粘贴到 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 而不失控

spec 的质量,取决于您保留了多少审查关卡。

  1. 先写 steering

    生成基础文件(product、tech、structure),然后添加上面的 native-app steering 文件。没有它,Kiro 会按桌面浏览器来做设计。

  2. 创建 spec 并审阅需求

    使用 Requirements-First 工作流的 Feature spec,而不是 Quick Spec:Quick Spec 会一次性写完需求、设计和任务,中间没有审批关卡。用 Markdown Review 对具体段落发表评论,并运行 Analyze Requirements。

  3. 像审核人员那样审阅设计

    检查三件事:删除在服务器上进行并移除身份验证用户,应用内的任何登录路径都不会出现弹出窗口,没有机密密钥被移到客户端。其余的都只是个人偏好。

  4. 逐个运行最初的任务

    一个好的任务看起来像 - [ ] 4. Add server-side account deletion (Requirements 2.2)。在布局和身份验证任务合并之前,请逐个运行;编辑相同组件的并行波次会产生冲突,让您不得不审查两遍。

  5. 部署并在应用内测试

    部署 Web 应用,然后在 WebViewGold 测试构建版本中打开它。需求 3.2、6 和 7 只能在那里验证。

  6. 配置 WebViewGold

    在 Config.swift 和 Config.java 中设置 URL、User-Agent 标记和推送开关。如果 fileMatch steering 文件规定只能修改值,Kiro 就可以编辑这些文件;签名仍由您负责。

从 spec 需求到商店规则

需求AppleGoogle 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 会很乐意为一个您根本没有的 /settings 路由编写规格。请让它列出它没有找到的内容。
  • 在这个项目中使用 Quick Spec。这里的瓶颈不是速度;审查关卡才是重点。
  • 在全新的 spec 上点击“Run all tasks”。波次会并行运行相互独立的任务,但“独立”是根据任务清单判断的,而不是根据实际会改动哪些文件。
  • Spec 偏离实际。当您改变主意时(例如 Google 登录改用重定向而不是弹出窗口),先更新 requirements.md,再让 Kiro 更新设计和任务。
  • 把验收标准当作证据。Kiro 能检查代码,却看不到 Apple 审核人员是如何体验您的应用的。请在手机上测试构建版本。
  • 支付被悄悄“修复”。在您读完Stripe 与应用内购买决策指南之前,请让支付清单保持只报告、不修改。

提交前的检查清单

  • tasks.md 中的每个任务都已勾选或被有意删除,并且 requirements.md 仍然准确描述了已构建的内容。
  • /delete-account URL 已填写在 Play Console 中;隐私政策 URL 已填写在两个控制台中。
  • Sign in with Apple 和账户删除已在真实构建版本中测试过,而不只是在浏览器中。
  • Supabase 或 Firebase 后端通过了Supabase 检查清单或Firebase 检查清单。
  • 免费的就绪检查对您的生产 URL 全部通过。

常见问题

Kiro 的 spec 文件放在哪里?应该提交它们吗?

放在 .kiro/specs/ 中,每个 spec 一个文件夹,包含 requirements.md、design.md 和 tasks.md。请提交它们;它们记录了应用为什么会呈现出审核人员看到的那种行为,也能帮助下一个代理或开发者。

这在 Kiro CLI 中可用,还是只能在 IDE 中使用?

Spec 和任务执行在 IDE、CLI 和 Web 版中都可用。Analyze Requirements 列明适用于 IDE 和 CLI,基于属性的正确性测试则仅适用于 IDE,所以请在这两者之一中进行需求审阅。

什么是 EARS 表示法?

即 Easy Approach to Requirements Syntax(简易需求语法)。每条标准都写明一个触发条件和一个预期行为(WHEN something happens THE SYSTEM SHALL do something),这让它可以测试,也便于代理把它转化为代码和检查。

Kiro 会读取 AGENTS.md 吗?

会。Kiro 会读取工作区根目录、子目录以及全局 steering 文件夹中的 AGENTS.md。这些文件总会被包含,不支持包含模式,所以请保持简短,把有条件的规则放进 steering 文件中。

spec 也应该涵盖 WebViewGold 的 Xcode 和 Android 项目吗?

让 spec 专注于 Web 应用。原生这一侧只是少量配置值,而不是一个功能;一份简短的检查清单,再加上对 Config.swift 和 Config.java 的一次经过审查的编辑,就足够了。

让您的应用上架商店的三种方式

结果相同,只是您需要投入的工作量不同。三种方式都附带审核通过保证和 7×24 小时人工支持。

自己动手

$109 每个平台,一次性付费

WebViewGold 许可证:一个现成的 Xcode 或 Android Studio 项目。粘贴您的 URL,设置名称和图标,开启所需功能,构建并提交。永久免费更新。

在主页查看方案

Cloud Builder

$349 每个许可证,一次性附加购买

无需 Mac、Xcode 或 Android Studio:在浏览器中完成配置,我们在云端构建两个应用,并将其交付到 App Store Connect 和 Play Console。

Cloud Builder 如何运作 试用免费演示

Full Service

$698 每个平台 $798

把您的 URL 和图标发给我们。我们的团队在 72 小时内完成配置、构建并交付您的应用,白标,附源码项目。两个平台共 $1,158。

Full Service 详情 服务提供方: WeSetupYourWebViewApp

冬季特惠价格有效期至 2026年12月31日。

准备好发布您的应用了吗?

App Store & Google Play 审核通过保证 – 否则 14 天内退款

想直接交给我们?Full Service:我们在 72 小时内完成配置、构建并交付,每个平台 $698 起。有疑问?通过 7×24 小时在线聊天联系我们。

退款依据我们 FAQ 中列出的条件:应用因非内容原因被 Apple 和/或 Google 拒审,并在购买后 14 天内提出申请。