Dart is a mobile programming languages that seems destined to overthrow even Swift and Kotlin as the goto language for mobile apps. You can find a collection of the best Dart resources and tutorials from the Internet on this blog.
Flutter is Google’s portable UI toolkit for crafting beautiful, natively compiled applications for mobile, web, and desktop from a single codebase. Flutter works with existing code, is used by developers and organizations around the world, and is free and open source.
What does Flutter do?
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 platforms.
For designers, Flutter helps deliver the original design vision, without loss of fidelity or compromises. It also acts as a productive prototyping tool.
Who is Flutter for?
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.
How experienced of a programmer/developer do I have to be to use Flutter?
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.
What kinds of apps can I build with Flutter?
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.
Who makes Flutter?
Flutter is an open source project, with contributions from Google and the community.
Who uses Flutter?
Developers inside and outside of Google use Flutter to build beautiful native apps for iOS and Android. To learn about some of these apps, visit the showcase.
What makes Flutter unique?
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, concise, 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.
Should I build my next production app with Flutter?
Flutter 1.0 was launched on Dec 4th, 2018. Thousands of apps have shipped with Flutter to hundreds of millions of devices. See some sample apps in the showcase.
Alternatively, you can use a combination of the flutter command in a terminal and one of the many editors that support editing Dart.
Does Flutter come with a framework?
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.
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.
How does Flutter run my code on Android?
The engine’s C and C++ code are compiled with Android’s NDK. The Dart code (both the SDK’s and yours) are ahead-of-time (AOT) compiled into a native, ARM and x86 libraries. Those libraries are included in a “runner” Android project, and the whole thing is built into an APK. When launched, the app loads the Flutter library. Any rendering, input or event handling, and so on, is delegated to the compiled Flutter and app code. This is similar to the way many game engines work.
Debug mode builds use a virtual machine (VM) to run Dart code (hence the “debug” banner they show to remind people that they’re slightly slower) in order to enable Stateful Hot Reload.
How does Flutter run my code on iOS?
The engine’s C and C++ code are compiled with LLVM. The Dart code (both the SDK’s and yours) are ahead-of-time (AOT) compiled into a native, ARM library. That library is included in a “runner” iOS project, and the whole thing is built into an .ipa. When launched, the app loads the Flutter library. Any rendering, input or event handling, and so on, are delegated to the compiled Flutter and app code. This is similar to the way many game engines work.
Debug mode builds use a virtual machine (VM) to run Dart code (hence the “debug” banner they show to remind people that they’re slightly slower) in order to enable Stateful Hot Reload.
Does Flutter use my system’s OEM widgets?
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 hope that the end-result is 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
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, it’s 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.
What happens when my mobile OS updates and introduces new widgets?
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 might 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.
What happens when my mobile OS updates and introduces new platform capabilities?
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.
What operating systems can I use to build a Flutter app?
Flutter supports development on Linux, Mac, and, Windows.
What language is Flutter written in?
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++.
Why did Flutter choose to use Dart?
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.
Can Flutter run any Dart code?
Flutter should be able to run most Dart code that does not import (transitively, or directly) dart:mirrors or dart:html.
How big is the Flutter engine?
In July 2019, we measured the download size of a minimal Flutter app (no Material Components, just a single Center widget, built with flutter build apk --split-per-abi), bundled and compressed as a release APK, to be approximately 4.3 MB for ARM, and 4.6 MB for ARM 64.
In ARM, the core engine is approximately 3.2 MB (compressed), the framework + app code is approximately 920.6 KB (compressed), the LICENSE file is 54.3 KB (compressed), necessary Java code (classes.dex) is 113.6 KB (compressed).
In ARM64, the core engine is approximately 3.5 MB (compressed), the framework + app code is approximately 872 KB (compressed), the LICENSE file is 54.3 KB (compressed), necessary Java code (classes.dex) is 113.6 KB (compressed).
On iOS, a release IPA of the same app has a download size of 10.9 MB on an iPhone X, as reported by Apple’s App Store Connect. The IPA is larger than the APK mainly because Apple encrypts binaries within the IPA, making the compression less efficient (see the iOS App Store Specific Considerations section of Apple’s QA1795).
Of course, YMMV, and we recommend that you measure your own app. To measure an Android app, run flutter build apk (using the new --split-per-abi option in version 1.7.8+hotfix.3 and later) and load the APK (build/app/outputs/apk/release/app-armeabi-v7a-release.apk or build/app/outputs/apk/release/app-arm64-v8a-release.apk) into Android Studio (Android Studio instructions) for a detailed size report. To measure an iOS app, upload a release IPA to Apple’s App Store Connect (iOS instructions) and obtain the size report from there.
What kind of app performance can I expect?
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.
What kind of developer cycles can I expect? How long between edit and refresh?
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.
How is ‘hot reload’ different from ‘hot restart’?
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:
You can compile and deploy your Flutter app to iOS and Android.
What devices and OS versions does Flutter run on?
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 believe Flutter works well on tablets. We do not currently implement all of the tablet-specific adaptations recommended by Material Design, though we are planning further investment in this area.
Does Flutter run on the web?
Flutter web is currently in technical preview. We are developing Flutter for web in a fork of the Flutter repo. This enables fast iterations while keeping the core Flutter repo stable. You can repackage existing Flutter code to work on the web preview, but there are some caveats while we’re still in preview. Check out the web instructionsfor more details.
Can I use Flutter to build desktop apps?
Yes, but right now it’s not very well supported. We’re working on making this a first class experience. Our current progress is documented on our wiki.
Can I use Flutter inside of my existing native app?
Yes, you can embed a Flutter view in your existing Android for this use case (see issue #14821 for details).
Can I access platform services and APIs like sensors and local storage?
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.
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.
Can I extend and customize the bundled widgets?
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.
Why would I want to share layout code across iOS and Android?
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.
Can I interop with my mobile platform’s default programming language?
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 might 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.
Does Flutter come with a reflection/mirrors system?
Not at this time. Because Flutter apps are pre-compiled for production, and binary size is always a concern with mobile apps, we disabled dart:mirrors. We are curious what you might need reflection/mirrors for—let us know at firstname.lastname@example.org.
How do I do internationalization (i18n), localization (l10n), and accessibility (a11y) in Flutter?
How do I write parallel and/or concurrent apps for Flutter?
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.
Why is the build() method on State, not StatefulWidget?
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.
Where is Flutter’s markup language? Why doesn’t Flutter have a markup syntax?
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.
My app has a Debug banner/ribbon in the upper right. Why am I seeing that?
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.
What programming paradigm does Flutter’s framework use?
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:
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’sIterable 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, formalizes a subscription model for events with multiple listeners.
Class-based object-oriented 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 specialize 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-oriented 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, theUserAccountsDrawerHeader 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.
Yes, Flutter is open source technology. You can find the project on GitHub.
Which software license(s) apply to Flutter and its dependencies?
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 in its license file.
For a more custom approach, you can get the raw licenses from the LicenseRegistry.
Who works on Flutter?
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!
What are Flutter’s guiding principles?
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.
Will Apple reject my Flutter app?
We can’t speak for Apple, but Apple’s policies have changed over the years, and their App Store contains many apps built with technologies like Unity and Flutter. Apple has even featured Flutter apps such as Hamilton.
Of course, Apple is ultimately in charge of their ecosystem, but our goal is to continue doing everything we can to ensure that Flutter apps can be deployed to Apple’s App Store.