| name | mobile-android-ios-parity |
| description | Bring src/mobile/android to feature and behavior parity with src/mobile/ios while keeping each app native. Use when comparing iOS Swift/SwiftUI/UIKit mobile behavior against Android Kotlin/Jetpack Compose behavior, implementing missing Android features, or validating parity with the Test Android Apps emulator QA workflow. |
| metadata | {"keywords":["mobile","android","ios","parity","kotlin","swift","compose","emulator","adb","share intent","upload"]} |
Mobile Android/iOS Parity
Use this skill when the goal is for src/mobile/ios and src/mobile/android to represent the same user-facing act while remaining native implementations under the hood.
Feature parity means: same user outcome, same data semantics, same error handling quality, and equivalent workflows. It does not mean copying Swift code into Android, copying Compose UI into iOS, or forcing identical platform chrome.
Non-negotiables
- Keep Android native: Kotlin, Gradle, Android APIs, Jetpack Compose, Android lifecycle, intents, storage, permissions, and platform services.
- Keep iOS native: Swift, SwiftUI/UIKit, extensions, app groups, iOS storage/security APIs.
- Do not replace
src/mobile/android with Swift-on-Android for app UI or platform integration.
- Use Swift/iOS code as the behavioral specification for Android, not as code to mechanically port.
- Preserve file formats and persisted semantics where users expect cross-platform compatibility: app config JSON, queue/history records,
.sxcu, .xsdc, upload result fields, destination IDs, generated URLs, and error text where practical.
- Update docs and durable lessons when the implementation reveals repo-specific mobile behavior.
