Mobile Experimental/iOS Parity

Use this skill when src/mobile-experimental must match src/mobile/ios feature-wise while keeping Avalonia, MAUI, Android, and iOS platform heads idiomatic.

Feature parity means the same user outcome, compatible persisted data, comparable error handling, and platform-native presentation. It does not mean copying SwiftUI into Avalonia/MAUI or forcing identical visual chrome.

Non-negotiables

• Treat src/mobile/ios as the behavioral contract.
• Keep experimental code native to its stack:
  • Avalonia: .axaml, compiled bindings, avares:// assets, platform services from TopLevel, Android/iOS platform heads where needed.
  • MAUI: XAML pages, Shell navigation, FilePicker, Launcher, platform heads where needed.
  • Android platform heads: intents, content URI handling, scoped cache files, Android package metadata.
  • iOS platform heads: bundle IDs, URL schemes, share extension/app-group behavior, iOS appearance defaults.
• Preserve cross-platform file/data contracts: .sxcu, .xsdc, upload queue/history records, destination IDs, generated URLs, and user-facing import messages where practical.
• Do not let experimental convenience drift from production identity. App IDs, URL schemes, document types, app group IDs, logo, version display, and About links should match src/mobile/ios unless intentionally forked.
• Use the Avalonia docs MCP rules at the start of Avalonia work. Avoid WPF-only patterns such as triggers, pack:// URIs, and DependencyProperty.

First pass