Impeccable 的 iOS 平台设计语言:原生 App 的导航、组件、字体与模拟器验证规范【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable本篇围绕 Impeccable 技能体系中的 iOS 平台参考文档 ios.md 展开。它规定了面向 SwiftUI / UIKit / React Native / Expo / Flutter 等原生与跨端 iOS 工程的设计底线:安全区布局、系统导航、Dynamic Type、语义颜色与 SF Symbols 等组件准则,以及一套用xcrun simctl完成截图取证与外观/字号切换的验证流程。读完后,你能判断一个 iOS 界面是否像原生应用,并能用文档中的命令行在 Simulator 上产出自检证据。这份文档在 Impeccable 中的位置ios.md 是 Impeccable 技能(定义于 SKILL.md)针对原生 iOS / iPadOS 应用的平台宪法,适用对象是shipping to Apple hardware的工程:SwiftUI、UIKit,以及 React Native、Expo、Flutter 等跨端框架落到苹果设备的产物。文档开篇即给出它在 Impeccable 模式体系中的定位:On native, the visitor mode narrows what expression may override. HIG conformance governs structure, navigation, and interaction in every mode; brand expresses through the layer the platform leaves open (tint, type, motion, content).也就是说,在原生平台上,Impeccable 的四种 visitor mode(Persuade / Operate / Read / Experience,见 SKILL.md 的 Modes 一节)只能收窄品牌表达的权限,而不能推翻平台规范:结构、导航、交互由 HIG(iOS 人机界面指南)约束,品牌只能表达在平台留白的层次上——tint 色、字体、动效与内容。平台参考文档的加载时机由技能流程保证。从源码结构看,加载链如下:init.md 的init流程会把平台判定为web、ios、android或adaptive并写入PRODUCT.md;其中明确写道:记录为ios之后,load ios.md ... before any design work,并且对于没有 PRODUCT.md 的存量项目,init is the only place that learns the answer——只有 init 能学到平台答案,此前的 context 脚本无从知晓。layout.md、typeset.md、animate.md、adapt.native.md 等具体设计命令在遇到原生目标时,都会把导航、insets、适配、触控目标、字体的决策权交给 ios.md 或 android.md。audit.native.md 则把 ios.md 当作评分标尺:Score against the platform reference(s): ios.md / android.md,并在打分前要求先读入该参考文档。The iOS slop test:一条判据,而非十条细则文档把最核心的验收标准压缩成一个问题:Would a fluent iPhone user trust this app, or pause at off-spec controls?一个熟练的 iPhone 用户是信任这个 App,还是会因为不合规范的控件而迟疑?文档随即给出最常见的败因——ported from a website(从网站移植来的痕迹):自造导航栏、自定义返回手势、网页形态的按钮、依赖 hover 的交互提示。结论性指令是:Default to the platforms components; depart only for a reason the user would thank you for.默认使用平台组件;只有当偏离能给用户带来实际回报时才偏离。这一 slop test 在 audit.native.md 中被提升为评分第 4 维度Platform Conformance(CRITICAL)的核心判据,报告必须首先给出 Pass/fail: does this read as a native app or a ported website? 的裁决。Layout structure:安全区、系统导航与返回手势原文档的 Layout structure 一节包含四条硬约束,完整继承如下:约束文档原文要求要点解读Safe areaLay out inside the safe-area insets. No controls under the notch, Dynamic Island, home indicator, or rounded corners.布局必须收在安全区内;刘海、灵动岛、Home 指示条与圆角之下不允许放任何控件System navigationTab bar for 2–5 top-level sections (sections, never actions), navigation stack for hierarchy, sheet for self-contained tasks. No custom global nav, no mixed metaphors.Tab bar 承载 2–5 个顶层分区(是 sections,不是 actions);层级用导航栈;自包含任务用 sheet;禁止自造全局导航、禁止混用隐喻Edge-swipe backThe left-edge back gesture is muscle memory; never disable or overlay it.左缘返回手势是肌肉记忆,永不禁用、永不遮挡Large titleson top-level screens, collapsing to inline on scroll. Deep detail screens stay inline.顶层页面用大标题,滚动时收为内联;深层详情页保持内联这四条与 audit.native.md 第 4 维度的检查项一一对应:该维度会把 edge-swipe back disabled、content under the notch / Dynamic Island / home indicator、custom global nav, overloaded tab bars 列为明确的扣分证据;第 5 维度 Adaptivity 则补充了 iPad Split View 等多任务场景下的布局校验。Touch targets:44×44 pt 是绝对下限原文档对触控目标只有一条,但表述是排他性的:44×44 pt minimumfor every tappable control, with breathing room between adjacent targets.每个可点控件最小 44×44 pt,且相邻目标之间要留呼吸空间。这条规则在 audit.native.md 中同时出现在两个维度:Accessibility 维度检查 below 44 pt ... or crammed without spacing,平台符合度报告示例中的系统性问题也以此为典型(Touch targets consistently below 44 pt throughout the tab bar and list rows)。作为对照,android.md 的下限是 48×48 dp 且间距至少 8 dp——两个平台的数值差异本身提示:这类下限不是经验值,而是各自平台规范(HIG / Material)的条文,移植时必须换算而非照抄。Typography:Dynamic Type 与 SF 的分工Typography 一节包含三条规则:Dynamic Type.使用系统文本样式(Large Title 到 Caption),让文字跟随用户的阅读字号;No hard-coded point sizes.San Francisco carries the UI.正文、标签、控件一律使用 SF Pro / SF Compact;品牌字体只允许出现在 display 时刻。11 pt floor;Body is 17 pt.字号下限 11 pt,正文(Body)固定 17 pt。这三条分别对应 audit.native.md 中三个不同的检查点:Accessibility 维度查 fixed point sizes defeating Dynamic Type ... layouts that clip or overlap at large sizes(固定字号击败 Dynamic Type、大字号下布局裁切或重叠);Appearance Theming 维度查硬编码颜色之外的硬编码一切;而验证流程一节则要求在大 Dynamic Type 尺寸下专门截图取证(见后文)。值得注意的分工:SF 承担全部 UI 文字,品牌字体只进 display 时刻——这与文档开篇brand expresses through ... type的表述一致,品牌表达被限定在平台开放的层次里。Color materials:语义色、Dark Mode 与一个 tintColor materials 一节的四条规则:Semantic system colors:label、secondaryLabel、systemBackground、separator、tint。它们自动适配 Dark Mode 与高对比度;直接用 hex 在这些场景下会断掉(raw hex breaks there)。Dark Mode is a first-class appearance.两种外观都要设计与测试。One tint colordrives interactive elements;decoration is not its job. 一个 tint 色驱动所有交互元素,它不负责装饰。System materialsfor blur and translucency behind bars and sheets;no hand-rolled glassmorphism. 栏与 sheet 后的模糊与半透明使用系统材质,禁止手搓玻璃拟态。从审计文档的映射看,这组规则直接支撑 Appearance Theming 维度(0–4 分)的打分:Hard-coded colors ... raw hex instead of semantic system colors、Broken dark appearance: missing dark variants, poor contrast in dark, quick inverts、Off-platform materials: hand-rolled visual materials where system materials ... are expected 都是逐条列举的检查点;4 分档的标准是 semantic throughout, both appearances first-class。Components controls:平台控件优先,SF Symbols 唯一Components controls 一节列出了四类组件准则:Platform controls.Switch、segmented control、stepper、系统 picker、action sheet、alert、context menu、swipe action。文档给出最尖锐的一句:Reinventing these for flavor is the most common native slop.——为了口味重造这些控件是最常见的原生 slop。SF Symbolsfor iconography:基线对齐、感知 Dynamic Type、有权重与缩放变体。Dont mix in a web icon set. 不要混入网页图标集。Deliberate modality.聚焦且可关闭的子任务用 sheet,沉浸场景用 full-screen cover。Cancel/Done 要清晰;尊重下滑关闭手势,除非有数据丢失才需要加守卫。Grouped/inset listsfor settings-shaped content;no bespoke card stacks. 设置型内容用分组/内嵌列表,禁止自造卡片堆。这四条同样被 audit.native.md 的 Platform Conformance 维度转译为检查项:Off-platform navigation ... iOS patterns on Android or vice versa、Web-shaped controls: HTML-style buttons, custom toggles, hover-dependent affordances、Icon drift: mixed icon sets instead of SF Symbols / Material Symbols。对照 android.md 可知,两边的 slop test 是对称的:iOS 版警惕从网站移植,Android 版警惕穿 Android 皮肤的 iOS App,互为镜像的失败模式。Motion:系统转场与 Reduce MotionMotion 一节两条:System transitions.push 是滑动进入,sheet 是升起,dismiss 反转入场动画。Custom transitions that fight the navigation model disorient.——与导航模型对抗的自定义转场会让人迷失。Honor Reduce Motion.开启减弱动态效果时,用 crossfade 替代视差与大幅滑动。animate.md 在遇到原生目标时明确follow the Motion section of ios.md ... including the platforms Reduce Motion behavior. Do not apply the web tooling below.——即 web 侧的动效工具链在原生平台完全让位于本节。Verifying the build:用 Simulator 证据完成验证这是本文档最具操作性的一节,给出三条取证规则,原文档的命令必须原样可用:1. 截图只能来自 Simulator,绝不能来自浏览器。Build and run, then capture withxcrun simctl io booted screenshot path.构建并运行后,用xcrun simctl io booted screenshot path截图。当多台模拟器同时在运行时,把booted换成目标设备的 UDID——通过xcrun simctl list devices booted获取;文档特别提醒:显示名可能撞名,UDID 不会。要求截取 App 所发布的每一类设备:至少一台 iPhone,若 iPad 是目标则再加一台 iPad,并且write the files where the review flow expects them——写到审查流程期望的位置。从 impeccable-finish-reviewer.md 可以看到这个约定的落点:原生平台的截图按设备类命名,存放在.impeccable/review/,例如phone.png与tablet.png(adaptive 平台再按 OS 加后缀)。2. Dark Mode 与 Dynamic Type 必须进入验证流程。xcrun simctl ui booted appearance darkflips appearance.用xcrun simctl ui booted appearance dark切换外观(多台在线时复用截图那台设备的 UDID);再在大 Dynamic Type 尺寸下检查一次——固定布局藏起来的文字裁切,只有这一步能暴露。3. Simulator 给广度,真机给真值。Simulators give breadth; posture, gestures, and performance need hardware. Say which one produced the evidence.姿态、手势与性能需要真机;报告中必须说明证据由哪种设备产生。adapt.native.md 在结尾处以 NEVER: ... Trust simulators alone 复述了同一条纪律,并要求逐平台覆盖at least one phone and one tablet, both orientations, split-screen where supported。这三条与 SKILL.md 的验证哲学一脉相承:核心原则要求Verify in bounded passes, not a loop,原生平台按the shipped device classes取证——截图、缺陷扫描、修复构成有界的批量回合,而非开放式自我打磨。ios.md 如何驱动一次 audit 评分把上文各节放回 audit.native.md 的评分框架,可以看到 ios.md 每个章节都是打分维度的判据来源:audit 维度(0–4 分)对应 ios.md 判据1. Accessibility(VoiceOver)11 pt 字号下限、Dynamic Type 不失效、44 pt 触控目标、Reduce Motion 的 crossfade 替代2. Performance无直接条文(由通用检查覆盖)3. Appearance Theming语义系统色、Dark Mode 一等外观、系统材质、单一 tint4. Platform Conformance(CRITICAL)slop test 全节:安全区、系统导航、边缘返回、平台控件、SF Symbols、模态5. Adaptivity大标题/内联层级、sheet 语义,配合 size-class 适配总分 20 分,评级带为:18–20 Excellent,14–17 Good,10–13 Acceptable,6–9 Poor,0–5 Critical;报告强制以 Platform Conformance 裁决开头(Pass/fail: does this read as a native app or a ported website?),所有问题按 P0–P3 分级,并只允许推荐技能内置命令(adapt / animate / ... / polish)作为修复路径,以/impeccable polish收尾。加载失效与修复:doctor 的 drift 检查一个容易被忽视的边界情况:doctor.md 列出了workspace-platform-native-evidence这一 drift 发现——当工作区携带原生构建文件、却继承了解析为 web 的根 PRODUCT.md 时,整个工作区会gets web guidance for its whole life and never loads ios.md or android.md(一辈子拿到 web 指引,永远不加载 ios.md);修复方式是在该工作区写一个子 PRODUCT.md,因为一条继承记录无法同时承载两个平台。从源码结构看,这是 init.md 中init 是学习平台答案的唯一入口这一设计在存量多工作区仓库中的必然推论:平台判定是单点写入、多点消费的模型,单点错了,下游所有以 ios.md 为标尺的评分与检查都会静默降级为 web 逻辑。小结:一张原生 iOS 验收清单把 ios.md 的全部硬性要求压缩为可执行的验收清单:布局收在安全区内,灵动岛/Home 条下无控件;2–5 个顶层分区走 tab bar,层级走导航栈,子任务走 sheet,不自造全局导航;左缘返回手势未被禁用或遮挡;顶层页大标题、滚动收内联,深层页保持内联;所有可点控件 ≥ 44×44 pt,相邻目标有间距;全部文字走系统文本样式,无硬编码字号;UI 文字在 SF 上,正文 17 pt、下限 11 pt;颜色全用语义系统色,Dark Mode 与高对比度均可用;tint 唯一且只驱动交互;栏与 sheet 用系统材质;Switch、picker、action sheet 等一律平台控件;图标只用 SF Symbols;转场用系统动画,Reduce Motion 下退化为 crossfade;证据链:xcrun simctl io booted screenshot覆盖每类设备;xcrun simctl ui booted appearance dark切换外观;大 Dynamic Type 复查;并注明证据来源是 Simulator 还是真机。这份清单的价值在于它把平台规范遵从从风格偏好变成了可打分、可复验的工程问题:每一项都能被 audit.native.md 的五个维度接住,并被xcrun取证流程固化成可留存的截图证据。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Impeccable 的 iOS 平台设计语言:原生 App 的导航、组件、字体与模拟器验证规范
Impeccable 的 iOS 平台设计语言:原生 App 的导航、组件、字体与模拟器验证规范【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable本篇围绕 Impeccable 技能体系中的 iOS 平台参考文档 ios.md 展开。它规定了面向 SwiftUI / UIKit / React Native / Expo / Flutter 等原生与跨端 iOS 工程的设计底线:安全区布局、系统导航、Dynamic Type、语义颜色与 SF Symbols 等组件准则,以及一套用xcrun simctl完成截图取证与外观/字号切换的验证流程。读完后,你能判断一个 iOS 界面是否像原生应用,并能用文档中的命令行在 Simulator 上产出自检证据。这份文档在 Impeccable 中的位置ios.md 是 Impeccable 技能(定义于 SKILL.md)针对原生 iOS / iPadOS 应用的平台宪法,适用对象是shipping to Apple hardware的工程:SwiftUI、UIKit,以及 React Native、Expo、Flutter 等跨端框架落到苹果设备的产物。文档开篇即给出它在 Impeccable 模式体系中的定位:On native, the visitor mode narrows what expression may override. HIG conformance governs structure, navigation, and interaction in every mode; brand expresses through the layer the platform leaves open (tint, type, motion, content).也就是说,在原生平台上,Impeccable 的四种 visitor mode(Persuade / Operate / Read / Experience,见 SKILL.md 的 Modes 一节)只能收窄品牌表达的权限,而不能推翻平台规范:结构、导航、交互由 HIG(iOS 人机界面指南)约束,品牌只能表达在平台留白的层次上——tint 色、字体、动效与内容。平台参考文档的加载时机由技能流程保证。从源码结构看,加载链如下:init.md 的init流程会把平台判定为web、ios、android或adaptive并写入PRODUCT.md;其中明确写道:记录为ios之后,load ios.md ... before any design work,并且对于没有 PRODUCT.md 的存量项目,init is the only place that learns the answer——只有 init 能学到平台答案,此前的 context 脚本无从知晓。layout.md、typeset.md、animate.md、adapt.native.md 等具体设计命令在遇到原生目标时,都会把导航、insets、适配、触控目标、字体的决策权交给 ios.md 或 android.md。audit.native.md 则把 ios.md 当作评分标尺:Score against the platform reference(s): ios.md / android.md,并在打分前要求先读入该参考文档。The iOS slop test:一条判据,而非十条细则文档把最核心的验收标准压缩成一个问题:Would a fluent iPhone user trust this app, or pause at off-spec controls?一个熟练的 iPhone 用户是信任这个 App,还是会因为不合规范的控件而迟疑?文档随即给出最常见的败因——ported from a website(从网站移植来的痕迹):自造导航栏、自定义返回手势、网页形态的按钮、依赖 hover 的交互提示。结论性指令是:Default to the platforms components; depart only for a reason the user would thank you for.默认使用平台组件;只有当偏离能给用户带来实际回报时才偏离。这一 slop test 在 audit.native.md 中被提升为评分第 4 维度Platform Conformance(CRITICAL)的核心判据,报告必须首先给出 Pass/fail: does this read as a native app or a ported website? 的裁决。Layout structure:安全区、系统导航与返回手势原文档的 Layout structure 一节包含四条硬约束,完整继承如下:约束文档原文要求要点解读Safe areaLay out inside the safe-area insets. No controls under the notch, Dynamic Island, home indicator, or rounded corners.布局必须收在安全区内;刘海、灵动岛、Home 指示条与圆角之下不允许放任何控件System navigationTab bar for 2–5 top-level sections (sections, never actions), navigation stack for hierarchy, sheet for self-contained tasks. No custom global nav, no mixed metaphors.Tab bar 承载 2–5 个顶层分区(是 sections,不是 actions);层级用导航栈;自包含任务用 sheet;禁止自造全局导航、禁止混用隐喻Edge-swipe backThe left-edge back gesture is muscle memory; never disable or overlay it.左缘返回手势是肌肉记忆,永不禁用、永不遮挡Large titleson top-level screens, collapsing to inline on scroll. Deep detail screens stay inline.顶层页面用大标题,滚动时收为内联;深层详情页保持内联这四条与 audit.native.md 第 4 维度的检查项一一对应:该维度会把 edge-swipe back disabled、content under the notch / Dynamic Island / home indicator、custom global nav, overloaded tab bars 列为明确的扣分证据;第 5 维度 Adaptivity 则补充了 iPad Split View 等多任务场景下的布局校验。Touch targets:44×44 pt 是绝对下限原文档对触控目标只有一条,但表述是排他性的:44×44 pt minimumfor every tappable control, with breathing room between adjacent targets.每个可点控件最小 44×44 pt,且相邻目标之间要留呼吸空间。这条规则在 audit.native.md 中同时出现在两个维度:Accessibility 维度检查 below 44 pt ... or crammed without spacing,平台符合度报告示例中的系统性问题也以此为典型(Touch targets consistently below 44 pt throughout the tab bar and list rows)。作为对照,android.md 的下限是 48×48 dp 且间距至少 8 dp——两个平台的数值差异本身提示:这类下限不是经验值,而是各自平台规范(HIG / Material)的条文,移植时必须换算而非照抄。Typography:Dynamic Type 与 SF 的分工Typography 一节包含三条规则:Dynamic Type.使用系统文本样式(Large Title 到 Caption),让文字跟随用户的阅读字号;No hard-coded point sizes.San Francisco carries the UI.正文、标签、控件一律使用 SF Pro / SF Compact;品牌字体只允许出现在 display 时刻。11 pt floor;Body is 17 pt.字号下限 11 pt,正文(Body)固定 17 pt。这三条分别对应 audit.native.md 中三个不同的检查点:Accessibility 维度查 fixed point sizes defeating Dynamic Type ... layouts that clip or overlap at large sizes(固定字号击败 Dynamic Type、大字号下布局裁切或重叠);Appearance Theming 维度查硬编码颜色之外的硬编码一切;而验证流程一节则要求在大 Dynamic Type 尺寸下专门截图取证(见后文)。值得注意的分工:SF 承担全部 UI 文字,品牌字体只进 display 时刻——这与文档开篇brand expresses through ... type的表述一致,品牌表达被限定在平台开放的层次里。Color materials:语义色、Dark Mode 与一个 tintColor materials 一节的四条规则:Semantic system colors:label、secondaryLabel、systemBackground、separator、tint。它们自动适配 Dark Mode 与高对比度;直接用 hex 在这些场景下会断掉(raw hex breaks there)。Dark Mode is a first-class appearance.两种外观都要设计与测试。One tint colordrives interactive elements;decoration is not its job. 一个 tint 色驱动所有交互元素,它不负责装饰。System materialsfor blur and translucency behind bars and sheets;no hand-rolled glassmorphism. 栏与 sheet 后的模糊与半透明使用系统材质,禁止手搓玻璃拟态。从审计文档的映射看,这组规则直接支撑 Appearance Theming 维度(0–4 分)的打分:Hard-coded colors ... raw hex instead of semantic system colors、Broken dark appearance: missing dark variants, poor contrast in dark, quick inverts、Off-platform materials: hand-rolled visual materials where system materials ... are expected 都是逐条列举的检查点;4 分档的标准是 semantic throughout, both appearances first-class。Components controls:平台控件优先,SF Symbols 唯一Components controls 一节列出了四类组件准则:Platform controls.Switch、segmented control、stepper、系统 picker、action sheet、alert、context menu、swipe action。文档给出最尖锐的一句:Reinventing these for flavor is the most common native slop.——为了口味重造这些控件是最常见的原生 slop。SF Symbolsfor iconography:基线对齐、感知 Dynamic Type、有权重与缩放变体。Dont mix in a web icon set. 不要混入网页图标集。Deliberate modality.聚焦且可关闭的子任务用 sheet,沉浸场景用 full-screen cover。Cancel/Done 要清晰;尊重下滑关闭手势,除非有数据丢失才需要加守卫。Grouped/inset listsfor settings-shaped content;no bespoke card stacks. 设置型内容用分组/内嵌列表,禁止自造卡片堆。这四条同样被 audit.native.md 的 Platform Conformance 维度转译为检查项:Off-platform navigation ... iOS patterns on Android or vice versa、Web-shaped controls: HTML-style buttons, custom toggles, hover-dependent affordances、Icon drift: mixed icon sets instead of SF Symbols / Material Symbols。对照 android.md 可知,两边的 slop test 是对称的:iOS 版警惕从网站移植,Android 版警惕穿 Android 皮肤的 iOS App,互为镜像的失败模式。Motion:系统转场与 Reduce MotionMotion 一节两条:System transitions.push 是滑动进入,sheet 是升起,dismiss 反转入场动画。Custom transitions that fight the navigation model disorient.——与导航模型对抗的自定义转场会让人迷失。Honor Reduce Motion.开启减弱动态效果时,用 crossfade 替代视差与大幅滑动。animate.md 在遇到原生目标时明确follow the Motion section of ios.md ... including the platforms Reduce Motion behavior. Do not apply the web tooling below.——即 web 侧的动效工具链在原生平台完全让位于本节。Verifying the build:用 Simulator 证据完成验证这是本文档最具操作性的一节,给出三条取证规则,原文档的命令必须原样可用:1. 截图只能来自 Simulator,绝不能来自浏览器。Build and run, then capture withxcrun simctl io booted screenshot path.构建并运行后,用xcrun simctl io booted screenshot path截图。当多台模拟器同时在运行时,把booted换成目标设备的 UDID——通过xcrun simctl list devices booted获取;文档特别提醒:显示名可能撞名,UDID 不会。要求截取 App 所发布的每一类设备:至少一台 iPhone,若 iPad 是目标则再加一台 iPad,并且write the files where the review flow expects them——写到审查流程期望的位置。从 impeccable-finish-reviewer.md 可以看到这个约定的落点:原生平台的截图按设备类命名,存放在.impeccable/review/,例如phone.png与tablet.png(adaptive 平台再按 OS 加后缀)。2. Dark Mode 与 Dynamic Type 必须进入验证流程。xcrun simctl ui booted appearance darkflips appearance.用xcrun simctl ui booted appearance dark切换外观(多台在线时复用截图那台设备的 UDID);再在大 Dynamic Type 尺寸下检查一次——固定布局藏起来的文字裁切,只有这一步能暴露。3. Simulator 给广度,真机给真值。Simulators give breadth; posture, gestures, and performance need hardware. Say which one produced the evidence.姿态、手势与性能需要真机;报告中必须说明证据由哪种设备产生。adapt.native.md 在结尾处以 NEVER: ... Trust simulators alone 复述了同一条纪律,并要求逐平台覆盖at least one phone and one tablet, both orientations, split-screen where supported。这三条与 SKILL.md 的验证哲学一脉相承:核心原则要求Verify in bounded passes, not a loop,原生平台按the shipped device classes取证——截图、缺陷扫描、修复构成有界的批量回合,而非开放式自我打磨。ios.md 如何驱动一次 audit 评分把上文各节放回 audit.native.md 的评分框架,可以看到 ios.md 每个章节都是打分维度的判据来源:audit 维度(0–4 分)对应 ios.md 判据1. Accessibility(VoiceOver)11 pt 字号下限、Dynamic Type 不失效、44 pt 触控目标、Reduce Motion 的 crossfade 替代2. Performance无直接条文(由通用检查覆盖)3. Appearance Theming语义系统色、Dark Mode 一等外观、系统材质、单一 tint4. Platform Conformance(CRITICAL)slop test 全节:安全区、系统导航、边缘返回、平台控件、SF Symbols、模态5. Adaptivity大标题/内联层级、sheet 语义,配合 size-class 适配总分 20 分,评级带为:18–20 Excellent,14–17 Good,10–13 Acceptable,6–9 Poor,0–5 Critical;报告强制以 Platform Conformance 裁决开头(Pass/fail: does this read as a native app or a ported website?),所有问题按 P0–P3 分级,并只允许推荐技能内置命令(adapt / animate / ... / polish)作为修复路径,以/impeccable polish收尾。加载失效与修复:doctor 的 drift 检查一个容易被忽视的边界情况:doctor.md 列出了workspace-platform-native-evidence这一 drift 发现——当工作区携带原生构建文件、却继承了解析为 web 的根 PRODUCT.md 时,整个工作区会gets web guidance for its whole life and never loads ios.md or android.md(一辈子拿到 web 指引,永远不加载 ios.md);修复方式是在该工作区写一个子 PRODUCT.md,因为一条继承记录无法同时承载两个平台。从源码结构看,这是 init.md 中init 是学习平台答案的唯一入口这一设计在存量多工作区仓库中的必然推论:平台判定是单点写入、多点消费的模型,单点错了,下游所有以 ios.md 为标尺的评分与检查都会静默降级为 web 逻辑。小结:一张原生 iOS 验收清单把 ios.md 的全部硬性要求压缩为可执行的验收清单:布局收在安全区内,灵动岛/Home 条下无控件;2–5 个顶层分区走 tab bar,层级走导航栈,子任务走 sheet,不自造全局导航;左缘返回手势未被禁用或遮挡;顶层页大标题、滚动收内联,深层页保持内联;所有可点控件 ≥ 44×44 pt,相邻目标有间距;全部文字走系统文本样式,无硬编码字号;UI 文字在 SF 上,正文 17 pt、下限 11 pt;颜色全用语义系统色,Dark Mode 与高对比度均可用;tint 唯一且只驱动交互;栏与 sheet 用系统材质;Switch、picker、action sheet 等一律平台控件;图标只用 SF Symbols;转场用系统动画,Reduce Motion 下退化为 crossfade;证据链:xcrun simctl io booted screenshot覆盖每类设备;xcrun simctl ui booted appearance dark切换外观;大 Dynamic Type 复查;并注明证据来源是 Simulator 还是真机。这份清单的价值在于它把平台规范遵从从风格偏好变成了可打分、可复验的工程问题:每一项都能被 audit.native.md 的五个维度接住,并被xcrun取证流程固化成可留存的截图证据。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考