How to ship an app to iPhone and Android as a solo builder

You have an app idea that needs to work on both iPhone and Android. Without a coding background, the gap between that idea and a working build feels enormous. Two separate codebases, two programming languages, and two toolchains are not a realistic starting point for a solo builder.

Two paths are worth considering. The traditional route is Flutter, a framework that gives developers one codebase for multiple platforms. The newer route is Anything, an AI app builder that lets you describe an app in plain language and iterate through conversation instead of writing code. This guide covers both so you can choose the path that fits how you actually want to work.

A 2024 developer survey found Flutter was used by 9.4% of developers surveyed, edging ahead of React Native at 8.4%. That adoption matters if you plan to hire help later, but it does not change the fact that Flutter still asks you to learn a programming language, set up a toolchain, and manage two store submissions on your own.

The two paths for a solo builder

If you are building alone and need one project to cover the same core product on iOS and Android, the math favors a single approach, whether that is one codebase or one conversational builder.

Flutter supports apps across iOS, Android, web, desktop, and embedded platforms. For a solo builder targeting both the App Store and Google Play, this means writing your app logic once in Dart instead of maintaining two separate projects in two languages.

Anything takes a different approach. Instead of writing code at all, you shape the app through back-and-forth prompts. Built-in infrastructure means you can publish web apps without setting up hosting, auth, or a database first. The current product context supports iOS deployment, and Android is in development. For builders who want less setup and a faster way to test an idea, that removes most of the work this article describes below.

Speed and iteration matter more than perfection

In Flutter, Hot Reload lets you change code and see results almost instantly without losing the app's current state. The Dart SDK comes bundled with Flutter, so you do not install it separately. That is fast for a developer who already knows Dart. For a first-time builder, the slower step is learning what to type into the editor in the first place.

In Anything, iteration happens through prompts. You describe a change, see it applied, and refine. There is no SDK to install, no Dart to learn, and no widget tree to reason about before you have something running.

One asterisk you need to know before starting with Flutter

Apple's toolchain creates one hard constraint before you commit to iOS distribution with Flutter. You can develop and test Flutter code on Windows, but iOS distribution still requires macOS access for the final build step.

Publishing to the Apple App Store requires macOS and Xcode for the final compilation step. This is an Apple toolchain requirement, not a Flutter limitation. If you do not own a Mac, address this before committing to an iOS-first idea, or consider Anything, which abstracts the toolchain step away.

The Flutter setup path

If you choose Flutter, VS Code and Flutter's guided install give most beginners a straightforward path to running sample code. The goal is simple: install the SDK, check the environment, and launch a starter app on a device or simulator.

Install prerequisites

On macOS, run xcode-select --install in Terminal. On Windows, install Git for Windows. On Linux, install the required packages:

sudo apt-get update -y && sudo apt-get upgrade -y

sudo apt-get install -y curl git unzip xz-utils zip libglu1-mesa

Then download Visual Studio Code on any platform.

Install Flutter through VS Code

1. Open VS Code, go to the Extensions panel, search for "Flutter," and install it (the Dart extension installs automatically)
2. Open the Command Palette with Ctrl+Shift+P (Windows/Linux) or Cmd+Shift+P (macOS)
3. Type flutter and select "Flutter: New Project"
4. VS Code will prompt you to locate the Flutter SDK. Select "Download SDK"
5. Choose an installation folder, click "Clone Flutter," and wait for the download to finish

This workflow handles SDK download, PATH configuration, and IDE integration. It is the lightest setup path Flutter offers, and it is still several steps before you have written a single line of your own app.

Verify your environment

Run flutter doctor in your terminal. It checks your setup and flags anything missing. Resolve all flagged issues before moving forward. Then confirm available devices with flutter devices.

Create and run your first project

flutter create my_app

cd my_app

flutter run

Your project now has a lib/main.dart file where all UI code starts and a pubspec.yaml file where you add dependencies. You can ignore the rest at first.

One detail matters early: the organization name you set at project creation, for example com.yourname, becomes your Android package name and iOS Bundle ID. Per the Android Studio documentation, this can not be changed after your app is released.

By contrast, the Anything setup is a sign-in. You open the product, describe the app you want, and start iterating. There is no PATH variable, no SDK download, and no flutter doctor to debug.

Seven concepts that carry a Flutter beginner to a first build

If you go the Flutter route, a simple mental model makes the framework easier to change without guessing. The Flutter team describes Flutter's UI model as reactive: UI reflects state. A widget declares its UI by overriding the build() method, which converts state into what the user sees. Below is the short version of what you will need to learn. If any of this feels like more than you signed up for, that is a fair signal that a prompt-based builder like Anything may match your starting point better.

Everything is a widget

Flutter represents every visual element as a widget primitive. Buttons, text, padding, rows, columns, and the app itself are all widgets. You build screens by nesting widgets together. The starter widgets you will use most:

• Scaffold for page structure
• Column and Row for layout
• Text for typography
• ElevatedButton for actions
• Container for styling and spacing

Stateless versus stateful widgets

The first question for any screen is simple: does anything on this screen change? Per the official UI guide, a StatelessWidget displays information that does not change. A StatefulWidget manages data that can change, like a counter or a form field. When data changes in a stateful widget, call setState() to trigger a redraw.

Lifting state up and sharing it across screens

When multiple widgets need the same data, that data lives in their common parent widget. Changes flow up via callbacks. Current data flows down to display widgets.

Once state needs to span multiple screens, the official learning materials present Provider with ChangeNotifier as a common next step beyond setState() for shared app state. You create a class that extends ChangeNotifier, wrap your widget tree with ChangeNotifierProvider, and use Consumer in widgets that need to rebuild. Start with setState() for single-screen state. Graduate to Provider only when you genuinely need shared state.

Navigation between screens

Flutter's Navigator widget manages screens as a stack. Navigator.push() opens a new screen. Navigator.pop() returns to the previous one. For a first app with a small number of screens, push and pop usually cover everything.

The official learning pathway

Flutter's official learning materials help you stay close to current APIs. That lowers the odds of copying examples that no longer match the current toolchain.

The Flutter team published a learning path. The early steps cover installation, widgets, layout, user input, stateful widgets, state management, HTTP requests, and ChangeNotifier. The hands-on companion is a step-by-step codelab. Following this sequence is a direct route to a working app, and it is also several weeks of work before most beginners ship anything real.

What solo builders have shipped

Community examples make either path feel less abstract. The Flutter community has a long backlog of informal builder stories, and they show what is possible if you are willing to invest the time.

One solo developer described building HabitKit after learning Flutter through an online course. The developer called the early part of the Flutter journey a breeze and the cross-platform result from one codebase pretty amazing in a community thread.

Billd came from a solo freelancer who started the project with no Flutter background, as documented in a builder post. The builder described the project in pragmatic terms. The app worked on a real device and met the immediate need.

Another solo developer who released many apps with Flutter said development speed and maintainability improved dramatically compared to maintaining separate native codebases, according to a developer thread.

Taken together, these stories show the practical appeal of Flutter for builders who are willing to learn a language and toolchain. They also highlight what is absent: a path for someone who has the idea and the motivation but not the coding background. That is the gap Anything is built to close. The work of distribution and monetization is still yours, but the work of writing and configuring code is not.

Publishing to the App Store and Google Play

Store requirements create the main friction after your app works locally, no matter which path you took to build it. Anything handles parts of this for you on iOS; the rules below still apply to anyone publishing through Flutter.

Apple App Store requirements

The Apple Developer Program costs $99 per year. Organization accounts require a D-U-N-S Number. 90% of submissions clear review in under 24 hours.

A common rejection reason is completeness. Many review issues fall under Guideline 2.1, including crashes, placeholder content, and incomplete flows. Test thoroughly before submitting.

Apps must meet Apple's current SDK and Xcode submission requirements at the time you upload. Check the submission requirements before your release.

Google Play Store requirements

Registration costs $25 one-time. Personal accounts face testing requirements before distribution, which adds timeline friction for solo builders.

Service fees on paid apps and in-app purchases are 15% on the first $1M in annual revenue and 30% above that threshold. Subscriptions are generally charged a 15% service fee, though published terms include eligibility, program, and revenue-threshold conditions.

Three compliance items to track:

• New apps and app updates must target Android 15 or higher
• A Financial Features Declaration is required for apps that offer financial features
• Developer verification will be required for Android app distribution as part of a phased rollout

Outdated targets or missing declarations can block release, so confirm each item against official documentation before you prepare your final store submission.

A faster path: building with Anything

If the sections above feel like a lot of moving pieces before you have shipped anything, that is the honest cost of the traditional path. Anything was built for the builder who wants to skip most of it.

With Anything, you describe what you want, and the product builds it. You iterate by talking to it, not by editing Dart files or chasing down flutter doctor warnings. A few practical differences:

• No SDK or toolchain setup. You sign in and start. There is no Flutter install, no Xcode configuration, and no PATH variable to manage.
• No language to learn first. You do not need to internalize widgets, state management, or navigation patterns before your first screen exists.
• Infrastructure included. Web apps publish without you setting up hosting, authentication, or a database. Those layers are part of the product.
• iOS deployment supported today. The current product context supports iOS deployment. Android is in development.
• Conversational iteration. Changes happen through prompts. Your role is to describe outcomes, review them, and refine. The mental model is closer to working with a teammate than to reading framework documentation.

The tradeoff is honest. Flutter gives you total control of a native codebase, which matters if you plan to grow into a custom architecture, ship deeply specialized features, or eventually hire engineers. Anything gives you speed to a working product and removes the parts of app development that have nothing to do with your idea. For a solo builder testing whether an idea is worth building at all, that tradeoff usually favors shipping sooner.

Your first build is closer than it looks

The fastest way to learn anything in app development is to run something on a real device or in a real browser. Once you move from reading to testing, the work becomes less abstract and easier to reason about.

If you choose Flutter, the learning surface is wide. Several pieces arrive roughly at once:

• Dart syntax and idioms
• The widget tree model
• State management patterns
• iOS toolchain setup on macOS

Many first-time builders feel challenged at the start, especially around state management, architecture, and the framework's mental model. It is not a signal that you picked the wrong tool. It is a signal that traditional app development asks a lot of beginners up front.

If you go the Flutter route, start with flutter create, follow Flutter's official "Get started" path and first app guide, and begin by experimenting with the simple counter app template. A working app on a real device teaches you more than weeks of tutorial consumption.

If you would rather skip SDK setup, language learning, and toolchain debugging, try Anything, an AI app builder that lets you shape an app through back-and-forth conversation instead of writing Dart from scratch. Built-in infrastructure means you can publish web apps without setting up hosting, auth, or a database first. The current product context supports iOS deployment and notes Android is still in development. For most solo builders, especially those without a coding background, that is the shortest distance between an idea and something real you can put in front of users.