Build Better Mobile Apps: AI Prompts for iOS & Android

I spent three weeks building a login screen. Three weeks. Modal animations, biometric authentication, error handling, edge cases—the works. Then I tried a structured React Native prompt. The entire screen, complete with error states and accessibility, was done in 45 minutes.

That’s when I realized: AI won’t replace mobile developers. But developers who use AI will ship faster than those who don’t.

I’ve been using AI prompts for mobile development (React Native, SwiftUI, Kotlin, Flutter) for two years. Some prompts save me hours on boilerplate. Others help me understand complex APIs. The difference is knowing how to ask and when to trust the output.

In this guide, I’m sharing 16 prompts I actually use for mobile development. These aren’t generic “write code” prompts—they’re sophisticated tools for component creation, architecture decisions, and debugging.

Fair warning: AI can generate bad code, especially around deprecated APIs and security. Always review, test, and understand what AI produces.

If you’re new to vibe coding, start with our best vibe coding tools guide to set up your development environment.

What Makes an Effective Mobile Development Prompt? (The Framework)

Think of AI as a senior developer who’s seen every anti-pattern and knows the documentation by heart. Here’s the 5-component framework I use:

1. Role: Tell the AI what kind of developer expertise you need
2. Framework: Specify your tech stack (React Native, SwiftUI, Kotlin, Flutter)
3. Context: Provide your component, screen, or feature requirements
4. Constraints: Mention platform specifics, versions, and limitations
5. Output: Specify what you need (code, explanation, debugging)

Here’s the difference:

Vague Prompt	Structured Prompt
”Help me with a button component"	"Act as a React Native expert. Create a Button component with primary, secondary, and outline variants. Include loading state, disabled state, TypeScript props, and accessibility labels. Using iOS and Android platform conventions.”

See the pattern? Now, here’s what you need to know about when not to rely on AI:

• Security-critical code: Authentication, encryption—review thoroughly
• API integrations: Verify AI’s understanding of current API versions
• Performance optimization: AI may suggest patterns that don’t scale
• App Store guidelines: Always verify compliance yourself

Hot take: AI is your pair programmer, not your replacement. It accelerates execution, but you still own the architecture.

Note for web developers: Check out our essential code prompts

Note for DevOps: Our AI prompts for DevOps engineers covers deployment

Ready? Let’s build your mobile development toolkit.

For official documentation, check out Apple’s iOS Developer Documentation for SwiftUI and native iOS development, Google’s Android Developers Guide for Kotlin and Jetpack, and React Native’s official documentation for cross-platform development.

---

Component Development Prompts (Prompts #1-5)

#1: React Native Component Generator

The Prompt:

Act as a senior React Native engineer. Design and implement a production-ready React Native component in TypeScript.

CONTEXT:
- Component name and type: [Button, Card, Modal, List, FormInput, etc.]
- App context: [consumer app, B2B dashboard, marketplace, health app, etc.]
- Target platforms: [iOS, Android, both]
- React Native setup: [Expo or bare RN], [React Native version if known], [TypeScript yes/no]
- Design system: [native components, React Native Paper, Tamagui, custom tokens, etc.]
- Required states: [default, pressed, loading, disabled, error, empty]
- Inputs/props: [list required props, optional props, callbacks]
- Existing constraints: [theme API, navigation library, analytics, accessibility requirements]

TASK:
Create the component as if it will be merged into a real app. Include:

1. A clean TypeScript props interface with sensible defaults
2. Component code with stable callbacks, memoization only where useful, and no unnecessary re-renders
3. Platform-specific behavior where iOS and Android should differ
4. Accessible labels, roles, hints, focus behavior, and screen-reader notes
5. Touch feedback, loading, disabled, and error states
6. Theme/dark-mode support without hardcoded colors
7. Unit test examples and a Storybook/preview example when relevant
8. A short list of assumptions and tradeoffs

OUTPUT FORMAT:
```typescript
// 1. Props interface
// 2. Component implementation
// 3. Styles/theme integration
// 4. Usage example
// 5. Test example
// 6. Accessibility checklist
```

Before writing code, ask up to three clarifying questions if required information is missing. If assumptions are safe, state them and proceed.

Use case: When building reusable UI components Best with: A coding model that can inspect surrounding component patterns Pro tip: Paste one existing component so AI matches the app’s naming, styling, and test conventions

For more React Native patterns, see our ChatGPT coding guide for developers.

#2: SwiftUI View Generator

The Prompt:

Act as a senior iOS engineer specializing in SwiftUI. Build an idiomatic SwiftUI view for a production iOS app.

CONTEXT:
- View name and purpose: [what the view does]
- iOS target: [minimum iOS version]
- Swift version / Xcode version if known: [version]
- Design guidance: [Apple HIG, custom design tokens, existing app style]
- Data source: [static props, @State, @Binding, @Observable, ViewModel, async API]
- User interactions: [buttons, gestures, navigation, forms]
- Required states: [loading, empty, error, success, disabled]
- Accessibility requirements: [VoiceOver, Dynamic Type, reduced motion, contrast]
- Existing model/types: [paste relevant structs or protocols]

TASK:
Create a SwiftUI implementation that includes:

1. The main `View` with clear body composition
2. Appropriate state management without unnecessary view-model complexity
3. Extracted subviews only where they improve readability
4. Accessibility labels, traits, Dynamic Type behavior, and VoiceOver notes
5. Light/dark mode and different screen-size previews
6. Error, loading, and empty-state handling when applicable
7. Unit-testable logic separated from view rendering when useful
8. A short explanation of iOS-version-specific APIs used

OUTPUT FORMAT:
```swift
// 1. SwiftUI view code
// 2. Supporting types or view model, if needed
// 3. Preview configurations
// 4. Accessibility and testing notes
```

Do not use deprecated APIs. If a newer SwiftUI API requires a higher iOS target, provide a compatible fallback.

Use case: When building native iOS components Best with: A model that understands SwiftUI lifecycle and platform conventions Pro tip: Always include the minimum supported iOS version so the model avoids unavailable modifiers

#3: Kotlin Android Module

The Prompt:

Act as a senior Android engineer specializing in Kotlin, Jetpack, and production app architecture. Create a [COMPONENT TYPE] implementation.

CONTEXT:
- Component type: [ViewModel, Repository, UseCase, Fragment, Compose screen, Worker]
- App architecture: [MVVM, Clean Architecture, MVI, modular monolith, etc.]
- UI stack: [Jetpack Compose, XML views, hybrid]
- Kotlin version / Android Gradle Plugin version: [if known]
- Minimum SDK / target SDK: [versions]
- Dependency injection: [Hilt, Koin, manual, none]
- Async/data stack: [Coroutines, Flow, Room, Retrofit, WorkManager, DataStore]
- Existing interfaces/models: [paste relevant code]
- Required states and failures: [loading, empty, offline, permission denied, retry]

TASK:
Create a production-ready Android implementation with:

1. Idiomatic Kotlin with clear null-safety and sealed UI states where useful
2. Correct coroutine scope, cancellation, dispatcher, and Flow handling
3. Dependency injection wiring that matches the chosen DI tool
4. Compose or XML integration based on the UI stack
5. Error handling for network, validation, offline, and permission cases
6. Unit tests using fakes/mocks and coroutine test utilities
7. Notes on lifecycle safety and memory-leak risks
8. Assumptions about APIs or libraries that need verification

OUTPUT FORMAT:
```kotlin
// 1. Kotlin implementation
// 2. DI/module wiring if needed
// 3. UI integration example
// 4. Test examples
// 5. Lifecycle and edge-case notes
```

Do not invent library APIs. If exact versions are unknown, use stable AndroidX patterns and clearly label assumptions.

Use case: When building native Android components Best with: A coding model that can reason about lifecycle, coroutines, and DI Pro tip: Include existing package names and module boundaries so the generated code drops in cleanly

#4: Flutter Widget Builder

The Prompt:

Act as a senior Flutter engineer. Build a production-quality Dart widget that follows Flutter conventions and the app's state-management pattern.

CONTEXT:
- Widget name and purpose: [what it displays or controls]
- Widget type: [StatelessWidget, StatefulWidget, sliver, custom painter, animation, form]
- Platforms: [iOS, Android, web, desktop]
- Flutter/Dart version if known: [version]
- Design system: [Material 3, Cupertino, custom theme]
- State management: [setState, Provider, Riverpod, BLoC, GetX, inherited model]
- Required states: [loading, empty, error, disabled, success]
- Inputs/callbacks: [props, streams, controllers, callbacks]
- Accessibility/localization needs: [semantics, text scaling, RTL, localization]

TASK:
Create a production-ready widget with:

1. Clean Dart code with immutable inputs where possible
2. Correct state-management integration without over-engineering
3. Theme support for light/dark mode and Material/Cupertino differences
4. Semantics, focus, text scaling, and localization considerations
5. Layout that works across common screen sizes
6. Animation code only if it improves the UX
7. Example usage and widget test examples
8. Performance notes for rebuilds, lists, images, and controllers

OUTPUT FORMAT:
```dart
// 1. Widget implementation
// 2. Supporting state/controller code if needed
// 3. Usage example
// 4. Widget test example
// 5. Accessibility and performance notes
```

If a package is required, explain why and include a no-new-dependency alternative when practical.

Use case: When building cross-platform Flutter components Best with: A model that can balance Flutter layout, state, and performance Pro tip: Tell AI the state-management library first; otherwise it may mix patterns

#5: Mobile UI Patterns

The Prompt:

Act as a senior mobile UX engineer. Design and implement a [PATTERN TYPE] pattern that feels native on the target platform.

CONTEXT:
- Pattern type: [onboarding, empty state, error recovery, loading state, infinite scroll, permissions, offline mode]
- Framework: [React Native, SwiftUI, Kotlin/Compose, Flutter]
- Target platforms: [iOS, Android, both]
- User goal: [what the user is trying to accomplish]
- Business goal: [activation, retention, conversion, completion, trust]
- Data conditions: [no data, slow network, partial data, failed request]
- Platform conventions: [Apple HIG, Material Design, app-specific design system]
- Accessibility requirements: [screen readers, reduced motion, large text, contrast]
- Analytics events if needed: [event names or desired funnel]

TASK:
Create the mobile pattern with:

1. UX behavior and state diagram in plain language
2. Production-ready component/screen code
3. Platform-specific interaction differences
4. Accessible copy, labels, focus order, and motion alternatives
5. Empty/error/offline/retry edge cases
6. Analytics events that avoid collecting sensitive data
7. Test cases for the core states
8. A short checklist for design review

OUTPUT FORMAT:
- Full code implementation
- Usage examples
- State and edge-case table
- Accessibility notes
- Testing guidance

Use case: When implementing common mobile UX patterns Best with: A model that can combine UX reasoning with framework-specific code Pro tip: Ask for a state table first; it prevents the model from only coding the happy path

---

Architecture and Integration Prompts (Prompts #6-10)

#6: App Store Optimization

The Prompt:

Act as an App Store Optimization strategist with mobile product marketing experience. Create an ASO strategy for [APP NAME].

CONTEXT:
- App name: [APP NAME]
- Category: [CATEGORY]
- Platforms: [Apple App Store, Google Play, both]
- Target audience: [who downloads and why]
- Core value proposition: [one-sentence benefit]
- Monetization: [free, paid, subscription, IAP, ads]
- Current metadata: [title, subtitle/short description, long description, keywords if any]
- Competitors: [3-5 key competitors]
- Markets/locales: [countries/languages]
- Compliance constraints: [regulated category, age rating, claims to avoid]

TASK:
Create an ASO plan that includes:

1. Keyword themes by user intent, not just keyword volume
2. App Store title/subtitle/keyword-field recommendations
3. Google Play title/short-description/long-description recommendations
4. Screenshot and preview-video messaging hierarchy
5. Localization opportunities and cultural risks
6. Review/rating growth plan that follows store policies
7. A/B testing roadmap with hypotheses and success metrics
8. Compliance notes for claims, subscriptions, privacy, and age rating

OUTPUT FORMAT:
- Keyword map by intent
- Metadata drafts for Apple App Store and Google Play
- Screenshot/video storyboard
- A/B test plan
- Policy/compliance checklist

Do not recommend misleading metadata, competitor trademark stuffing, or review manipulation.

Use case: When optimizing app store presence Best with: A model that can reason about positioning, search intent, and store policy Pro tip: Provide competitor listings or screenshots if available; ASO improves with real market context

#7: Mobile Analytics Setup

The Prompt:

Act as a senior mobile analytics engineer. Design a privacy-aware analytics implementation plan for [APP TYPE].

CONTEXT:
- App type: [CONSUMER, B2B, UTILITY, GAMING]
- Analytics platform: [AMPLITUDE, MIXPANEL, FIREBASE, CUSTOM]
- Platforms: [IOS, ANDROID]
- Primary funnels: [activation, onboarding, purchase, retention, referral]
- Key user actions: [events to track]
- User properties: [attributes to track]
- Data sensitivity: [PII, health, finance, location, children, none]
- Privacy requirements: [GDPR, CCPA/CPRA, ATT, consent mode, internal policy]
- Existing schema: [paste current event names if any]
- Engineering stack: [React Native, Swift, Kotlin, Flutter, backend]

TASK:
Create an analytics plan and implementation guide with:

1. Event taxonomy with names, triggers, properties, and owners
2. Naming conventions that prevent duplicate or ambiguous events
3. Screen tracking and lifecycle rules
4. Consent, opt-out, deletion, and data minimization strategy
5. Platform-specific implementation snippets
6. Debug logging and QA workflow
7. Dashboard recommendations for the first 30 days
8. Data-quality checks for missing, duplicated, or late events

OUTPUT FORMAT:
- Event taxonomy document
- Implementation snippets
- Consent/privacy checklist
- Testing strategy
- Dashboard starter metrics

Do not include raw PII in event properties. Flag any proposed property that could be sensitive.

Use case: When setting up analytics infrastructure Best with: A model that can connect product funnels to implementation details Pro tip: Start with one funnel and 5-10 high-signal events before tracking everything

For robust error handling in your analytics implementation, check out our AI error handling snippets.

#8: Push Notification Campaign

The Prompt:

Act as a mobile lifecycle and engagement strategist. Create a push notification strategy that respects user trust and platform rules.

CONTEXT:
- App type: [CONSUMER, B2B, PRODUCTIVITY]
- Notification types: [TRANSACTIONAL, MARKETING, BEHAVIORAL, SECURITY, REMINDER]
- User segments: [SEGMENTS TO TARGET]
- Goals: [engagement, retention, conversion, safety, habit formation]
- Platforms: [IOS, ANDROID]
- Opt-in status: [not requested, partially opted in, low opt-in rate, healthy opt-in rate]
- Personalization inputs: [behavior, preferences, location, plan, lifecycle stage]
- Quiet hours/time zones: [rules]
- Deep links: [screens or routes]
- Brand voice: [tone and words to avoid]

TASK:
Create a notification system with:

1. Notification categories by user value and urgency
2. Permission prompt timing and pre-permission education
3. Message templates with variables and fallbacks
4. Frequency caps, quiet hours, and suppression rules
5. Deep-link behavior and fallback screens
6. A/B tests for copy, timing, and trigger logic
7. Metrics: opt-in rate, open rate, conversion, unsubscribe, churn impact
8. Guardrails for sensitive content and over-notification

OUTPUT FORMAT:
- Notification category definitions
- Message templates with variables
- Timing recommendations
- A/B test matrix
- Success metrics
- Suppression and safety rules

Avoid manipulative urgency, sensitive personal details on lock screens, and campaigns that create notification fatigue.

Use case: When building notification strategy Best with: A model that can balance growth, privacy, and user experience Pro tip: Build transactional and reminder notifications before marketing campaigns

#9: In-App Purchase Guide

The Prompt:

Act as a mobile monetization engineer. Design an in-app purchase implementation guide that is reliable, testable, and store-compliant.

CONTEXT:
- Purchase type: [CONSUMABLE, NON-CONSUMABLE, SUBSCRIPTION]
- Platforms: [iOS StoreKit, Android Play Billing, both]
- Product catalog: [PRODUCTS TO OFFER]
- Paywall locations: [onboarding, feature gate, settings, upgrade screen]
- Entitlement rules: [what each product unlocks]
- Backend availability: [server receipt validation yes/no]
- Account model: [anonymous, signed-in, family/team account]
- Edge cases: [refunds, cancellations, grace period, restore, network loss]
- Testing needs: [sandbox, TestFlight, Play test tracks]

TASK:
Create an implementation plan with:

1. Product and entitlement schema
2. Purchase, restore, cancellation, refund, and grace-period flows
3. Client implementation outline for each platform
4. Server-side receipt validation and webhook strategy
5. Paywall UX states and copy guardrails
6. Error handling for interrupted purchases and stale entitlements
7. Sandbox/TestFlight/Play testing checklist
8. Monitoring and alerting for failed purchases

OUTPUT FORMAT:
- Product schema
- Purchase-flow sequence
- Client/server implementation notes
- Paywall state templates
- Server-side validation notes
- Testing scenarios

Never trust client-only purchase state for paid entitlements. Clearly separate demo code from production requirements.

Use case: When implementing monetization Best with: A model that can reason about client/server state and store edge cases Pro tip: Always implement receipt validation server-side—never trust the client

#10: Cross-Platform Strategy

The Prompt:

Act as a principal mobile architect. Recommend a cross-platform development strategy for [APP TYPE].

CONTEXT:
- App type and business goal: [why this app exists]
- Key features: [offline, camera, BLE, maps, payments, chat, video, etc.]
- Target platforms: [iOS, Android, tablets, wearables, web]
- Team expertise: [React Native, Flutter, Swift, Kotlin, web, backend]
- Timeline and release pressure: [MVP date, staged rollout, hard deadline]
- Budget/resources: [team size, design support, QA support]
- Performance requirements: [startup time, animation smoothness, battery, memory]
- Native integration needs: [SDKs, background work, permissions]
- Maintenance horizon: [months/years, expected feature velocity]

TASK:
Create a decision memo with:

1. Recommendation across React Native, Flutter, native iOS/Android, and hybrid options
2. Decision matrix with weighted criteria
3. Architecture and module boundaries
4. Shared-code strategy and platform-specific escape hatches
5. Plugin/native-module risk assessment
6. Testing, release, and observability strategy
7. Hiring and maintenance implications
8. Migration path if the team starts with one approach and outgrows it

OUTPUT FORMAT:
- Technology comparison
- Weighted decision matrix
- Architecture diagram in text
- Implementation roadmap
- Risk assessment
- Team skill requirements

Do not choose a framework only because it is popular. Tie the recommendation to the app's constraints and team reality.

Use case: When choosing cross-platform technology Best with: A reasoning model that can compare tradeoffs instead of defaulting to one stack Pro tip: Consider team expertise and long-term maintenance, not just initial speed

---

Performance and Quality Prompts (Prompts #11-14)

#11: Mobile Performance Optimization

The Prompt:

Act as a senior mobile performance engineer. Diagnose and optimize performance for [APP AREA].

CONTEXT:
- App area: [SCREEN, LIST, IMAGE LOADING, STARTUP]
- Framework: [REACT NATIVE, SWIFTUI, KOTLIN, FLUTTER]
- Current issue: [slow startup, janky scroll, memory growth, battery drain, ANR, crash]
- Measured metrics: [startup time, FPS, memory, CPU, network, crash rate, ANR rate]
- Device profile: [low-end Android, latest iPhone, tablet, emulator, real device]
- Data size: [number of rows/images/messages/items]
- Current implementation: [paste relevant code or describe architecture]
- Target: [what good looks like]
- Constraints: [no new dependencies, must preserve design, deadline]

TASK:
Create a performance plan with:

1. Likely root causes ranked by probability and impact
2. Measurements needed before changing code
3. Code-level optimization recommendations
4. Platform/framework-specific tools to verify the issue
5. Before/after benchmark targets
6. Regression test strategy
7. Tradeoffs and risks for each optimization
8. A rollback plan if the change hurts UX

OUTPUT FORMAT:
- Root cause analysis
- Code optimization examples
- Performance metrics
- Testing checklist
- Verification plan

Do not guess blindly. If metrics are missing, first propose the minimum measurement plan.

Use case: When fixing performance issues Best with: A model that can inspect code and connect symptoms to measurement Pro tip: Measure first, optimize second—guessing wastes time

Pair this with our Cursor AI tutorial to streamline your mobile development workflow.

#12: Mobile Accessibility Audit

The Prompt:

Act as a senior mobile accessibility engineer. Audit and remediate accessibility issues for [APP/FLOW/SCREEN].

CONTEXT:
- Framework: [REACT NATIVE, SWIFTUI, KOTLIN, FLUTTER]
- Audit scope: [FULL APP, SPECIFIC FLOW]
- Target platforms: [iOS, Android, both]
- Accessibility target: [WCAG level if applicable, internal standard, legal requirement]
- Assistive tech: [VoiceOver, TalkBack, Switch Control, Voice Control, dynamic text]
- Screens/flows included: [onboarding, checkout, login, settings, etc.]
- Known issues: [missing labels, poor contrast, focus traps, inaccessible gestures]
- Existing code or screenshots: [paste relevant code or describe UI]
- User risk: [critical flow, payment, health/safety, account access]

TASK:
Create an accessibility audit and remediation guide with:

1. Issue inventory grouped by severity and user impact
2. Platform-specific fixes for iOS and Android
3. Code examples for labels, roles, hints, focus order, text scaling, contrast, and motion
4. Screen-reader test scripts for VoiceOver and TalkBack
5. Automated checks that complement manual testing
6. Regression test plan for future releases
7. Acceptance criteria for each fix

OUTPUT FORMAT:
- Audit checklist
- Issue descriptions with fixes
- Code examples
- Testing guide
- Automation approach
- Acceptance criteria

Do not treat automated checks as sufficient. Include manual assistive-technology testing.

Use case: When ensuring app accessibility Best with: A model that can reason from user impact to code changes Pro tip: Test with real screen readers—not just automated tools

For WCAG guidelines, see the W3C Web Accessibility Initiative Quick Reference.

#13: Deep Link Configuration

The Prompt:

Act as a senior mobile linking engineer. Design and implement deep linking for [APP].

CONTEXT:
- Link types: [Universal Links, Android App Links, custom scheme, deferred deep links]
- URL structure: [domains, paths, query params]
- Target routes: [product page, invite, reset password, content detail, checkout]
- App framework/navigation: [React Navigation, SwiftUI navigation, Android Navigation, Flutter go_router]
- Web fallback: [landing page, install page, content page]
- Auth requirements: [public route, login required, magic link]
- Attribution/analytics: [campaign params, source, medium]
- Existing domains/files: [apple-app-site-association, assetlinks.json if any]

TASK:
Create a deep-linking implementation with:

1. URL scheme and route design
2. iOS associated domains and Android asset links setup
3. App-side routing code for the selected framework
4. Auth, expired-link, and fallback behavior
5. Deferred-deep-link options and tradeoffs if needed
6. Analytics events without leaking sensitive token data
7. Test matrix for fresh install, app installed, logged out, expired link, and malformed link

OUTPUT FORMAT:
- URL structure definition
- Platform configuration
- Code implementation
- Testing checklist
- Failure-mode handling

Do not put secrets or long-lived auth tokens in deep-link URLs. Recommend short-lived tokens and server validation for sensitive flows.

Use case: When implementing deep linking Best with: A model that can connect platform config to app routing Pro tip: Use a library like Branch or Adjust for production apps

#14: Biometric Authentication

The Prompt:

Act as a senior mobile security engineer. Design biometric authentication for [APP/FLOW].

CONTEXT:
- Auth type: [Face ID, Touch ID, Android biometrics, device credential]
- Framework/platforms: [React Native, SwiftUI/native iOS, Kotlin/native Android, Flutter]
- Use case: [unlock app, approve payment, reveal sensitive data, step-up auth]
- Security level: [low, medium, high]
- Fallback: [password, PIN, passkey, device credential, no fallback]
- Token/session model: [JWT, refresh token, secure enclave/keychain/keystore, backend session]
- Compliance: [SOC2, HIPAA, PCI, internal security standard]
- Threats to consider: [stolen device, replay, rooted/jailbroken device, shoulder surfing]

TASK:
Create a secure biometric implementation with:

1. Biometric availability and enrollment checks
2. Authentication flow and fallback behavior
3. Secure storage strategy using Keychain/Keystore or platform equivalent
4. Session timeout, lockout, and re-authentication rules
5. Error handling for cancel, lockout, no enrollment, changed biometrics, and device unsupported
6. Code examples for the selected stack
7. Test cases and security review checklist
8. Clear separation between local unlock and server-side authorization

OUTPUT FORMAT:
- Code implementation
- Security considerations
- Error handling guide
- Testing cases
- Threat model notes

Do not store raw biometric data. Do not imply biometrics replace server-side authorization for sensitive actions.

Use case: When adding biometric authentication Best with: A model that can reason about security boundaries, not just UI APIs Pro tip: Always have fallback—biometrics can fail or be unavailable

---

Specialized Development Prompts (Prompts #15-16)

#15: React Native Bridge Native Module

The Prompt:

Act as a senior React Native native-module engineer. Design a bridge for [NATIVE CAPABILITY] with minimal, maintainable native code.

CONTEXT:
- Native capability: [camera feature, Bluetooth, sensor, secure storage, SDK integration, etc.]
- React Native architecture: [old bridge, TurboModule, Fabric, unsure]
- iOS implementation language: [Swift, Objective-C]
- Android implementation language: [Kotlin, Java]
- Data crossing the boundary: [primitive values, objects, streams, files, binary data]
- Threading requirements: [main thread, background queue, long-running operation]
- Permission requirements: [camera, location, Bluetooth, notifications, etc.]
- Existing native SDKs: [names and versions]
- Error model: [error codes, retryable vs fatal, user-facing messages]

TASK:
Create a native module plan and implementation with:

1. TypeScript API that is small and stable
2. iOS native implementation
3. Android native implementation
4. Permission handling and platform capability checks
5. Threading and memory-safety notes
6. Error mapping from native errors to JS errors
7. Usage example in React Native
8. Unit/integration test strategy and manual test matrix
9. Build/configuration steps

OUTPUT FORMAT:
- iOS module code
- Android module code
- TypeScript definitions
- Usage documentation
- Build and testing notes

Keep the bridge thin. Put complex platform behavior in native code and expose a small, predictable JavaScript API.

Use case: When accessing native capabilities Best with: A model that can reason across JavaScript, iOS, and Android boundaries Pro tip: Keep bridging code minimal—complex logic belongs in native apps

#16: Mobile App Security Hardening

The Prompt:

Act as a senior mobile security architect. Create a security hardening plan for [APP TYPE].

CONTEXT:
- App type: [CONSUMER, B2B, FINANCIAL, HEALTH]
- Platforms/frameworks: [iOS, Android, React Native, Flutter, native]
- Security requirements: [SOC2, HIPAA, PCI, internal policy, app-store rules]
- Current security: [WHAT'S ALREADY DONE]
- Data handled: [PII, PAYMENT, HEALTH DATA]
- Attack surface: [EXPOSURE POINTS]
- Auth/session model: [OAuth, JWT, passkeys, refresh tokens, SSO]
- Backend/API assumptions: [TLS, certificate pinning, API gateway, rate limits]
- Device-risk concerns: [root/jailbreak, tampering, screenshots, debug builds]
- Release process: [CI/CD, signing, secrets handling, crash reporting]

TASK:
Create a hardening plan with:

1. Threat model with likely attackers and assets to protect
2. Data storage and encryption strategy
3. Token/session handling and secure logout
4. Network security recommendations
5. Build/release hardening, signing, and secret-management checks
6. Root/jailbreak/tamper detection tradeoffs
7. Privacy and logging rules to avoid leaking sensitive data
8. Security testing plan, including static analysis, dynamic testing, and manual abuse cases
9. Prioritized roadmap: now, next, later

OUTPUT FORMAT:
- Security checklist
- Implementation code
- Configuration examples
- Testing scenarios
- Audit guidance
- Prioritized remediation roadmap

Do not promise perfect security. Label each recommendation by risk reduction, implementation cost, and possible UX impact.

Use case: When hardening app security Best with: A model that can reason about threat modeling and implementation tradeoffs Pro tip: Security is layered—don’t rely on any single measure

---

Quick Reference: Mobile Development Prompts

#	Prompt	Use Case	Best Output To Request
1	React Native Component	Reusable UI components	Component code + tests + accessibility checklist
2	SwiftUI View	iOS native components	View code + previews + version-specific notes
3	Kotlin Android Module	Android native code	Kotlin implementation + DI wiring + lifecycle notes
4	Flutter Widget	Cross-platform widgets	Widget code + usage + widget tests
5	Mobile UI Patterns	Common UX patterns	State table + component code + edge cases
6	App Store Optimization	App store visibility	Metadata drafts + screenshot storyboard + test plan
7	Mobile Analytics Setup	Tracking implementation	Event taxonomy + privacy checklist + QA plan
8	Push Notification Campaign	Engagement strategy	Message matrix + timing rules + suppression rules
9	In-App Purchase Guide	Monetization	Purchase flow + validation strategy + test scenarios
10	Cross-Platform Strategy	Technology selection	Decision matrix + roadmap + risk assessment
11	Performance Optimization	Speed improvements	Measurement plan + code changes + verification checklist
12	Mobile Accessibility Audit	Accessibility compliance	Issue list + fixes + manual test scripts
13	Deep Link Configuration	Linking strategy	URL design + platform config + failure-mode tests
14	Biometric Authentication	Security feature	Auth flow + secure storage + threat notes
15	React Native Bridge	Native capabilities	Native code + TypeScript API + build notes
16	Security Hardening	Security improvements	Threat model + prioritized remediation roadmap

---

Common Mistakes (And How to Avoid Them)

AI-generated mobile code usually fails in predictable places: trust, platform fit, accessibility, and real-device behavior. Treat these mistakes as a pre-merge checklist before shipping AI-assisted mobile work.

Mistake #1: Blindly Using AI Code

What it looks like: Generated code gets copied into the app without checking dependencies, data flow, security assumptions, or failure states.

How to avoid it: Review every import, permission, API call, and platform version before committing. Ask the AI to list assumptions, edge cases, and risky shortcuts, then verify those points manually.

Why it fails: AI can generate plausible code that compiles but still includes deprecated APIs, weak security choices, performance problems, or missing error handling.

Mistake #2: Ignoring Platform Conventions

What it looks like: One shared UI pattern gets forced across iOS and Android even when navigation, gestures, permissions, notifications, or form controls should behave differently.

How to avoid it: Ask for platform-specific behavior in the prompt, then verify the result against Apple Human Interface Guidelines and Material Design expectations. Keep shared code for business logic, not for every interaction detail.

Why it fails: Cross-platform code that ignores conventions feels wrong to users.

Mistake #3: Skipping Accessibility

What it looks like: Components ship without accessible labels, focus order, Dynamic Type support, contrast checks, reduced-motion handling, or screen-reader testing.

How to avoid it: Add accessibility requirements directly to every component prompt. Require labels, roles, hints, text scaling, focus behavior, and VoiceOver/TalkBack test steps in the output.

Why it fails: Accessibility is structural. Retrofitting it later often means redesigning layout, state handling, and interaction patterns.

Mistake #4: Not Testing on Real Devices

What it looks like: A feature works in the simulator, then fails on physical devices because of performance, camera behavior, biometrics, push notifications, battery impact, or network variability.

How to avoid it: Use simulators for fast iteration, then verify release candidates on real iOS and Android devices. Include low-end Android hardware when performance, camera, maps, Bluetooth, or background work matters.

Why it fails: Real devices reveal issues simulators don’t catch.

Pre-merge checklist:

Check	What to verify
Architecture	The generated code fits the app’s existing state, navigation, and module boundaries
Security	Secrets, tokens, permissions, and storage choices are reviewed manually
Platform behavior	iOS and Android interactions follow native expectations
Accessibility	Screen readers, text scaling, focus, contrast, and reduced motion are covered
Real-device QA	The feature works on physical devices before release

The bottom line: AI accelerates mobile development, but quality still depends on architecture review, platform judgment, accessibility testing, and real-device QA.

---

Frequently Asked Questions

Q: Which cross-platform framework is best in 2026?

React Native and Flutter both have strong ecosystems. React Native feels closer to native. Flutter offers more consistent UI. Choose based on team expertise and specific app needs.

Q: Can AI help with app store rejection?

Yes. AI can help you understand rejection reasons and draft appeals. But understand the guidelines first—AI can’t fix fundamental policy violations.

Q: How do I keep up with platform updates?

Follow Apple’s WWDC sessions and Google’s I/O announcements. Major changes come yearly—AI can help you understand new APIs quickly.

Q: Should I use AI for code reviews?

Yes, as a first pass. AI can catch style issues and common bugs. But human review is still essential for architecture and logic.

Q: How do I handle deprecated APIs?

AI often suggests deprecated patterns. Check documentation before implementing. When AI mentions an API, verify it’s current.

Learn more about building agent systems with our AI agent code patterns guide

---

Conclusion

We covered 16 battle-tested prompts for mobile development:

• Component prompts (#1-5) build UI elements
• Architecture prompts (#6-10) handle integrations
• Quality prompts (#11-14) ensure performance and accessibility
• Specialized prompts (#15-16) handle advanced needs

The reality check: AI can write 50% of your boilerplate code, but you still own the architecture, security, and quality.

Key takeaways:

• Review all AI-generated code
• Respect platform conventions
• Build accessibility in from the start
• Test on real devices

My final advice: Use AI for what it’s good at—boilerplate, patterns, syntax—and keep architecture decisions for yourself.

Stay current by following platform updates and testing new APIs. And remember: the best mobile developers use AI as a tool, not a replacement.

Hot take one more time: The mobile developer of 2026 isn’t someone who writes more code—it’s someone who architects better and leverages AI to execute faster.

---

Ready to level up? Explore our best AI agent frameworks compared to expand your toolkit. Deepen your understanding with our guide to AI function calling snippets.