Whether you ship a fully native app or a React Native app with native modules, iOS rewards treating platform behavior as a product requirement. Permissions, background execution, signing, and privacy declarations are not afterthoughts — they decide whether your app passes review and behaves correctly on device.
Key takeaways
- Treat permissions, background modes, signing, and privacy declarations as product requirements.
- Use native modules when platform behavior cannot be expressed reliably in JavaScript.
- Test real devices, lifecycle transitions, and App Store release builds.
SwiftUI, UIKit, and native modules
New native UI is best built in SwiftUI, falling back to UIKit for screens that need fine control or integration with older code. In a React Native app, reach for a native module only when behavior cannot be expressed reliably in JavaScript — background location, secure enclave access, or a vendor SDK with no JS bridge.
Keep the native surface small and well-typed at the boundary so most of the product still lives in shared code.
Permissions, signing, and release
Declare every permission with a clear usage string, configure background modes only for capabilities you actually use, and fill in the privacy manifest and App Privacy details accurately — review rejections here are common and avoidable.
Test on physical devices across lifecycle transitions (background, foreground, termination, low memory), and validate the actual release build through TestFlight before submission. Read the App Store Review Guidelines before your first submission, not after a rejection.