Mobile App PRD Template for Product Planning

Use this template whenever the product or feature ships as a mobile app (iOS, Android, or both). Even if you are adding a mobile-specific feature to an existing app, the platform considerations, permission flows, and device targeting sections add structure that a generic PRD lacks. For web-only features, the standard [PRD template](/templates/prd-template) is sufficient.

The decision depends on three factors: team expertise, performance requirements, and platform-specific API needs. Native development (Swift/Kotlin) gives the best performance and full platform API access but doubles the codebase. Cross-platform frameworks like React Native or Flutter share 70-90% of code but may require native modules for features like HealthKit or ARKit. Document this decision in the Technical Architecture section with a clear rationale.

Check the latest adoption data from Apple and Google. A common starting point is iOS 16+ (covers ~95% of active devices) and Android 12+ API 31 (covers ~70% of active devices). Lower your Android floor if your target audience skews toward emerging markets where older devices are common. Always document the trade-off between reach and engineering complexity.

Build review compliance into the PRD from the start. Common rejection reasons include requesting unnecessary permissions without justification, missing privacy policy links, and incomplete metadata. The Platform Considerations checklist in this template covers the most frequent issues. Allow 2-5 business days for initial review and plan at least one resubmission cycle into your timeline.

No. Write one PRD that covers both platforms with a dedicated Platform Considerations section for each. Separate PRDs create drift between platforms and make it harder to maintain feature parity. The exception is when you are building fully native apps with different feature sets by design, which is rare. ---