# IOS App Development > Use for cross-stack iOS product and platform decisions: select Swift, Flutter, or a mixed boundary; shape iOS architecture, native capabilities, privacy, lifecycle, integration, release, and long-term ownership. For framework-specific implementation after stack selection, use swift-skill or flutter-skill. - Skill: `bejeweledme/ios-app-development` (Agent Skill, multi-file: 17 files) - Install (CLI): `npx skillmds@latest add bejeweledme/ios-app-development` - Raw SKILL.md: https://api.skillmd.com/api/skills/bejeweledme/ios-app-development/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Integrations & APIs - Author: BejeweledMe (https://skillmd.com/u/bejeweledme) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/bejeweledme/ios-app-development --- # iOS App Development Use this skill to design, review, validate, debug, implement, or release iOS applications across Flutter, SwiftUI/native, and mixed stacks. Treat iOS quality as the product of architecture, platform constraints, state/data ownership, native integration, privacy, testing, signing/release, observability, and maintenance. ## Core Rule Do not start from framework preference. First clarify stack, target iOS versions, product/platform goals, native capabilities, data/offline needs, privacy/security constraints, performance budget, testing depth, release target, signing/CI setup, and long-term ownership. ## Hierarchy And Handoffs This is the iOS platform router and cross-stack owner. Start here when the stack is unknown, a product must choose between native and Flutter, or a decision crosses app, native integration, privacy, release, or App Store boundaries. - Choose `$swift-skill` as the implementation owner for a native iOS-only product, an Apple-framework capability, or Swift/SwiftUI/UIKit code and runtime behavior. - Choose `$flutter-skill` as the implementation owner for a Flutter product, shared cross-platform feature, Dart/UI/state/data design, or Flutter plugin integration. - Use this skill together with both specialists for a mixed app or native-plugin boundary. Keep one explicit owner for each interface and release decision. - Bring in `$qa-testing` for classic test strategy, `$system-design` for backend or distributed-service architecture, and `$sre-reliability-engineering` for operated service reliability. They do not replace platform routing here. Do not load all three skills merely because the target is iOS. After selecting the stack, use the specialist and return here only for platform-wide tradeoffs. ## Reference Routing Read only the references needed for the current task. - Always start with `references/00-overview.md` for broad design, review, stack choice, or unclear requests. - For iOS platform constraints, lifecycle, sandbox, App Store gate, device QA, and product/platform assumptions, read `references/01-ios-platform-model.md`. - For Flutter architecture, View/ViewModel, repositories, services, optional domain/use-case layer, and Flutter data boundaries, read `references/02-flutter-ios-architecture.md`. - For Swift/native architecture, SwiftUI/native layering, value/reference semantics, ARC, protocols, modules, and ownership, read `references/03-swift-native-architecture.md`. - For setup, Xcode, Flutter CLI, dependency managers, SwiftPM, CocoaPods, plugin dependency paths, and deployment target issues, read `references/04-project-setup-dependencies.md`. - For declarative UI, navigation, local/shared/persisted state, ViewModel/state ownership, and route validation, read `references/05-ui-navigation-state.md`. - For platform integration, native plugins, platform channels, AppDelegate/native setup, entitlements, camera, push, location, payments, biometrics, and Apple APIs, read `references/06-platform-integration-plugins.md`. - For networking, repositories, source of truth, cache/offline behavior, local storage, SwiftData, migrations, and sync caveats, read `references/07-networking-storage-persistence.md`. - For Dart async/isolates, Swift concurrency, actors, actor reentrancy, cancellation, lifecycle interruptions, and background work, read `references/08-concurrency-lifecycle.md`. - For permissions, Info.plist strings, Apple privacy manifests, SDK signatures, required-reason APIs, Keychain, backend trust boundaries, and client-side security, read `references/09-permissions-privacy-security.md`. - For startup, rendering, jank, memory pressure, ARC leaks, image/media costs, battery, Flutter DevTools, and Instruments-style profiling, read `references/10-performance-memory-battery.md`. - For unit/widget/UI/integration tests, real-device QA, debugging, lints, crash reporting, logs, analytics, and production observability, read `references/11-testing-debugging-observability.md`. - For signing, provisioning, Bundle ID, version/build numbers, IPA, App Store Connect, TestFlight, App Review, CI signing, and release gates, read `references/12-build-signing-release-app-store.md`. - For quick reviews and common failure modes, read `references/13-common-mistakes.md`. - For final production readiness or release reviews, read `references/14-production-checklist.md`. ## Workflow 1. Classify the request: - New app or feature design: read `00`, then stack-specific files `02` or `03`, plus `05`, `07`, `08`, `09`, `11`, and `12` as needed. - Flutter app architecture/review: read `02`, `05`, `07`, `08`, `11`, and `13`. - SwiftUI/native architecture/review: read `03`, `05`, `07`, `08`, `10`, and `13`. - Mixed Flutter/native or plugin work: read `04`, `06`, `09`, and stack-specific architecture files. - Persistence/offline/sync work: read `07`, then `08`, `09`, and the relevant stack file. - Concurrency/lifecycle/performance debugging: read `08`, `10`, and the relevant stack file. - Security/privacy review: read `09`, then `06`, `07`, `12`, and `14` if release is involved. - Test strategy or debugging: read `11`, then files matching the behavior under test. - TestFlight/App Store/release readiness: read `12`, `14`, `04`, `09`, and `11`. 2. Identify blocking unknowns. Ask only when the missing answer changes the design or release decision; otherwise state assumptions. 3. Preserve platform truth: distinguish Flutter abstractions, Swift/native behavior, and Apple ecosystem constraints. 4. Prefer the simplest architecture that preserves testability, lifecycle correctness, platform compliance, and maintainability. 5. Validate every recommendation against state ownership, source of truth, async/lifecycle behavior, privacy/security, testing, release, observability, and rollback/fallback. 6. Mark ideas not grounded in the references as `external extension` when adding them. ## Output For New App Or Feature Design Include: - Stack choice: Flutter, SwiftUI/native, UIKit/native, or mixed, with tradeoffs. - Goals, anti-goals, target iOS versions, device assumptions, and release target. - iOS platform constraints: capabilities, permissions, privacy, lifecycle, App Store risks. - Architecture layers: UI, state/ViewModel, domain/use cases if needed, repositories, services/platform adapters. - UI/navigation/state model and ownership boundaries. - Data, networking, persistence, cache/offline, migration, and source-of-truth plan. - Platform integration/plugin/native bridge plan. - Concurrency/lifecycle/cancellation/background-work plan. - Security/privacy plan, including Keychain/secrets/backend trust boundaries and Apple privacy checks. - Testing, debugging, observability, crash/error reporting, and real-device QA plan. - Build/dependencies/signing/TestFlight/App Store release plan. - Risks, assumptions, validation steps, and next actions. ## Output For Review Lead with risks and missing decisions: - Critical release/platform blockers. - Architecture and ownership problems. - State/navigation/lifecycle/concurrency risks. - Data/persistence/source-of-truth/security risks. - Native plugin/dependency/signing/privacy risks. - Testing, observability, and real-device QA gaps. - Concrete fixes and verification steps. ## Output For Release Readiness Prioritize: 1. Blocking App Store/TestFlight/signing issues. 2. Bundle ID, provisioning, certificates, version/build, IPA, and App Store Connect state. 3. Privacy labels, privacy manifests, SDK signatures, required-reason APIs, permissions, and entitlements. 4. Release-build device QA, crash/error reporting, and environment correctness. 5. Dependency manager state: SwiftPM/CocoaPods, deployment target, plugin native setup. 6. TestFlight or equivalent release-candidate validation when targeting App Store production. 7. Open risks, rollback/fallback options, owners, and follow-up checks. ## Fact-Check Guardrails - Say `as of Flutter 3.44` for SwiftPM default support unless current Flutter docs have been rechecked. - Do not say CocoaPods is removed or stops working. Say Flutter supports CocoaPods in maintenance/fallback mode and cite current docs. - Do not use Packt repo examples as current production authority. Treat them as educational code snapshots. - Do not claim SwiftUI tutorials define mandatory production architecture. - Do not claim SwiftData replaces Core Data for every app or solves migrations/sync/availability without target-specific Apple docs. - Do not conflate TestFlight with a mandatory App Store step; use it as a practical release-candidate validation gate for production. - Do not call Swift actors atomic across `await`; account for actor reentrancy. - Do not treat mobile client code as a trusted security boundary. ## Quality Bar - Do not call an iOS app production-ready without real-device QA, explicit state/data ownership, privacy/security checks, tests, observability, signing/release plan, and App Store/TestFlight readiness. - Prefer simple Flutter UI/data/domain boundaries before adding architecture layers. - Prefer Swift value types for value-like domain state and classes only when identity/reference semantics are needed. - Keep native integration isolated behind explicit adapters/services. - Tie performance advice to measurement and release/profile builds on real devices. - Keep recommendations scoped to the user's stack, target iOS versions, release target, and team constraints.