Skip to main content

ZERO TO STORES GUIDE

Set Up Your Project

Before You Start

Make sure you've logged into the required services like described in Guide Overview.

Tutorial Video

Video recording in progress. Available soon.

Create Your Project​

Everything starts with a simple command that launches an interactive setup process.
You'll be guided through the necessary steps to configure and generate your project with Codika.

codika create

This command runs in two phases:

  1. First, you'll go through a series of prompts to define your project configuration.
  2. Then, Codika will use that configuration to generate your Flutter app.

Next time you want to skip the interactive setup and reuse a saved configuration, you can run:

codika create -c path/to/codika.yaml

But for now, let's walk through the interactive setup step by step.

Project Identifiers​

The first step is choosing your app's identity.

  • The project name will be used to generate the Flutter project folder.
  • The app name is how your app will appear in Codika and on the CLI. You can include spaces and capitalization.
  • The organization identifier is used to uniquely identify your app in app stores. It follows the reverse domain notation (e.g. com.yourcompany).

Here's an example of what that might look like during setup:

? Enter project name ( default: My App ) QuickstartProject
? Enter app name ( default: Quickstart Project ) QuickStart Project
? Enter organization identifier ( default: com.example ) com.yourcompany

Git Configuration​

Codika can automate your repository setup using the GitHub CLI (gh).
This saves you the manual work of creating and configuring a Git repository.

During setup, you'll be asked how you'd like to configure version control:

How would you like to setup your Git repository?
❯ ◉  Create a new GitHub repository
  ◯  Enter repository URL manually
  ◯  Setup repository later

If you choose to create a GitHub repository, Codika will:

  • Use your GitHub authentication via the gh CLI
  • Let you select an organization under your GitHub account
  • Allow you to choose the repository name and visibility (private or public)
  • Set up the remote connection automatically

If you're not using GitHub or prefer to set things up yourself, you can select Enter repository URL manually and paste any valid Git URL (preferably SSH).

App assets​

Codika gives you the option to configure app visuals like the app icon and splash screen right from the start.
We use the flutter_launcher_icons and flutter_native_splash packages to handle this.

During setup, you'll be asked:

? Configure custom app icon? (Y/n) Y
? Configure custom splash screen? (Y/n) Y

Saying Yes doesn't mean you're uploading your assets now. It simply adds the necessary configuration to your project, making it easy to update visuals later using:

codika update-visuals

If you select No, Codika will skip the configuration entirely, and no default visuals will be added.

Updating App Visuals

If you select Yes, your app will start with Codika-branded visuals as placeholders. You can replace them at any time using the command above. Check out the Modify App Icon and Splash Screen guide for more.

Environment Configuration​

Codika enforces a clean separation between development and production environments.
Each environment gets its own bundle identifier and configuration,
which means you can install both versions of the app on the same device without conflict.

You'll also have the option to add a staging environment.

Staging sits between dev and prod and is ideal for final QA before releasing to users.
With Codika, adding staging is effortless, and we highly recommend it—even if you're just getting started.

Would you like to add a staging environment? Press SPACE to select/deselect.
? Additional environment:
❯ ◉  Staging

Why add a staging environment?

Use staging to test production-like builds in a safe environment before pushing to real users. It gives your team a chance to catch last-minute issues without affecting the live app.

Starter Project Selection​

Codika is built around the idea of reusable building blocks. At the core of this is the starter project—the initial Flutter app your project is based on.

If this is your first time using Codika, you'll likely only see one option: Flutter Starter, which is simply the default Flutter counter app.

? Select a starter project
❯ ◉  Flutter Starter

This minimal template is meant to get you started quickly. Later, you can replace it with your own custom setup—complete with your design system, routing logic, or preferred architecture—and generalize it into a new starter project for future use.

The Future of Starter Projects

Starter projects are the foundation of Codika's vision for a community-driven development ecosystem. While we currently only offer a Flutter starter project, our roadmap includes enabling developers to:

  • Turn your production-ready apps into reusable templates
  • Encode best practices and architectural decisions into your own starter projects
  • Share your templates within your team or with the wider community
  • Monetize your work through a marketplace—similar to Framer's model

Codika handles all the integration logic automatically, allowing you to focus on creating high-quality foundations you can reuse again and again.

Additional Components​

A mobile app is rarely just a starter template. Codika helps you add real-world features through components. Components are modular building blocks you can integrate directly into your project during setup.

For example, the Flutter Starter includes an optional Localizations component that sets up internationalization support out of the box:

? Select components to include [Press SPACE to select/deselect] :
❯ ◉  Localizations

Components go far beyond just adding code. They include everything needed to make a feature work end-to-end automatically.

Each component can include:

  • Packages
  • Assets (icons, fonts, images)
  • Routes
  • Localization strings
  • Native configuration updates
  • Initialization code
  • And more

Everything is pre-wired to work inside your Codika project, without any manual setup.

Reusable Components Built for Scale

Codika components are designed to be fully customizable, reusable, and deeply integrated. You'll be able to:

  • Create your own reusable components
  • Define dependencies between components (e.g. Notifications → Firebase)
  • Scope components to specific starter projects or architectures
  • Share them privately in your team or publicly through codika.dev

Think of it like pub.dev, but instead of small packages, you're reusing complete features, with all the wiring handled for you.

Firebase Configuration​

Codika uses the Firebase CLI and Google Cloud CLI to fully automate your Firebase setup. You'll be asked if you want to configure Firebase for your environments:

? Configure Firebase? (Y/n) Y

? How to set up Firebase for the Development ?
❯ ◉  Create new
  ◯  Link existing
  ◯  Skip Firebase setup for Development

? How to set up Firebase for the Production ?
  ◯  Create new
  ◯  Link existing
❯ ◉  Same as Development
  ◯  Skip Firebase setup for Production

With Codika, you can:

  • Create a new Firebase project directly from the CLI
  • Link to an existing project (Codika will fetch and list them for you)
  • Reuse the same Firebase project across environments using Same as Development
  • Skip Firebase for now and configure it later

If you select Link existing, Codika will list all projects from your Firebase account so you can pick one. No need to manually enter anything. Once selected, Codika handles everything:

  • Downloads and integrates the google-services files
  • Initializes your Firebase app
  • Creates a Firestore database
  • Enables the required Google APIs
  • Sets up service accounts for automated deployment

This ensures your app is Firebase-ready the moment creation finishes.

Why Firebase Matters in This Guide

Firebase will be used later to automate Play Store deployment. Codika creates a service account in your Firebase project to authenticate securely with Google Play. For this reason, we recommend that you configure Firebase now.

In some cases, it might make sense to keep things simple and use a single Firebase project across all environments (Dev, Staging, Prod). That's totally fine when you're just getting started.

Reusing a Firebase Project

You can create one Firebase project and reuse it across all environments. This keeps setup light and is ideal for prototypes or small teams. You can always add more Firebase projects later with a single command.

As your project grows, it's best to separate environments cleanly to avoid data overlap and simplify testing.

Recommended Setup for Real Apps

We suggest starting with two Firebase projects:

  • One for Prod
  • One for Dev

If you also have a Staging environment, you can initially link it to the Prod project. Later, when things scale, you can promote Staging to its own Firebase project for full separation.

Shorebird Integration​

Shorebird enables over-the-air (OTA) updates for your Flutter app. It allows you to push fixes and patches instantly—without waiting for App Store or Play Store approval.

During setup, Codika will prompt you:

? Configure Shorebird for over-the-air updates? (Y/n) Y

If you select Yes, Codika will:

  • Initialize the Shorebird project
  • Link it to your Shorebird account
  • Set up your CI/CD pipeline so you can ship patches using:
codika app patch

Shorebird is completely free to set up, and you don't have to use it right away. However, if your app isn't built with Shorebird enabled, you won't be able to use OTA updates later. There's no workaround—the feature must be baked in at build time.

That's why we strongly recommend enabling it now, even if you're unsure whether you'll need it immediately.

Required to Follow This Guide

To complete the full Zero to Stores guide—including production release automation—Shorebird must be configured during setup.

Shorebird essentially brings native hot reload to production. It's a powerful way to:

  • Ship emergency fixes without resubmitting to app stores
  • Roll out updates gradually
  • React fast to production bugs

Once it's set up, deploying a patch is as simple as using the codika app patch command.

Android Version Setup Executor​

At this stage of the setup, Codika will ask if you want to configure the android version setup executor. Executors are optional automation steps that configure your project even further. The Android Version Setup executor updates your app to meet Google Play Store requirements.

? Update Android configurations? (Y/n) Y

What actually happens?

It will update the Gradle version, Java version, NDK version, Min SDK version, Target SDK version, and Android application version. Here are the changes it will make to your android/app/build.gradle file:

- gradleVersion = '8.9'
- javaVersion = JavaVersion.VERSION_17
- ndkVersion = '27.0.12077973'
- minSdkVersion = 24
- targetSdkVersion = 34
- android Application Version = '8.7.2'

App Configuration Overview​

The app configuration part is now over. You'll see a summary of the configuration that will be used to generate your project. Press Enter to confirm the creation of your app and the CLI will start building everything for you. It should take about a minute to complete.

Run Your App​

Once Codika finishes creating your project, you can immediately run it with the pre-configured launch configurations:

Navigate to the Run and Debug panel to find these launch configurations:

  • DEV | Debug
  • DEV | Profile
  • DEV | Release
  • PROD | Debug
  • PROD | Profile
  • PROD | Release

What's Next?​

Nice work! You now have a fully set up project with multiple environments and a structured workflow.

Next, we'll configure Codemagic and Shorebird and build your first app release. Continue to setting up your app distribution pipeline. 🚀