|
| 1 | +--- |
| 2 | +title: What is Flutter? |
| 3 | +description: An Introduction to Flutter for Developers |
| 4 | +sidebar: |
| 5 | + order: 1 |
| 6 | +--- |
| 7 | + |
| 8 | +In the early stages of mobile development, you had two options: build your app |
| 9 | +twice (once for iOS in Swift, once for Android in Kotlin) or compromise on |
| 10 | +quality by wrapping a web view. The first option doubled your engineering costs |
| 11 | +and created divergent user experiences. The second option left users with janky |
| 12 | +interfaces that felt wrong on both platforms. |
| 13 | + |
| 14 | +Flutter changed this equation. It's Google's open source UI toolkit for building |
| 15 | +natively compiled applications for mobile, web, and desktop from a single |
| 16 | +codebase. Unlike earlier cross-platform frameworks that wrapped native |
| 17 | +components, Flutter draws its own pixels, giving you complete control over every |
| 18 | +frame that renders on screen. |
| 19 | + |
| 20 | +Flutter isn't experimental anymore. Companies like |
| 21 | +[eBay Motors](https://flutter.dev/showcase/ebay) use it for their vehicle |
| 22 | +marketplace app. [BMW](https://flutter.dev/showcase/bmw) uses it for its |
| 23 | +connected car experiences. [Nubank](https://flutter.dev/showcase/nubank), one of |
| 24 | +the world's largest digital banks, built its entire mobile platform with Flutter |
| 25 | +and serves over 100 million customers. |
| 26 | + |
| 27 | +This article explains how Flutter works under the hood, why businesses and |
| 28 | +developers choose it, and the ecosystem of tools and agencies that make it |
| 29 | +production-ready for enterprise teams. |
| 30 | + |
| 31 | +## How Flutter Works: The Architecture |
| 32 | + |
| 33 | +Most cross-platform frameworks act as translators. They take your code and |
| 34 | +convert it into native iOS and Android UI components at runtime. This |
| 35 | +translation layer creates performance bottlenecks and inconsistencies because |
| 36 | +iOS buttons don't behave exactly like Android buttons. |
| 37 | + |
| 38 | +Flutter takes a different approach. It doesn't use native platform widgets at |
| 39 | +all. Instead, it draws every pixel itself using a high-performance graphics |
| 40 | +engine. Think of it like a video game engine, but for building apps. On iOS, |
| 41 | +Android, desktop, and web, Flutter controls the entire rendering pipeline from |
| 42 | +your code down to the pixels on screen. |
| 43 | + |
| 44 | +This approach starts with [Skia](https://skia.org/), the same 2D graphics |
| 45 | +library that powers Chrome and Android. In 2022-24, Flutter introduced and set |
| 46 | +as default [Impeller](https://docs.flutter.dev/perf/impeller), a next-generation |
| 47 | +rendering engine that compiles shaders ahead of time for even better |
| 48 | +performance. When your Flutter app renders a button, it's not asking the OS for |
| 49 | +a button component. It's drawing the exact pixels that make up that button, down |
| 50 | +to the shadow and animation curves. |
| 51 | + |
| 52 | +Google chose [Dart](https://dart.dev/) as the programming language for Flutter |
| 53 | +for specific technical reasons. Dart compiles to native ARM machine code on |
| 54 | +mobile, which means your production app runs at full speed without a JavaScript |
| 55 | +bridge or interpreter. During development, Dart's Just-in-Time (JIT) compiler |
| 56 | +powers Hot Reload, one of Flutter's most praised features. You can change your |
| 57 | +code and see the result in under a second, without losing your app's state or |
| 58 | +restarting. |
| 59 | + |
| 60 | +Flutter's architecture centers on widgets. Everything in Flutter is a widget, |
| 61 | +from structural elements like rows and columns to styling properties like |
| 62 | +padding and margins. You compose these widgets together to build your interface. |
| 63 | +A button isn't a single object. It's a composition of widgets for gesture |
| 64 | +detection, padding, material effects, and text styling. This composability makes |
| 65 | +Flutter interfaces predictable and testable. |
| 66 | + |
| 67 | +The framework uses Ahead-of-Time (AOT) compilation for production builds. Your |
| 68 | +Dart code compiles directly to native ARM code, eliminating the runtime overhead |
| 69 | +of interpretation or just-in-time compilation. This is why Flutter apps can |
| 70 | +maintain 60fps (or 120fps on high-refresh displays) consistently. The |
| 71 | +framework's |
| 72 | +[rendering pipeline is designed to complete all work for a frame in under 16 milliseconds](https://docs.flutter.dev/tools/devtools/performance#:~:text=This%20means%20that%2C%20approximately%20every%2016ms%2C%20the%20UI%20updates%20to%20reflect%20animations%20or%20other%20changes%20to%20the%20UI.), |
| 73 | +the budget for 60fps rendering. |
| 74 | + |
| 75 | +Flutter's architecture has one more advantage: consistency across platforms. |
| 76 | +Because Flutter controls its own rendering, a button looks identical on iOS 15, |
| 77 | +Android 13, and a three-year-old device. You're not at the mercy of platform |
| 78 | +differences or OS version fragmentation. |
| 79 | + |
| 80 | +## Why Developers and Businesses Choose Flutter |
| 81 | + |
| 82 | +Hot Reload changed how mobile developers work. Before Flutter, changing a UI |
| 83 | +element meant recompiling your app, reinstalling it, and navigating back to the |
| 84 | +screen you were working on. This cycle took 30-60 seconds. With Hot Reload, you |
| 85 | +save your file and see the change in a few seconds, with your app's current |
| 86 | +state preserved. You can iterate on animations, test edge cases, and experiment |
| 87 | +with designs at a pace that wasn't possible before. |
| 88 | + |
| 89 | +For businesses, the math is simple. You write one codebase instead of two. That |
| 90 | +means one team instead of two separate iOS and Android teams. You don't need to |
| 91 | +synchronize features between platforms or maintain parity between codebases. |
| 92 | +When you fix a bug, it's fixed everywhere. When you ship a feature, it ships to |
| 93 | +all your users at once. |
| 94 | + |
| 95 | +Flutter gives you pixel-perfect control over your interface on every screen |
| 96 | +size. You're not limited by platform conventions or native component libraries. |
| 97 | +Companies building design systems appreciate this control. You can match your |
| 98 | +brand guidelines exactly, animate transitions the way your designers envisioned, |
| 99 | +and create custom UI components that work identically across mobile, desktop, |
| 100 | +and web. |
| 101 | + |
| 102 | +Dart's null safety system, introduced in Dart 2.12, prevents null reference |
| 103 | +errors at compile time. These errors are responsible for billions of dollars in |
| 104 | +software failures across the industry. Dart's type system catches null errors |
| 105 | +before you ship code to users. The language also supports modern features like |
| 106 | +async/await for handling asynchronous operations, strong type inference, and |
| 107 | +extension methods for adding functionality to existing classes. |
| 108 | + |
| 109 | +The business case extends beyond engineering efficiency. Teams shipping Flutter |
| 110 | +apps report faster time-to-market because they're not coordinating two |
| 111 | +platform-specific releases. They can experiment more freely because changes are |
| 112 | +cheaper to make. Most importantly, they can maintain quality standards across |
| 113 | +all platforms without fragmenting their engineering resources. |
| 114 | + |
| 115 | +## The Flutter Ecosystem: Tools and Agencies |
| 116 | + |
| 117 | +A framework is only useful if you can actually ship production apps with it. |
| 118 | +Flutter has matured into a commercial ecosystem with specialized tools and |
| 119 | +agencies that handle the full application lifecycle. |
| 120 | + |
| 121 | +### The Tooling Stack |
| 122 | + |
| 123 | +**Shorebird** solves one of mobile development's biggest frustrations: app store |
| 124 | +review times. When you find a critical bug, you can't just push a fix. You have |
| 125 | +to submit an update, wait 24-48 hours for Apple's review (longer on weekends), |
| 126 | +then wait for users to actually install the update. |
| 127 | +[Shorebird](https://shorebird.dev) enables |
| 128 | +[over-the-air updates](https://docs.shorebird.dev/code-push/) for Flutter apps. |
| 129 | +You can [patch bugs](https://docs.shorebird.dev/code-push/patch/) and ship |
| 130 | +changes directly to your users' devices without going through the store review |
| 131 | +process. It works by updating your Dart code while keeping your native shell |
| 132 | +unchanged, which keeps you compliant with |
| 133 | +[App Store](https://docs.shorebird.dev/code-push/guides/stores/app-store/) and |
| 134 | +[Play Store](https://docs.shorebird.dev/code-push/guides/stores/play-store/) |
| 135 | +guidelines. |
| 136 | + |
| 137 | +**Codemagic** is a CI/CD platform built specifically for mobile apps. Generic CI |
| 138 | +systems like GitHub Actions work, but they weren't designed for the specific |
| 139 | +needs of mobile builds: managing certificates, provisioning profiles, |
| 140 | +platform-specific signing, and coordinating releases across multiple stores. |
| 141 | +[Codemagic](https://codemagic.io/) handles these mobile-specific workflows out |
| 142 | +of the box. It |
| 143 | +[integrates with Shorebird](https://docs.shorebird.dev/code-push/ci/codemagic/) |
| 144 | +and provides specialized workflows for releasing to the App Store, Play Store, |
| 145 | +and Firebase App Distribution. |
| 146 | + |
| 147 | +**ServerPod** lets you build your backend in Dart. Most Flutter apps talk to a |
| 148 | +backend written in Node.js, Python, or Go. [ServerPod](https://serverpod.dev/) |
| 149 | +lets you write full-stack applications in a single language. It includes an ORM, |
| 150 | +API generation, authentication, and real-time communication. If you're building |
| 151 | +a Flutter app and need a backend, ServerPod means your entire team can work in |
| 152 | +Dart with shared types and business logic between client and server. |
| 153 | + |
| 154 | +**Widgetbook** is Storybook for Flutter. It creates a catalog of your UI |
| 155 | +components where you can develop widgets in isolation, test them with different |
| 156 | +data, and document their usage. When you're building a design system or working |
| 157 | +on a team where designers need to review components, |
| 158 | +[Widgetbook](https://www.widgetbook.io/) provides a development environment |
| 159 | +focused purely on UI components, separate from your app's business logic and |
| 160 | +navigation. |
| 161 | + |
| 162 | +### The Experts: Agencies |
| 163 | + |
| 164 | +Not every company has the internal expertise or bandwidth to build a Flutter app |
| 165 | +from scratch. For businesses looking to scale quickly without an internal team, |
| 166 | +hiring a specialized Flutter app development company is a common path. |
| 167 | + |
| 168 | +**Very Good Ventures (VGV)** is known for defining architecture patterns and |
| 169 | +best practices in the Flutter community. They've worked with companies like |
| 170 | +Betterment and Hamilton, building production Flutter apps that handle millions |
| 171 | +of users. VGV open sources many of their tools, including |
| 172 | +[Very Good CLI](https://cli.vgv.dev/) for scaffolding projects and Very Good |
| 173 | +Coverage for enforcing code coverage standards. When companies need to establish |
| 174 | +patterns for large Flutter codebases, |
| 175 | +[VGV's architectural guidance](https://verygood.ventures/) shapes how teams |
| 176 | +structure their apps. |
| 177 | + |
| 178 | +**LeanCode** specializes in enterprise Flutter applications. They've built apps |
| 179 | +for European banks, healthcare providers, and logistics companies where |
| 180 | +security, compliance, and scale matter. Their expertise includes integrating |
| 181 | +Flutter with existing enterprise systems, implementing complex authentication |
| 182 | +flows, and optimizing performance for apps with heavy data requirements. |
| 183 | + |
| 184 | +A dedicated Flutter mobile app development company can accelerate time-to-market |
| 185 | +by using pre-built modules, established patterns, and deep knowledge of the |
| 186 | +platform's edge cases. These agencies have encountered and solved the problems |
| 187 | +you'll face, from handling offline sync to optimizing app size to debugging |
| 188 | +platform-specific issues. |
| 189 | + |
| 190 | +## Flutter vs. The Competition |
| 191 | + |
| 192 | +It is also important to look at Flutter’s competitors to understand the benefits |
| 193 | +that you get over them |
| 194 | + |
| 195 | +### Flutter vs. React Native |
| 196 | + |
| 197 | +React Native uses a JavaScript bridge to communicate with native platform |
| 198 | +components. When you render a button in React Native, your JavaScript code sends |
| 199 | +a message across this bridge to create a native iOS or Android button. This |
| 200 | +bridge adds latency and complexity. Flutter eliminates the bridge entirely by |
| 201 | +rendering its own components. This architectural difference means Flutter |
| 202 | +delivers more consistent performance, especially in complex UIs with heavy |
| 203 | +animation or frequent state changes. |
| 204 | + |
| 205 | +React Native's approach has an advantage: it uses actual native components, so |
| 206 | +updates to iOS or Android automatically apply to React Native apps. But this |
| 207 | +same characteristic creates consistency problems. Your React Native app can look |
| 208 | +and behave differently depending on the OS version. Flutter trades this |
| 209 | +automatic updating for guaranteed consistency across platforms and OS versions. |
| 210 | + |
| 211 | +### Flutter vs. Native Development |
| 212 | + |
| 213 | +Building native apps in Swift and Kotlin gives you immediate access to every OS |
| 214 | +API and the latest platform features on day one. Flutter catches up quickly |
| 215 | +(usually within weeks of a platform update), but native development is always |
| 216 | +first to new capabilities. |
| 217 | + |
| 218 | +The tradeoff is the maintenance burden. Native development means maintaining |
| 219 | +separate codebases with duplicated business logic, separate testing, and |
| 220 | +coordinated releases. For teams that can't afford dedicated iOS and Android |
| 221 | +engineers, or for companies where mobile isn't the core product, this |
| 222 | +duplication is expensive. Flutter significantly reduces this maintenance cost, |
| 223 | +though you give up the cutting edge of platform features. |
| 224 | + |
| 225 | +The decision often comes down to your constraints. If you need the absolute |
| 226 | +latest iOS 26 features and your app's value is tied to platform-specific |
| 227 | +capabilities, native development makes sense. If you need to ship across |
| 228 | +platforms quickly, control your interface precisely, and minimize long-term |
| 229 | +maintenance, Flutter is the better choice. |
| 230 | + |
| 231 | +## Where Shorebird Fits in the Stack |
| 232 | + |
| 233 | +The app stores serve a purpose. They enforce security standards, review apps for |
| 234 | +policy compliance, and give users confidence about the software they install. |
| 235 | +But the review process creates a bottleneck. You can't respond to production |
| 236 | +issues quickly. You can't iterate based on user feedback without waiting days |
| 237 | +for approval. |
| 238 | + |
| 239 | +This is the "last mile" problem. Flutter solves the problem of writing once and |
| 240 | +deploying everywhere. But you still hit the bottleneck of app store review times |
| 241 | +when you need to update your app. |
| 242 | + |
| 243 | +[Shorebird patches this last mile](https://docs.shorebird.dev/code-push/system-architecture/). |
| 244 | +It enables over-the-air updates that bypass the store review process. When you |
| 245 | +find a bug, you [create a patch](https://docs.shorebird.dev/code-push/patch/) |
| 246 | +and push it directly to your users. They receive the update automatically, |
| 247 | +without reinstalling your app or waiting for store approval. Shorebird works by |
| 248 | +separating your Dart code from your native app shell. The shell (which contains |
| 249 | +platform-specific code) goes through normal store reviews. Your Dart code (which |
| 250 | +is most of your app) can be updated over-the-air. |
| 251 | + |
| 252 | +Shorebird integrates cleanly with the rest of the Flutter ecosystem. You can add |
| 253 | +Shorebird commands to your |
| 254 | +[Codemagic workflows](https://docs.shorebird.dev/code-push/ci/codemagic/) to |
| 255 | +automatically create patches when you merge to production. Your developers |
| 256 | +continue using their existing tools. Shorebird adds one command to your |
| 257 | +[deployment process](https://docs.shorebird.dev/code-push/guides/development-workflow/). |
| 258 | + |
| 259 | +The philosophy behind Shorebird is that big tech companies like Google, Meta, |
| 260 | +and Microsoft have solved these problems internally for their own apps. They |
| 261 | +have systems to update apps without store reviews. Shorebird makes these |
| 262 | +capabilities available to every Flutter developer, not just teams with the |
| 263 | +resources to build their own infrastructure. |
| 264 | + |
| 265 | +## Next Steps |
| 266 | + |
| 267 | +Now that you understand Flutter and the ecosystem around it, here are practical |
| 268 | +paths forward: |
| 269 | + |
| 270 | +**Start Your First Flutter Project**: Download the |
| 271 | +[Flutter SDK](https://docs.flutter.dev/get-started/install) and follow the |
| 272 | +[Shorebird Quick Start](https://docs.shorebird.dev/getting-started/) to create a |
| 273 | +new project with code push capabilities built in. The `shorebird create` command |
| 274 | +scaffolds a Flutter app with Shorebird already integrated. |
| 275 | + |
| 276 | +**Set Up Your Development Workflow**: Establish a robust development process by |
| 277 | +following Shorebird's |
| 278 | +[development workflow guide](https://docs.shorebird.dev/code-push/guides/development-workflow/). |
| 279 | +Learn how to |
| 280 | +[test patches](https://docs.shorebird.dev/code-push/guides/testing-patches/) |
| 281 | +before deploying them and implement |
| 282 | +[staging environments](https://docs.shorebird.dev/code-push/guides/staging-patches/) |
| 283 | +to catch issues before production. |
| 284 | + |
| 285 | +**Implement Continuous Integration**: Automate your build and deployment |
| 286 | +pipeline using |
| 287 | +[Shorebird's CI documentation](https://docs.shorebird.dev/code-push/ci/github/). |
| 288 | +Whether you're using GitHub Actions, |
| 289 | +[Codemagic](https://docs.shorebird.dev/code-push/ci/codemagic/), or |
| 290 | +[Fastlane](https://docs.shorebird.dev/code-push/ci/fastlane/), you can integrate |
| 291 | +code push into your existing workflows. |
| 292 | + |
| 293 | +**Prepare for Production Release**: Before launching to the app stores, review |
| 294 | +the platform-specific guidelines for |
| 295 | +[iOS](https://docs.shorebird.dev/code-push/guides/stores/app-store/) and |
| 296 | +[Android](https://docs.shorebird.dev/code-push/guides/stores/play-store/). |
| 297 | +Implement |
| 298 | +[patch signing](https://docs.shorebird.dev/code-push/guides/patch-signing/) for |
| 299 | +additional security and set up |
| 300 | +[percentage-based rollouts](https://docs.shorebird.dev/code-push/guides/percentage-based-rollouts/) |
| 301 | +to gradually deploy updates to your user base. |
| 302 | + |
| 303 | +**Scale Your Team's Usage**: If you're working with a team, set up |
| 304 | +[Shorebird Organizations](https://docs.shorebird.dev/account/orgs/) to manage |
| 305 | +access and collaborate on releases. Configure your apps to work with |
| 306 | +[build flavors](https://docs.shorebird.dev/code-push/guides/flavors/android/) if |
| 307 | +you maintain multiple app variants or white-label applications. |
0 commit comments