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

ChatGPT & Codex

用 Codex 为 WebViewGold 应用做移动端 UI 审查:安全区域、点按区域和审核人员会注意到的细节

因准则 4.0 被拒和一星差评,往往源于同样的几个像素:页眉被刘海遮住、标签栏藏在主屏幕指示条后面、关闭按钮太小、点按输入框时页面被放大。Codex 能在您的代码里找出其中的大部分,并在无头浏览器中验证修复结果,而几项 WebViewGold 设置决定了安全区域由谁负责。下面把这次审查整理成一个可重复的工作流程。

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

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

审核人员会怎么看您的页面

App 审核会把构建版本安装到当前的硬件上,通常是一台带灵动岛的 iPhone,外加一台 iPad,因为除非您加以限制,WebViewGold 应用也会在 iPad 上运行(封装 Web 应用的 iPad 支持)。审核人员用拇指而不是鼠标点按主要流程。任何被状态栏遮住的内容、要点三次才有反应的按钮、放大后就缩不回去的表单,或者能左右滚动的页面,都会让人觉得“这就是个网站”,拒审通常会引用准则 4.0(设计)或 2.1(准则 4.0 拒审详解)。Google 则会把同样的问题归为功能故障。

这次审查的目标是刻意追求“平淡无奇”:没有任何内容与系统界面重叠,每个控件都能轻松点中,在 320 像素宽度下没有页面会横向滚动,输入框不会触发聚焦放大,状态栏在浅色和深色模式下都与页眉相匹配。

先决定安全区域由谁负责

方案WebViewGold 设置您的 CSS适用场景
由 WebViewGold 把内容保持在安全区域内(默认)iOS:autoAdjustSafeAreaInsets 保持 true;用 statusBarBackgroundColor 为状态栏着色,主屏幕指示条区域则用 bottombar 配合 bottombarBackgroundColor(也有深色模式的变体)。Android:TRANSPARENT_STATUS_BAR 设为 false,状态栏颜色取自 style.xml 中的 colorPrimaryDark不加 inset 内边距;确保没有组件自己添加刘海占位大多数应用,工作量最小
由您的 Web 应用实现全面屏绘制iOS:transparentStatusBar 设为 true,autoAdjustSafeAreaInsets 设为 false。Android:TRANSPARENT_STATUS_BAR 设为 true,blackStatusBarText 与您的页眉相匹配viewport-fit=cover,并在固定页眉、标签栏和底部面板上使用 env(safe-area-inset-top) 和 env(safe-area-inset-bottom);Android 要在真机上测试通栏页眉、地图、媒体
原生标签栏iOS:showNavFooter 配合 FooterBar.json。Android:ENABLE_NAVIGATION_FOOTER 配合 res/menu/menu_drawer.xml当 isNativeApp() 为 true 时隐藏您自己的网页标签栏,否则用户会看到两个有三到五个顶级板块的应用

第一轮:无头、只读的审查

codex exec 在没有交互界面的情况下运行 Codex;--sandbox read-only 表示它可以读取所有文件但不能修改任何文件,-o 会把它的最终回答保存到文件中。请在仓库根目录运行。第二条命令是可选的,它让 Codex 看到设备上显示的内容:-i 会把截图附加到提示词中。

bash
# Pass 1: Codex reads, changes nothing, and the CLI saves the report.
codex exec --sandbox read-only -o ui-audit.md "Read AGENTS.md. This web app runs inside
native iOS and Android WebViews (WebViewGold). Audit every route and shared layout
component and REPORT ONLY, do not edit. For each finding: file:line, severity
(blocker, major, minor), what breaks on a phone, and the smallest fix. Check:
- viewport meta: width=device-width, initial-scale=1, viewport-fit=cover
- fixed or sticky elements at the top or bottom edge and how they handle safe areas
- interactive elements smaller than 44x44 CSS px, or closer than 8px to each other
- input, select and textarea font size under 16px (iOS focus zoom)
- hover-only menus, tooltips and actions
- 100vh layouts, horizontal overflow below 360px width, fixed pixel widths
- modals and sheets without a visible close button
End with a summary table by severity."

# Optional: attach device screenshots from TestFlight or internal testing
codex --sandbox workspace-write -i iphone-home.png,ipad-settings.png "These screenshots
are from the TestFlight build. Add everything visible here that ui-audit.md misses."

把 Web 应用转换成原生应用的绝佳方式!周转速度快,无需开发完整的原生应用就能把应用上架到应用商店!

Kevin Joling · FlightConnections & TrainConnections · Trustpilot

第二轮:用 Playwright 检查让修复长期有效

阅读代码能发现大部分问题;浏览器则能证明修复有效。下面的修复提示词会让 Codex 添加这个测试,它值得一直保留在 CI 中。它被刻意设计得很严格:可能会有少量误报,比如行内文字链接或复选框;请让 Codex 把它们加入经过审阅的白名单,而不是放宽阈值。

javascript
// tests/mobile-ui.spec.js (run: npx playwright test tests/mobile-ui.spec.js)
import { test, expect } from "@playwright/test";

const ROUTES = ["/", "/login", "/settings", "/projects/demo"];
const WIDTHS = [320, 375, 430, 768]; // small phone, phone, large phone, iPad portrait
const ALLOW = ["a.inline-link", "input[type=checkbox]"]; // reviewed exceptions

for (const width of WIDTHS) {
  for (const route of ROUTES) {
    test(route + " at " + width + "px", async ({ page }) => {
      await page.setViewportSize({ width, height: 860 });
      await page.goto(route);

      // 1. No sideways scrolling
      const overflow = await page.evaluate(
        () => document.documentElement.scrollWidth - window.innerWidth);
      expect(overflow, "horizontal overflow in px").toBeLessThanOrEqual(0);

      // 2. Tap targets of at least 44 x 44 CSS px
      const small = await page.$$eval("a, button, [role=button], [role=tab], select",
        (els, allow) => els
          .filter((el) => !allow.some((sel) => el.matches(sel)))
          .filter((el) => { const r = el.getBoundingClientRect();
            return r.width > 0 && (r.width < 44 || r.height < 44); })
          .map((el) => (el.getAttribute("aria-label") || el.textContent || el.tagName)
            .trim().slice(0, 40)),
        ALLOW);
      expect(small, "tap targets under 44px").toEqual([]);

      // 3. No iOS focus zoom: form fields at 16px or more
      const tiny = await page.$$eval("input, select, textarea",
        (els) => els.filter((el) => parseFloat(getComputedStyle(el).fontSize) < 16).length);
      expect(tiny, "form fields under 16px").toBe(0);
    });
  }
}

修复提示词

用 codex --sandbox workspace-write --ask-for-approval on-request 启动一个交互式会话。安装 Playwright 及其浏览器需要网络访问,所以 Codex 会在那一步请求审批;批准它,或者事先自己安装好 Playwright。根据表格保留方案 A 或 B,删除另一个。

审查完成后粘贴到 Codex
请阅读 AGENTS.md 和 ui-audit.md。用能解决问题的最小改动修复所有 blocker 和 major 级别的问题。除非某个问题确实需要,否则不要重新设计、不要重命名组件、也不要修改颜色。

安全区域(保留一个方案,删除另一个):
A)由 WebViewGold 把内容保持在安全区域内(Config.swift 中 autoAdjustSafeAreaInsets 保持 true)。不要添加安全区域内边距;而是移除所有刘海占位组件。
B)我们实现全面屏绘制(Config.swift 中 transparentStatusBar = true 且 autoAdjustSafeAreaInsets = false,Config.java 中 TRANSPARENT_STATUS_BAR = true)。添加 viewport-fit=cover,并为固定页眉、标签栏和底部面板设置内边距 max(原有内边距, env(safe-area-inset-top)) 或 env(safe-area-inset-bottom)。

规则:
- 可交互元素至少 44x44 CSS px。用内边距或 ::before 伪元素扩大点击区域;不要放大图标。相邻元素之间保持 8px 间距。
- input、select 和 textarea 的字号至少 16px。绝不添加 maximum-scale 或 user-scalable=no。
- 把 100vh 替换为 100dvh,并在它前面保留一行 100vh 作为回退。
- 仅靠悬停触发的交互要有对应的点按方式。
- 如果应用有浅色和深色主题:当主题切换且 isNativeApp() 为 true 时,用页眉颜色跳转到 statusbarcolor://R,G,B,让原生状态栏跟着变化。
- 如果我们启用了 WebViewGold 的原生标签栏(iOS 上的 showNavFooter、Android 上的 ENABLE_NAVIGATION_FOOTER),当 isNativeApp() 为 true 时隐藏我们的网页标签栏。

然后添加 Playwright(安装前先询问),一个 baseURL 指向 npm run dev 的 playwright.config,以及 tests/mobile-ui.spec.js:在 320、375、430 和 768 px 宽度下,对[列出您的主要路由]检查横向溢出、点按区域和表单字号。反复运行直到通过。最后更新 ui-audit.md,分成三个列表:已修复、有意不修复(及原因)、需要真机检查。

审查工作流程

  1. 选定安全区域的负责方

    从表格中选择一行,并在 WebViewGold 项目中进行设置(iOS 安全区域文档也介绍了底部栏)。请最先决定这一点,因为每一处 CSS 修复都取决于它。

  2. 运行只读审查

    第一轮会生成 ui-audit.md,为每个问题列出文件、行号、严重程度和建议的修复方法。仓库中不会有任何改动。

  3. 亲自分诊

    删除您不认同的问题,并标出有意为之的设计决定。在这里花十分钟,可以防止 Codex “修复”掉您的品牌风格。

  4. 运行修复会话

    粘贴修复提示词,然后执行 /review 并查看 git diff。部署前 Playwright 测试必须全部通过。

  5. 在真机上查看

    在带刘海的 iPhone 和 iPad 上用 TestFlight 测试,在一台使用手势导航、系统字体调大的小屏 Android 手机上做内部测试。截下任何看起来不对劲的地方,用 codex -i 交回给 Codex。免费的App Store 上架就绪检查可以发现 URL 层面的基础问题。

  6. 保留防护措施

    把 Playwright 测试留在 CI 中,并在 AGENTS.md 中添加一条针对新增小点按区域的审查规则,这样 Codex 代码审查就会在以后的 pull request 中标记回归问题。

真机检查清单

  • 状态栏文字在浅色和深色模式下都清晰可读;当页眉颜色随主题变化时,应用会调用 statusbarcolor://R,G,B(或 statusbartextcolor://white / black),让状态栏跟着变化(Dynamic UI API)。
  • 没有内容位于灵动岛或刘海下方,没有内容被主屏幕指示条遮挡,底部面板避开了手势区域。
  • 每个控件用拇指点一次就能生效:图标按钮、关闭按钮、标签、列表行。
  • 点按输入框不会放大页面,获得焦点的输入框始终显示在键盘上方(在 Android 上,INPUT_SCROLL_HELPER 可以帮忙)。
  • Android 上调大系统字体不会破坏布局;如果某个布局无法伸缩,可以用 MAX_TEXT_ZOOM 限制文字缩放。
  • iPad 横竖两个方向:没有被拉伸的手机布局和无限长的文本行。
  • 回弹和下拉刷新符合预期:iOS 上的 preventoverscroll 会去掉橡皮筋效果,pulltorefresh 需要它关闭,Android 使用 ENABLE_PULL_REFRESH。
  • Android 返回手势会返回上一页,只在您预期的地方退出应用(EXIT_APP_BY_BACK_BUTTON_HOMEPAGE、EXIT_APP_DIALOG)。

会带来新问题的修复

  • 双重内边距:CSS 中设置了 inset 内边距,而 WebViewGold 同时也把 WebView 保持在安全区域内。只能有一个负责方。
  • 用 maximum-scale=1 或 user-scalable=no 禁止聚焦放大。这也会让需要双指缩放的人无法缩放;请改为修正字号。WebViewGold 在 iOS 上提供了 preventZoom,但使用前请三思。
  • 使用 100vh 的全屏布局,结果比可见区域还高。请使用 100dvh,并以 100vh 作为回退。
  • 把图标放大到 44 像素。请用内边距扩大点击区域,设计保持不变。
  • 用更长的悬停延迟来“修复”悬停菜单。触摸没有悬停;它们需要一个点按操作。
  • 让审查演变成一次重新设计。提示词要求最小改动;审阅时要让 Codex 遵守这一点。

常见问题

Apple 要求点按区域达到 44×44 点吗?

Apple 的人机界面指南建议至少 44×44 点,Material Design 建议 48×48 dp,WCAG 2.2 则把 24×24 CSS 像素定为最低标准。审核人员不会去量,但他们会注意到需要点好几次的控件。iOS 上以 44 为目标,Android 上以 48 为目标。

Codex 能看到我的应用吗?

它会读取您的代码,也能查看您附加的图片:用 -i 加上一张来自 TestFlight 或 Android 设备的截图启动 Codex,让它把截图和代码进行对比。这种组合能发现两者单独都发现不了的问题。

我到底需不需要 env(safe-area-inset-*)?

只有当您的 Web 应用实现全面屏绘制,使用透明状态栏并关闭了 WebViewGold 的安全区域调整时才需要。在默认处理方式下,页面本来就位于安全区域内;只需在带刘海的设备上检查没有组件额外添加了第二个占位即可。

为什么点按输入框时我的应用会放大?

当表单字段的字号小于 16 CSS 像素时,iOS 会放大到该字段。把 input、select 和 textarea 设为 16px 或更大,放大就会消失,而且无需禁用双指缩放。

每个 pull request 都应该运行这次审查吗?

Playwright 测试应该每次都跑,它成本很低。只读的 Codex 审查值得在每次提交商店之前或较大的改版之后重复进行,而 AGENTS.md 中的审查规则能让 Codex 代码审查在两次审查之间标记出新问题。

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

结果相同,只是您需要投入的工作量不同。三种方式都附带审核通过保证和 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 天内提出申请。