Mobile application starters · project planning pack

Mobile application starters · project planning pack

Choose a foundation for Mobile application starters with a platform brief, repository comparison, proposed tasks, acceptance criteria and the relevant Orqestria specialists.

This planning pack creates a project containing documents and assigns the recommended agents with their existing skills. It contains no external application code or installer and does not start an application. The task lists are proposals in files; no board tasks are created automatically.

Choose the target devices and first mobile journey before choosing React Native/Expo, Flutter, Android or SwiftUI. Compare reusable starting points with native reference examples, then plan permissions, offline behavior, accessibility and store delivery.

First business scenario

A person opens the app, reads and edits one useful record, briefly loses connectivity, then reconnects without silent data loss or duplicate changes. Permission refusal has a usable fallback and does not prevent unrelated actions.

Records to model

A user profile, the first domain record, local cached copies, pending changes, synchronization status, device permission choices and notifications when needed. Define conflict resolution and which data may stay on the device.

Recommended team

Orion, Finn, Mira, Otto, and Yara

Documents in this pack

Read the brief, adapt the proposed tasks to your business and agree on acceptance criteria before implementation. Add the selected tasks to your board when you are ready to begin.

• Project brief: planning/en/brief.md
• Proposed initial tasks: planning/en/proposed-tasks.md
• Acceptance criteria: planning/en/acceptance.md
• Choose and validate the application foundation: planning/en/starter-selection.md

Repositories to compare

Explore the category recommendations

• Ignite · Recommendation and scope
• Obytes React Native Starter · Recommendation and scope
• Very Good CLI · Recommendation and scope
• Now in Android · Recommendation and scope
• Clean Architecture SwiftUI · Recommendation and scope

Repository shortlist checked: Oct 25, 2026. Recheck current official sources before selecting a revision; inclusion is not a security audit or a guarantee of suitability.

Proposed initial tasks

These are suggested tasks to discuss and add to your board. Installation writes these documents into the project; it does not create work items, run external setup commands or contact the linked services.

Define scope and outcomes

Identify the users, the business outcome and what the first version excludes. Use this scenario as the initial acceptance journey: A person opens the app, reads and edits one useful record, briefly loses connectivity, then reconnects without silent data loss or duplicate changes. Permission refusal has a usable fallback and does not prevent unrelated actions.

Compare at least two foundations

Compare at least two linked repositories against the scenario and records. Separate shipped features from paid editions, add-ons and work you must build. Record a reasoned choice or why a custom build is preferable.

Verify the current upstream and dependencies

Review official source, licenses, edition terms, dependency requirements, maintenance activity and security advisories for the exact revision. Record unresolved findings and necessary changes before adopting it.

Model data and permissions

Define ownership, validation, relationships and allowed access for these records: A user profile, the first domain record, local cached copies, pending changes, synchronization status, device permission choices and notifications when needed. Define conflict resolution and which data may stay on the device. Include at least two roles and explicit denied-access cases.

Prototype the smallest complete scenario

Use representative sample data in an isolated test environment. Demonstrate the full scenario, including one invalid input and one failure or correction, before expanding the product.

Plan restoration and upgrades

Test a backup and restore of the prototype, define an upgrade and rollback approach and estimate hosting, migration, integration and maintenance effort. Record owners for operation and acceptance.

Acceptance criteria

These criteria define the first prototype's review, not completed work. Attach evidence and unresolved issues when the team evaluates each item.

• The agreed scenario is demonstrated end to end with representative records: A person opens the app, reads and edits one useful record, briefly loses connectivity, then reconnects without silent data loss or duplicate changes. Permission refusal has a usable fallback and does not prevent unrelated actions.
• At least two candidates have been compared, and the chosen revision, license and edition constraints, dependency fit and security findings are recorded with official source links.
• At least two roles have verified allowed and denied actions, with no access to another user's or organization's restricted records.
• Invalid input, a failure and a correction are handled with visible results and without unintended duplicate records or business actions.
• A backup has been restored in a test environment and the expected records and access rules have been verified.
• The team has documented an upgrade and rollback plan, known gaps, operating responsibilities and the remaining implementation work.
• The first journey is evidenced on an intended device with offline recovery, permission denial and app restart; target toolchains, generated app root if any, signing and store responsibilities are recorded.

Choose and validate the application foundation

Compare Ignite or Obytes for a React Native/Expo direction, and Very Good CLI for a Flutter direction. Check the actual supported versions and native modules against the required device features. Now in Android and Clean Architecture SwiftUI are reference applications: extract relevant patterns and replace sample-domain behavior instead of treating the whole example as your finished product.

Ignite and Very Good CLI contain generator tooling. Record the generator version, selected template and generated app root; the cloned tool repository is not the app to ship. Confirm Android SDK/JDK, Xcode/macOS and signing requirements for the selected targets, and identify skills the current team still needs.

Prove the first journey on an emulator and at least one intended physical device. Include a denied permission, offline edit/reconnect, secure storage, app restart, readable screen sizes and accessibility. Plan app identifiers, certificates, store accounts, privacy disclosures and an upgrade/data-migration path; these are separate from cloning the repository.