If you have been following Flutter development, you may have noticed something quietly disappear. The current release of Android Studio — Panda 3 (2025.3.3) — lists Kotlin, Java, and C/C++ as supported languages. Flutter and Dart are gone from the page entirely. The Flutter plugin is still available through the JetBrains Marketplace, but it is no longer promoted, bundled, or even mentioned by Google. For anyone building cross-platform apps with Flutter, this is worth paying attention to — not as a reason to panic, but as a signal that the platform landscape is shifting in ways that affect your technology decisions.

Why Flutter No Longer Appears in Android Studio

This seems odd at first glance. Flutter and Android Studio are both Google products. But they were always maintained by separate teams with different mandates. Flutter sits under the Dart team and targets iOS, web, desktop, and Android. Android Studio is owned by the Android team, whose job is native Android development with Kotlin and Java. The shared Google branding made them look more unified than they actually were.

The more pointed explanation is strategic. Google has been pushing Jetpack Compose as its preferred UI framework for Android — a Kotlin-native, deeply integrated approach to building Android apps. Flutter, being cross-platform, competes with that narrative. The implicit message from Google appears to be: for native Android, use Compose; for cross-platform, Flutter exists but you manage your own tooling.

The 2024 layoffs reinforced this. Google cut a significant portion of the Flutter and Dart teams in early 2024. This was not just a headcount number — it reflected a reduced internal commitment to Flutter as a Google-strategic product. Flutter has since drifted toward being a more community-driven project, with flutter.dev increasingly positioned as its own ecosystem rather than an extension of Android Studio.

Is Flutter Actually in Trouble?

The honest answer is: probably not doomed, but the trajectory is worth watching carefully. There are real reasons for concern and real reasons it is likely to persist.

The concerning signals:

  • Significant team layoffs in 2024 are rarely a sign of growing commitment
  • Google has a well-documented history of abandoning products — Stadia, Allo, Google+, and many others
  • De-emphasis in Android Studio removes a major on-ramp for new developers
  • Reduced Google investment slows the pace of new platform feature support

The stabilising factors:

  • Flutter is embedded in production apps at major companies worldwide — it cannot simply be switched off
  • Google itself uses Flutter in production, including Google Pay
  • The Dart language and Flutter framework are open source, which means a community fork or handoff is at least plausible if Google steps back further
  • The ecosystem is large enough to sustain itself in a way a proprietary product never could

The more likely scenario is not a sudden shutdown but a gradual transition — Flutter becomes a stable, well-maintained open source project that is no longer the exciting Google-backed story it was in 2019–2022. Think less Google Wave (switched off abruptly) and more Apache Cordova (still used, still maintained, no longer the hot thing). The Flutter GitHub release cadence over the next 12–18 months will be the clearest indicator of which direction this goes.

The Bigger Risk Is Apple, Not Google

Google reducing investment is uncomfortable, but the code remains open. The more existential risk is Apple. Apple could make Flutter simply stop working on iOS, and the Flutter community would have very limited recourse.

Apple has both the means and the motive. SwiftUI is their own cross-platform UI framework for Apple platforms, and they have shown repeatedly that App Store policy can be used as a competitive tool. Flutter navigates a legal grey area in the App Store rules around interpreted code and runtime execution. Apple could tighten those rules — deliberately or as collateral damage — in a way that makes Flutter apps non-compliant.

An outright ban is unlikely in the near term. The antitrust scrutiny Apple is under, particularly in the EU, makes overtly anti-competitive moves more legally risky. There are also enormous numbers of App Store apps built with Flutter — removing them would be a significant self-inflicted wound on App Store revenue.

The subtler risk is more plausible and harder to fight. Apple could make life progressively more difficult without issuing an explicit ban — tightening API access, slowing framework approvals, or introducing new platform features that take years to get proper Flutter support. This kind of slow friction is harder to characterise as anti-competitive but has the same practical effect over time. Apple applied this exact playbook to PWAs on iOS: no outright ban, just deliberate capability limitations that made them less viable than native apps.

This is the fundamental vulnerability of any cross-platform mobile framework. You are always dependent on the goodwill of two platform owners, one of whom has strong commercial reasons to prefer you used their own tools.

What This Means for Your Tooling Today

For day-to-day Flutter development, VS Code with the Flutter and Dart extensions is now the recommended setup. It is actively maintained, aligned with Flutter SDK releases, and does not depend on where Android Studio chooses to position itself. Android Studio is still useful for specific tasks — the Android SDK Manager, AVD Manager (for emulators), and build tool configuration — but writing Flutter code is better done in VS Code.

To install the Flutter plugin in Android Studio if you still need it, go to Settings → Plugins → Marketplace and search for Flutter. It installs cleanly, but treat it as a community-maintained plugin rather than a Google-supported feature.

Should You Still Build With Flutter?

For most cross-platform business application development, Flutter remains a reasonable choice. The risk of platform dependency is real but manageable for most use cases, and there is no obviously better alternative right now. React Native has its own complications with the new architecture migration, and every other option has a smaller ecosystem and fewer production-proven deployments.

The risk to plan around is not a sudden collapse but a slow degradation — reduced Google investment leading to slower platform support, Apple introducing friction through policy or API changes, and a gradual shrinkage in the contributor community. None of these are immediate crises, but they are relevant inputs to any architecture decision with a three-to-five year horizon.

If you are evaluating mobile technology for a new project, or reviewing an existing Flutter dependency as part of a technology audit, talk to the NettSite team. We help South African businesses make these decisions with a clear picture of risk, cost, and long-term maintainability — not just what is trending on developer blogs.

Ready to build something great?

flutter mobile development cross-platform android app development platform risk