Skip to content

Commit 6bb565b

Browse files
dawn-duckytomarra
andauthored
Feat: Add complete introduction to Flutter (#484)
* Feat: Add complete introduction to Flutter This document provides a comprehensive introduction to Flutter, explaining its architecture, advantages for developers and businesses, and the ecosystem of tools and agencies that support Flutter development. * format changes * spelling fixes * add front matter * fix front matter issues --------- Co-authored-by: Tom Arra <tarra3@gmail.com>
1 parent 6ac9107 commit 6bb565b

File tree

3 files changed

+312
-2
lines changed

3 files changed

+312
-2
lines changed

.cspell.yaml

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,7 @@ words:
3131
- evenodd
3232
- ffigen
3333
- jank
34+
- janky
3435
- libapp
3536
- libflutter
3637
- libupdater
@@ -40,6 +41,7 @@ words:
4041
- microsoftonline
4142
- mipmap
4243
- mozallowfullscreen
44+
- nubank
4345
- podfile
4446
- prefs
4547
- previewable
@@ -51,6 +53,7 @@ words:
5153
- subosito
5254
- temurin
5355
- webkitallowfullscreen
56+
- widgetbook
5457
- xcarchive
5558
- xcframework
5659
- xcframeworks
Lines changed: 307 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,307 @@
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.

src/content/docs/flutter-concepts/flutter-sdk-deep-dive.mdx

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,8 @@
11
---
22
title: Flutter SDK Deep Dive
3-
description: Learn how to manage organizations in Shorebird
3+
description: Learn how the Flutter SDK works under the covers
44
sidebar:
5-
order: 1
5+
order: 2
66
---
77

88
This article is a technical deep-dive through various parts of Flutter, written

0 commit comments

Comments
 (0)