| layout | title | permalink |
|---|---|---|
page |
FAQ |
/faq/ |
- Placeholder for TOC {:toc}
Flutter is Google’s mobile app SDK for crafting high-quality native experiences on iOS and Android in record time. Flutter works with existing code, is used by developers and organizations around the world, and is free and open source.
For users, Flutter makes beautiful app UIs come to life.
For developers, Flutter lowers the bar to entry for building mobile apps. It speeds up development of mobile apps and reduces the cost and complexity of app production across iOS and Android.
For designers, Flutter helps deliver the original design vision, without loss of fidelity or compromises. It also acts as a productive prototyping tool.
Flutter is for developers that want a faster way to build beautiful mobile apps, or a way to reach more users with a single investment.
Flutter is also for engineering managers that need to lead mobile development teams. Flutter allows eng managers to create a single mobile app dev team, unifying their development investments to ship more features faster, ship the same feature set to iOS and Android at the same time, and lower maintenance costs.
While not the initial target audience, Flutter is also for designers that want their original design visions delivered consistently, with high fidelity, to all users on mobile.
Fundamentally, Flutter is for users that want beautiful apps, with delightful motion and animation, and UIs with character and an identity all their own.
Flutter is approachable to programmers familiar with object-oriented concepts (classes, methods, variables, etc) and imperative programming concepts (loops, conditionals, etc).
No prior mobile experience is required in order to learn and use Flutter.
We have seen people with very little programming experience learn and use Flutter for prototyping and app development.
Flutter is optimized for 2D mobile apps that want to run on both Android and iOS.
Apps that need to deliver brand-first designs are particularly well suited for Flutter. However, apps that need to look like stock platform apps can also be built with Flutter.
You can build full-featured apps with Flutter, including camera, geolocation, network, storage, 3rd-party SDKs, and more.
Flutter is an open source project, with contributions from Google and the community.
Google uses Flutter to build business-critical apps for iOS and Android. For example, Google's mobile sales tool app is built with Flutter, along with a Store Manager app for Google Shopping Express. Other Flutter apps are in the works, or "inside the firewall".
Teams outside of Google are also using Flutter. For example, the official app for the musical Hamilton (Android, iOS) is built with Flutter.
Flutter is different than most other options for building mobile apps because Flutter uses neither WebView nor the OEM widgets that shipped with the device. Instead, Flutter uses its own high-performance rendering engine to draw widgets.
In addition, Flutter is different because it only has a thin layer of C/C++ code. Flutter implements most of its system (compositing, gestures, animation, framework, widgets, etc) in Dart (a modern, terse, object-oriented language) that developers can easily approach read, change, replace, or remove. This gives developers tremendous control over the system, as well as significantly lowers the bar to approachability for the majority of the system.
Flutter is still being developed and is not yet at 1.0. But Flutter is used inside of Google and apps built with Flutter are deployed to users in production. A few sample apps are shown in the showcase.
Some key features are not yet complete, however features that are completed are generally of high-quality and ready for use.
Our APIs are stabilizing, and we continue to improve parts of the system based on user feedback. We email [email protected] when we make a change that might impact our users.
So really, it is up to you. The features you need may be available today. Please let us know if you released an app built with Flutter to users. We'd love to hear what you're building!
- Heavily optimized, mobile-first 2D rendering engine with excellent support for text
- Modern react-style framework
- Rich set of widgets for Android and iOS
- APIs for unit and integration tests
- Interop and plugin APIs to connect to the system and 3rd-party SDKs
- Headless test runner for running tests on Windows, Linux, and Mac
- Command-line tools for creating, building, testing, and compiling your apps
We are building plugins for Android Studio, IntelliJ IDEA, and VS Code.
See editor configuration for setup details, and 'Developing Flutter apps in an IDE' for tips on how to use the plugins.
Alternatively, you can use a combination of the flutter command in a terminal
and one of the many editors that support editing Dart.
Yes! Flutter ships with a modern framework, inspired by React. Flutter's framework is designed to be layered and customizable (and optional). Developers can choose to use only parts of the framework, or a different framework.
Yes! Flutter ships with a set of high quality Material Design and Cupertino (iOS-style) widgets, layouts, and themes. Of course, these widgets are only a starting point. Flutter is designed to make it easy to create your own widgets, or customize the existing widgets.
Yes! The Flutter and Material teams collaborate closely, and Material Theming is fully supported. A number of examples of this are shown in the MDC-103 Flutter: Material Theming codelab.
Yes, Flutter provides APIs for writing unit and integration tests. Learn more about testing with Flutter.
We use our own testing capabilities to test our SDK. We measure our test coverage on every commit.
Not at this time. Please share your ideas at [email protected].
Flutter is built with C, C++, Dart, and Skia (a 2D rendering engine). See this architecture diagram for a better picture of the main components.
The engine's C/C++ code is compiled with Android's NDK, and any Dart code is AOT-compiled into native code. The app runs using the native instruction set (no interpreter is involved).
The engine's C/C++ code is compiled with LLVM, and any Dart code is AOT-compiled into native code. The app runs using the native instruction set (no interpreter is involved).
No. Instead, Flutter provides a set of widgets (including Material Design and Cupertino (iOS-styled) widgets), managed and rendered by Flutter's framework and engine. You can browse a catalog of Flutter's widgets.
We are hoping the end-result will be higher quality apps. If we reused the OEM widgets, the quality and performance of Flutter apps would be limited by the quality of those widgets.
In Android, for example, there's a hard-coded set of gestures and fixed rules for disambiguating them. In Flutter, you can write your own gesture recognizer that is a first-class participant in the gesture system. Moreover, two widgets authored by different people can coordinate to disambiguate gestures.
Modern app design trends point towards designers and users wanting more motion-rich UIs and brand-first designs. In order to achieve that level of customized, beautiful design, Flutter is architectured to drive pixels instead of the OEM widgets.
By using the same renderer, framework, and set of widgets, we make it easier to publish for both iOS and Android concurrently, without having to do careful and costly planning to align two separate codebases and feature sets.
By using a single language, a single framework, and a single set of libraries for all of your UI (regardless if your UI is different for each mobile platform or largely consistent), we also aim to help lower app development and maintenance costs.
The Flutter team watches the adoption and demand for new mobile widgets from iOS and Android, and aims to work with the community to build support for new widgets. This work may come in the form of lower-level framework features, new composable widgets, or new widget implementations.
Flutter's layered architecture is designed to support numerous widget libraries, and we encourage and support the community in building and maintaining widget libraries.
Flutter's interop and plugin system is designed to allow developers to access new mobile OS features and capabilities immediately. Developers don't have to wait for the Flutter team to expose the new mobile OS capability.
Flutter supports development on Linux, Mac, and, Windows.
We looked at a lot of languages and runtimes, and ultimately adopted Dart for the framework and widgets. The underlying graphics framework and the Dart virtual machine are implemented in C/C++.
Flutter used four primary dimensions for evaluation, and considered the needs of framework authors, developers, and end users. We found some languages met some requirements, but Dart scored highly on all of our evaluation dimensions and met all our requirements and criteria.
Dart runtimes and compilers support the combination of two critical features for Flutter: a JIT-based fast development cycle that allows for shape changing and stateful hot reloads in a language with types, plus an Ahead-of-Time compiler that emits efficient ARM code for fast startup and predictable performance of production deployments.
In addition, we have the opportunity to work closely with the Dart community, which is actively investing resources in improving Dart for use in Flutter. For example, when we adopted Dart, the language did not have an ahead-of-time toolchain for producing native binaries, which is instrumental in achieving predictable, high performance, but now the language does because the Dart team built it for Flutter. Similarly, the Dart VM has previously been optimized for throughput but the team is now optimizing the VM for latency, which is more important for Flutter’s workload.
Dart scores highly for us on the following primary criteria:
-
Developer productivity. One of Flutter's main value propositions is that it saves engineering resources by letting developers create apps for both iOS and Android with the same codebase. Using a highly productive language accelerates developers further and makes Flutter more attractive. This was very important to both our framework team as well as our developers. The majority of Flutter is built in the same language we give to our users, so we need to stay productive at 100k's lines of code, without sacrificing approachability or readability of the framework and widgets for our developers.
-
Object-orientation. For Flutter, we want a language that's suited to Flutter's problem domain: creating visual user experiences. The industry has multiple decades of experience building user interface frameworks in object-oriented languages. While we could use a non-object-oriented language, this would mean reinventing the wheel to solve several hard problems. Plus, the vast majority of developers have experience with object-oriented development, making it easier to learn how to develop with Flutter.
-
Predictable, high performance. With Flutter, we want to empower developers to create fast, fluid user experiences. In order to achieve that, we need to be able to run a significant amount of end-developer code during every animation frame. That means we need a language that both delivers high performance and delivers predictable performance, without periodic pauses that would cause dropped frames.
-
Fast allocation. The Flutter framework uses a functional-style flow that depends heavily on the underlying memory allocator efficiently handling small, short-lived allocations. This style was developed in languages with this property and does not work efficiently in languages that lack this facility.
Flutter should be able to run most Dart code that does not import (transitively, or directly) dart:mirrors or dart:html.
In June 2017, we measured the size of a minimal Flutter app
(no Material Components, just a single Center widget, built with
flutter build apk), bundled and
compressed as a release APK, to be approximately 6.7MB.
For this simple app, the core engine is approximately 3.3MB (compressed), the framework + app code is approximately 1.25MB (compressed), the LICENSE file (contained in app.flx) is 55k (compressed), necessary Java code (classes.dex) is 40k (compressed), and there is approximately 2.1MB of (compressed) ICU data.
Of course, YMMV, and we recommend that you measure your own app,
by running flutter build apk and looking at app/outputs/apk/app-release.apk.
You can expect excellent performance. Flutter is designed to help developers easily achieve a constant 60fps. Flutter apps run via natively compiled code – no interpreters are involved. This means Flutter apps start quickly.
Flutter implements a hot reload developer cycle. You can expect sub-second reload times, on a device or an emulator/simulator.
Flutter's hot reload is stateful, which means the app state is retained after a reload. This means you can quickly iterate on a screen deeply nested in your app, without starting from the home screen after every reload.
Hot Reload works by injecting updated source code files into the running Dart VM (Virtual Machine). This includes not only adding new classes, but also adding methods and fields to existing classes, and changing existing functions. A few types of code changes cannot be hot reloaded though:
- Global variable initializers.
- Static field initializers.
- The
main()method of the app.
See Using Hot Reload for additional details.
You can compile and deploy your Flutter app to iOS and Android.
Mobile operating systems: Android Jelly Bean, v16, 4.1.x or newer, and iOS 8 or newer.
Mobile hardware: iOS devices (iPhone 4S or newer) and ARM Android devices.
Note Flutter currently does not support building for x86 Android (issue #9253) directly, however apps built for ARMv7 or ARM64 run fine (via ARM emulation on many x86 Android devices.
We support developing Flutter apps with Android and iOS devices, as well as with Android emulators and the iOS simulator.
We test on a variety of low-end to high-end phones but we don't yet have an official device compatibility guarantee.
We do not test on tablets, so there may be issues with some widgets on tablets. We have not implemented tablet-specific adaptations in our widgets.
No. We are not working to provide a web version of Flutter.
We are focused on mobile-first use cases. However, Flutter is open source and we encourage the community to use Flutter in a variety of interesting ways.
Yes, you can embed a Flutter view in your existing Android or iOS app, however our tooling is currently not fully optimized for this use case (see this issue for details).
Two current demonstrations of this are the platform_view and flutter_view examples. Some initial documentation is available in the wiki page Add Flutter to existing apps.
Yes. Flutter gives developers out-of-the-box access to some platform-specific services and APIs from the operating system. However, we want to avoid the "lowest common denominator" problem with most cross-platform APIs, so we do not intend to build cross-platform APIs for all native services and APIs.
A number of platform services and APIs have ready-made packages available in the Pub repository. Using an existing package is easy.
Finally, we encourage developers to use Flutter's asynchronous message passing system to create your own integrations with platform and third-party APIs. Developers can expose as much or as little of the platform APIs as they need, and build layers of abstractions that are a best fit for their project.
Absolutely. Flutter's widget system was designed to be easily customizable.
Rather than having each widget provide a large number of parameters, Flutter embraces composition. Widgets are built out of smaller widgets that you can reuse and combine in novel ways to make custom widgets. For example, rather than subclassing a generic button widget, RaisedButton combines a Material widget with a GestureDetector widget. The Material widget provides the visual design and the GestureDetector widget provides the interaction design.
To create a button with a custom visual design, you can combine widgets that implement your visual design with a GestureDetector, which provides the interaction design. For example, CupertinoButton follows this approach and combines a GestureDetector with several other widgets that implement its visual design.
Composition gives you maximum control over the visual and interaction design of your widgets while also allowing a large amount of code reuse. In the framework, we've decomposed complex widgets to pieces that separately implement the visual, interaction, and motion design. You can remix these widgets however you like to make your own custom widgets that have full range of expression.
You can choose to implement different app layouts for iOS and Android. Developers are free to check the mobile OS at runtime and render different layouts, though we find this practice to be rare.
More and more, we see mobile app layouts and designs evolving to be more brand-driven and unified across platforms. This implies a strong motivation to share layout and UI code across iOS and Android.
The brand identity and customization of the app's aesthetic design is now becoming more important than strictly adhering to traditional platform aesthetics. For example, app designs often require custom fonts, colors, shapes, motion, and more in order to clearly convey their brand identity.
We also see common layout patterns deployed across iOS and Android. For example, the "bottom nav bar" pattern can now be naturally found across iOS and Android. There seems to be a convergence of design ideas across mobile platforms.
Yes, Flutter supports calling into the platform, including integrating with Java or Kotlin
code on Android, and ObjectiveC or Swift code on iOS. This is enabled via a
flexible message passing style where a Flutter app may send and receive messages
to the mobile platform using a
BasicMessageChannel.
Learn more about accessing platform and third-party services in Flutter with platform channels.
Here is an example project that shows how to use a platform channel to access battery state information on iOS and Android.
Not at this time. Because Flutter apps are pre-compiled for iOS, and binary size is always a concern with mobile apps, we disabled dart:mirrors. We are curious what you might need reflection/mirrors for – please let us know at [email protected].
Learn more about i18n and l10n in the Flutter Internationalization Tutorial.
Learn more about a11y in the accessibility documentation.
Flutter supports isolates. Isolates are separate heaps in Flutter's VM, and they are able to run in parallel (usually implemented as separate threads). Isolates communicate by sending and receiving asynchronous messages. Flutter does not currently have a shared-memory parallelism solution, although we are evaluating solutions for this.
Check out an example of using isolates with Flutter.
Running code in the background has platform-specific APIs due to fundamental differences in the support for background execution on each of the for Android and iOS platforms.
On Android, the android_alarm_manager
plugin enables you to run Dart code in the background, even when your Flutter
app is not in the foreground.
On iOS we currently do not support this capability. Please keep an eye on bug 6192 for updates.
Absolutely. There are libraries in pub.dartlang.org for JSON, XML, protobufs, and many other utilities and formats.
For a detailed writeup on using JSON with Flutter, check out the JSON tutorial.
Today we don't support for 3D via OpenGL ES or similar. We have long-term plans to expose an optimized 3D API, but right now we're focused on 2D.
Usually, assets including images, sound files, fonts, etc, are the bulk of an APK or IPA. Various tools in the Android and iOS ecosystems can help you understand what's inside of your APK or IPA.
Also, be sure to create a release build of your APK or IPA with the Flutter tools. A release build is usually much smaller than a debug build.
Learn more about creating a release build of your Android app, and creating a release build of your iOS app.
We have seen Flutter apps run on some Chromebooks. We are tracking issues related to running Flutter on Chromebooks.
Putting a Widget build(BuildContext context) method on State
rather putting a Widget build(BuildContext context, State state)
method on StatefulWidget gives developers more flexibility when
subclassing StatefulWidget. You can read a more
detailed discussion on the API docs for State.build.
Flutter UIs are built with an imperative, object-oriented language (Dart, the same language used to build Flutter's framework). Flutter does not ship with a declarative markup.
We found that UIs dynamically built with code allow for more flexibility. For example, we have found it difficult for a rigid markup system to express and produce customized widgets with bespoke behaviours.
We have also found that our "code-first" better allows for features like hot reload and dynamic environment adaptations.
It is possible to create a custom language that is then converted to widgets on the fly. Because build methods are "just code", they can do anything, including interpreting markup and turning it into widgets.
By default flutter run command uses the debug build configuration.
The debug configuration runs your Dart code in a VM (Virtual Machine) enabling a fast development cycle with hot reload (release builds are compiled using the standard Android and iOS toolchains).
The debug configuration also checks all asserts, which helps you catch errors
early during development, but imposes a runtime cost. The "Debug" banner
indicates that these checks are enabled. You can run your app without these
checks by using either the --profile or --release flag to flutter run.
If you are using the Flutter plugin for IntelliJ, you can launch the app in profile or release mode using the menu entries Run > Flutter Run in Profile Mode or Release Mode.
Flutter is a multi-paradigm programming environment. Many programming techniques developed over the past few decades are used in Flutter. We use each one where we believe the strengths of the technique make it particularly well-suited. In no particular order:
-
Composition: The primary paradigm used by Flutter is that of using small objects with narrow scopes of behavior, composed together to obtain more complicated effects. Most widgets in the Flutter widget library are built in this way. For example, the Material FlatButton class is built using a MaterialButton class, which itself is built using an IconTheme, an InkWell, a Padding, a Center, a Material, an AnimatedDefaultTextStyle, and a ConstrainedBox. The InkWell is built using a GestureDetector. The Material is built using an AnimatedDefaultTextStyle, a NotificationListener, and an AnimatedPhysicalModel. And so on. It's widgets all the way down.
-
Functional programming: Entire applications can be built with only StatelessWidgets, which are essentially functions that describe how arguments map to other functions, bottoming out in primitives that compute layouts or paint graphics. (Such applications can't easily have state, so are typically non-interactive.) For example, the Icon widget is essentially a function that maps its arguments (color, icon, size) into layout primitives. Additionally, heavy use is made of immutable data structures, including the entire Widget class hierarchy as well as numerous supporting classes such as Rect and TextStyle. On a smaller scale, Dart's Iterable API, which makes heavy use of the functional style (map, reduce, where, etc), is frequently used to process lists of values in the framework.
-
Event-driven programming: User interactions are represented by event objects that are dispatched to callbacks registered with event handlers. Screen updates are triggered by a similar callback mechanism. The Listenable class, which is used as the basis of the animation system, formalises a subscription model for events with multiple listeners.
-
Class-based object-orientated programming: Most of the APIs of the framework are built using classes with inheritance. We use an approach whereby we define very high-level APIs in our base classes, then specialise them iteratively in subclasses. For example, our render objects have a base class (RenderObject) that is agnostic regarding the coordinate system, and then we have a subclass (RenderBox) that introduces the opinion that the geometry should be based on the Cartesian coordinate system (x/width and y/height).
-
Prototype-based object-orientated programming: The ScrollPhysics class chains instances to compose the physics that apply to scrolling dynamically at runtime. This lets the system compose, for example, paging physics with platform-specific physics, without the platform having to be selected at compile time.
-
Imperative programming: Straightforward imperative programming, usually paired with state encapsulated within an object, is used where it provides the most intuitive solution. For example, tests are written in an imperative style, first describing the situation under test, then listing the invariants that the test must match, then advancing the clock or inserting events as necessary for the test.
-
Reactive programming: The widget and element trees are sometimes described as reactive, because new inputs provided in a widget's constructor are immediately propagated as changes to lower-level widgets by the widget's build method, and changes made in the lower widgets (e.g., in response to user input) propagate back up the tree via event handlers. Aspects of both functional-reactive and imperative-reactive are present in the framework, depending on the needs of the widgets. Widgets with build methods that consist of just an expression describing how the widget reacts to changes in its configuration are functional reactive widgets (e.g., the Material Divider class). Widgets whose build methods construct a list of children over several statements, describing how the widget reacts to changes in its configuration, are imperative reactive widgets (e.g., the Chip class).
-
Declarative programming: The build methods of widgets are often a single expression with multiple levels of nested constructors, written using a strictly declarative subset of Dart. Such nested expressions could be mechanically transformed to or from any suitably expressive markup language. For example, the UserAccountsDrawerHeader widget has a long build method (20+ lines), consisting of a single nested expression. This can also be combined with the imperative style to build UIs that would be harder to describe in a pure-declarative approach.
-
Generic programming: Types can be used to help developers catch programming errors early. The Flutter framework uses generic programming to help in this regard. For example, the State class is parameterized in terms of the type of its associated widget, so that the Dart analyzer can catch mismatches of states and widgets. Similarly, the GlobalKey class takes a type parameter so that it can access a remote widget's state in a type-safe manner (using runtime checking), the Route interface is parameterized with the type that it is expected to use when popped, and collections such as Lists, Maps, and Sets are all parameterized so that mismatched elements can be caught early either during analysis or at runtime during debugging.
-
Concurrent programming: Flutter makes heavy use of Futures and other asynchronous APIs. For example, the animation system reports when an animation is finished by completing a future. The image loading system similarly uses futures to report when a load is complete.
-
Constraint programming: The layout system in Flutter uses a weak form of constraint programming to determine the geometry of a scene. Constraints (e.g., for cartesian boxes, a minimum and maximum width and a minimum and maximum height) are passed from parent to child, and the child selects a resulting geometry (e.g., for cartesian boxes, a size, specifically a width and a height) that fulfills those constraints. By using this technique, Flutter can usually lay out an entire scene with a single pass.
If you think you've encountered a bug, please file it in our issue tracker. We encourage you to use Stack Overflow for "HOWTO" type questions. For discussions, please join our mailing list at [email protected].
Flutter is open source, and we encourage you to contribute. You can start by simply filing issues for feature requests and bugs in our issue tracker.
We recommend that you join our mailing list at [email protected] and let us know how you're using Flutter and what you'd like to do with it.
If you're interested in contributing code, you can start by reading our Contributing Guide and check out our list of easy starter issues.
Yes, Flutter is open source technology. You can find the project on GitHub.
Flutter includes two components: an engine that ships as a dynamically linked binary, and the Dart framework as a separate binary that the engine loads. The engine uses multiple software components with many dependencies; view the complete list here.
The framework is entirely self-contained and requires only one license.
In addition, any Dart packages you use may have their own license requirements.
There's an API to find the list of licenses you need to show:
-
If your application has a Drawer, add an AboutListTile.
-
If your application doesn't have a Drawer but does use the Material Components library, call either showAboutDialog or showLicensePage.
-
For a more custom approach, you can get the raw licenses from the LicenseRegistry.
Flutter is an open source project. Currently, the bulk of the development is done by engineers at Google. If you're excited about Flutter, we encourage you to join the community and contribute to Flutter!
We believe that:
- In order to reach every potential user, developers need to target multiple mobile platforms.
- HTML and WebViews as they exist today make it challenging to consistently hit high frame rates and deliver high-fidelity experiences, due to automatic behavior (scrolling, layout) and legacy support.
- Today, it's too costly to build the same app multiple times: it requires different teams, different code bases, different workflows, different tools, etc.
- Developers want an easier, better way to use a single codebase to build mobile apps for multiple target platforms, and they don't want to sacrifice quality, control, or performance.
We are focused on three things:
- Control - Developers deserve access to, and control over, all layers of the system. Which leads to:
- Performance - Users deserve perfectly fluid, responsive, jank-free apps. Which leads to:
- Fidelity - Everyone deserves precise, beautiful, delightful mobile app experiences.
We can't speak for Apple, but Apple's policies have changed over the years, and they have allowed apps built with systems like Flutter. We are aware of apps built with Flutter that have been reviewed and released via the App Store.
Of course, Apple is ultimately in charge of their ecosystem, but our goal is to continue to do everything we can to ensure Flutter apps can be deployed into Apple's App Store.