Flutter - free resource mobile app, desktop, web

Every year the Flutter team publishes a roadmap, and the 2026 edition is unusually concrete about direction even as it avoids version-number promises. The team has committed to four stable and twelve beta releases this year, and — notably — stated it is not investing in built-in code push. What it is investing in tells you where cross-platform development is heading.

WebAssembly becomes the default for web

The biggest technical bet is WebAssembly. Flutter is on track to make Wasm the default output for Flutter Web, after preparing with Wasm dry-runs in 3.35 and later builds. The payoff is real: in the team’s tests, WebAssembly compilation delivered 40% faster load times and 30% less runtime memory. For anyone who has hesitated to ship serious apps on Flutter Web because of startup cost, this is the change that moves the needle.

Flutter comes to the living room

Google announced a collaboration with LG to bring Flutter to LG smart TVs, with an official Flutter-on-webOS SDK targeting a first-half-2026 release. TVs are a genuinely new surface for Flutter, and an official SDK — rather than a community port — signals that Google sees the framework as a way to write once and ship to phones, desktops, the web, and now the living room.

iOS plugins move to Swift Package Manager

On the Apple side, the roadmap commits to Swift Package Manager becoming the default iOS plugin option, replacing the CocoaPods-centric workflow many teams still use. More experimentally, the team is working on direct calls from Dart to Swift/Objective-C and Java/Kotlin without platform channels — a change that would cut boilerplate and latency at the native boundary. If it lands, writing plugins gets meaningfully simpler.

The real goal: platform parity

Underneath the specific features is a single stated objective for 2026: platform parity — erasing the “uncanny valley” where a Flutter app feels close to native but falls just short. You can see this thread in recent releases already: Cupertino Squircles matching Apple’s corner geometry, full iOS 26 and macOS 26 support, and Android screen-share protection. The roadmap is the same idea pointed forward.

A note on Flutter 4.0

Despite a steady stream of blog posts, Flutter 4.0 has not been officially released. It is speculated for mid-2026 and would be the first major version bump since 2022, but the official roadmap makes no version promise. Treat “Flutter 4.0 feature” articles claiming specific details as speculation until the Flutter team says otherwise; the authoritative sources are the official release notes and the flutter-announce group.

What to plan for

• Test your web build under Wasm. If Wasm is becoming the default, validate your app there before it becomes mandatory.
• Migrate plugins toward Swift Package Manager as the default shifts on iOS.
• Watch the new surfaces. LG webOS support means “Flutter developer” may soon include TV apps.

The bottom line

Flutter’s 2026 roadmap is pragmatic: faster, lighter web via WebAssembly; a real path onto TVs; a cleaner native plugin story on iOS; and a relentless focus on closing the last gaps with native. No grand version-number theatrics — just the unglamorous work of making one codebase feel genuinely at home everywhere it runs.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

Dart 3.13 ships alongside Flutter 3.47, and its headline feature is the one Dart developers have been asking for since the language got null safety: primary constructors are stable. Declare your fields and your constructor in the class header, and delete the three-line ceremony that every model class in your codebase currently repeats.

There is also a breaking change hiding in the release, and it is not the one most people expect.

The basic shape

The traditional form:

class Point {
  int x;
  int y;
  Point(this.x, this.y);
}

The primary constructor form:

class Point(var int x, var int y);

That is the entire class. Note the ordering — the modifier comes first, then the type, then the name: var int x, not int var x.

Declaring parameters are the actual feature

This is the part worth understanding properly, because it is where the design is subtler than “shorter syntax”.

A parameter prefixed with var or final is a declaring parameter: it induces an instance field. A parameter without either modifier behaves like an ordinary constructor argument and creates no field at all.

// Creates fields x and y
class Point(var int x, var int y);

// No field created — `name` is just an argument
class User(String name);

That distinction gives you a validation-only constructor for free, without the usual trick of a private field you never read.

For immutable models — which is most of them in a Flutter codebase — use final:

class ConstPoint(final int x, final int y);

Named parameters, and the underscore trick

Named parameters work as you would expect, with one nice detail: a private named parameter automatically exposes a public name to callers.

class User({required var String _name});
// Called as: User(name: 'John Doe')

The field is _name, private to the library. The argument label is name, public. You get encapsulation without writing a constructor that maps one to the other.

Named and private primary constructors

Append a dot and a name after the class identifier:

class Point.custom(var int x, var int y);

// Private — restricts direct instantiation from outside the library
class Point._(var int x, var int y);

The private form is the sealed-ish pattern many packages implement by hand today.

Const primary constructors

Put const before the parameter list:

class ConstPoint const (final int x, final int y) {
  final int z;
  this : z = x + y;
}

The constraints are the ones you would guess from const semantics:

• no body block
• every field must be final and definitely initialised
• initialising expressions must be potentially constant

For Flutter this matters more than it looks. Const widget constructors are a real performance lever, and anything that makes them cheaper to write means more of them get written.

Adding a body without giving up the header

You are not choosing between a primary constructor and constructor logic. this : introduces an initializer list, a body, or both:

class Point(var int x, var int y) {
  this : assert(x >= 0 && y >= 0) {
    print('Point initialized at ($x, $y)');
  }
}

Super parameters forward cleanly:

class Person(final String name, final int age);

class Employee(super.name, super.age, final String role) extends Person;

The scoping rule that will trip you up

There are two scopes, and they resolve the same identifier differently:

Concretely:

class ScopingDemo(var String x, String suffix) {
  final String field = x;  // 'x' is the parameter

  this : {
    x = x.toUpperCase();   // 'x' now refers to the field
    print('$x$suffix');    // 'suffix' is still the parameter
  }
}

Read that twice before you refactor a class with a non-trivial initializer list. It is consistent, but it is not obvious.

Restrictions

Compile-time constraints worth knowing before you start converting classes:

• declaring parameters cannot be late or external
• parameter names cannot collide with existing methods or fields
• parameters are read-only inside the primary initializer scope
• you cannot initialise a field both at its declaration and in the primary constructor
• mixin classes may only declare trivial primary constructors — no parameters, no initializer list, no body
• covariant only works with mutable (var) declaring parameters

The breaking change

Here is the part to plan for. final and var on regular function parameters are now reserved exclusively for primary constructor declaring parameters. Existing code that wrote void f(final int x) becomes invalid.

The lint story changed accordingly: parameter_assignments (Dart 3.13+) replaces the older avoid_final_parameters and var_with_no_type_annotation from 3.12 and earlier.

There is a second, quieter hazard: a method named factory without an explicit return type can now be misparsed as a factory constructor. If you have one, add the return type annotation.

What else is in 3.13

Beyond the language change:

• dart2wasm deferred loading (preview) — dart compile wasm -O2 --enable-deferred-loading, with meaningful initial-page-load improvements over dart2js for large apps
• @RecordUse() in package:meta, enabling native libraries to be tree-shaken alongside Dart code
• formatter refinements — a fix for misformatting around large collection literals, better method-chain split heuristics, and blank lines between import sections per Effective Dart
• type promotion soundness fix for nested functions
• faster dartdoc rendering on pub.dev via a two-level hash index

Adopting it without churn

1. Upgrade and build. Fix any void f(final int x) parameters the analyzer now rejects.
2. Add explicit return types to any method named factory.
3. Enable parameter_assignments and remove avoid_final_parameters / var_with_no_type_annotation from analysis_options.yaml.
4. Start with plain data classes — DTOs, value objects, freezed-adjacent models. Highest boilerplate reduction, lowest risk.
5. Use the four IDE refactorings to move between primary and in-body constructors rather than editing by hand.
6. Convert const widget constructors next, once you are comfortable with the const form’s constraints.
7. Leave classes with complex initializer lists for last, and re-read the scoping table before you touch them.

The bottom line

Primary constructors are the rare language feature that is purely subtractive: same semantics, less typing, no new concepts once you understand declaring parameters. The var/final restriction on function parameters is a genuine breaking change, but a mechanical one your analyzer will find in a single build. Convert your data classes this week; leave the gnarly ones until you have internalised the two-scope rule.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

Two of the biggest platform stories of 2026 are, at their core, the same story told twice. Apple is weaving Apple Intelligence through iOS 26, and Google is rolling out Gemini Intelligence across Android 17 and beyond. Both companies are making the same bet: that an ambient, proactive assistant baked into the operating system — not a separate chatbot app — is the next default way people use their phones. For developers, that bet changes what users expect from every app they open.

Two paths to the same idea

On iOS 26, Apple Intelligence has expanded its reach: deeper ChatGPT integration in Visual Intelligence (now usable on screenshots), and — importantly — the ability for third-party apps to integrate the Apple Intelligence framework. iOS 27, due in fall 2026, pushes further with a redesigned Siri capable of natural conversation and a Shortcuts app that can assemble automations from a plain-language description.

On Android 17, Google’s Gemini Intelligence is arriving on select advanced devices and expanding across phones, watches, laptops, and cars. Google’s framing is nearly identical to Apple’s: an assistant that “handles the busy work” and works “proactively to get things done throughout your day.”

The convergence is the point. Whatever platform your users are on, they are being trained to expect the operating system itself to be smart, contextual, and helpful.

What changes for app developers

• Assistant-style help becomes an expectation. Users who lean on system AI will expect the apps inside those systems to be at least as capable. A static form or a dumb search box will feel dated.
• The integration surface is opening. Apple exposing its Intelligence framework to third-party apps, and Google extending Gemini across surfaces, means you can plug into the platform assistant rather than build everything yourself.
• On-device matters for privacy and cost. Both companies emphasize on-device processing. Running inference locally avoids cloud bills and keeps user data on the device — a genuine differentiator you can market.

The cross-platform angle

If you build with a single codebase, the AI race is both a challenge and an opportunity. You cannot rely on one platform’s assistant framework and call it done — your users are split across both. The Flutter ecosystem has responded with a deep bench of AI packages: on-device LLM runners, official Google and OpenAI SDKs, chat UI kits, and speech tooling. The practical pattern in 2026 is to design an AI feature once and wire it to whichever provider — cloud or on-device — fits each platform and price point.

What to do now

• Add one genuinely useful AI feature, not a gimmick — summarization, natural-language search, or a task assistant that fits your app’s core job.
• Prefer on-device where you can for privacy and predictable cost, falling back to cloud models for heavier work.
• Design provider-agnostic. Keep your AI layer swappable so you are not locked to a single vendor as the platforms evolve.

The bottom line

Apple Intelligence and Gemini Intelligence are two versions of the same future: the phone as a proactive assistant, with AI woven into the OS rather than bolted on. The apps that thrive in that world will be the ones that add real, contextual intelligence to their core experience — and, for cross-platform teams, do it in a way that works no matter whose assistant the user trusts.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

Google’s newest major release, Android 17, is rolling out to Pixel first and to other eligible devices through the rest of 2026. The theme this year is less about a single headline feature and more about three quiet shifts: better multitasking, deeper AI, and taking foldables seriously as a first-class form factor.

Bubbles turn any app into a floating window

The most visible change for everyday users is Bubbles — the ability to turn any app into a floating window for quick multitasking. It is the kind of feature that sounds small and changes daily habits, letting you keep a chat, a calculator, or a translation floating above whatever you are doing. Android 17 also adds a new toolbar to record your screen and your reactions at the same time, a nod to the creator workflows that dominate mobile.

Foldables get a gaming mode

Foldable phones have been on the market for years, but software has lagged the hardware. Android 17 introduces a foldable gaming mode that optimizes screen layout for the larger unfolded display. Combined with Google’s broader hardware push — including the newly introduced Googlebook built with Gemini at its core — the message is that foldables and unconventional form factors are now part of the mainstream Android story, not an afterthought.

Gemini Intelligence moves in

The strategic centerpiece is Gemini Intelligence, Google’s on-device and cloud AI layer, arriving on select advanced devices “later this summer” and expanding across phones, watches, laptops, and cars. Google frames it as an assistant that “handles the busy work” so you can focus — the same proactive-assistant pitch Apple is making with Apple Intelligence, now fully joined on the Android side.

Privacy and safety, tightened

Android 17 also ships meaningful privacy work: temporary location access, so an app can get your location once without permanent permission, and enhanced anti-theft features that can lock a stolen device. Google’s monthly “Android Drop” updates reinforce this — recent drops added fake-call detection in the Phone app and extended Quick Share to work with AirDrop on more devices.

What Android developers should do

• Test on foldables and floating windows. Bubbles and unfolded layouts expose apps that assume a single, fixed screen size. Responsive layout is no longer optional.
• Respect temporary permissions. Design flows that degrade gracefully when a user grants one-time location instead of always-on access.
• Plan for an AI surface. Whether or not you integrate Gemini directly, users increasingly expect assistant-style help inside apps.

For cross-platform teams, Flutter’s responsive-layout tooling and its recent Android content-protection features make it well suited to the Android 17 world — a single codebase still has to earn its keep on a folding screen, but the primitives are there.

The bottom line

Android 17 is an evolution, not a revolution — but the direction is clear. Multitasking is getting more fluid, AI is becoming ambient, and foldables are finally getting the software attention their hardware deserves. Developers who test across form factors and design for one-time permissions will be the ones whose apps feel native on Android in 2026.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

macOS 26, tên Tahoe, là hệ điều hành Mac hiện tại của Apple, và nó mang hai câu chuyện cùng lúc. Thứ nhất là thẩm mỹ và tức thì: Mac giờ khoác Liquid Glass, thay đổi thiết kế lớn nhất kể từ 2013. Thứ hai là cấu trúc và dứt điểm: Tahoe là bản macOS cuối cùng hỗ trợ Mac chạy Intel. Cùng nhau, đây là một bản chuyển tiếp đáng hiểu dù bạn dùng Mac hay làm phần mềm cho nó.

Liquid Glass trên desktop

Apple đưa vật liệu trong suốt mới lên Mac, và đi khá sâu: biểu tượng desktop, thư mục, Dock, điều hướng trong app, menu, thanh công cụ và Control Center đều mang chất “thủy tinh”. Thanh menu trong suốt khiến màn hình như rộng hơn. Apple cũng thêm cá nhân hóa mượn từ iOS — tông sáng, tối, trong cho biểu tượng, cùng màu nhấn và màu tô sáng văn bản tùy chỉnh.

App Điện thoại trên Mac

Bổ sung thực sự hữu ích là app Điện thoại cho Mac, chạy nhờ Continuity, chuyển tiếp cuộc gọi di động từ iPhone gần đó. Nó mang Call Screening, Hold Assist, Live Translation, Recents, Contacts và Voicemail lên desktop — lặng lẽ bớt đi một lý do phải cầm điện thoại lên khi đang tập trung.

Spotlight lớn lên, Launchpad nghỉ hưu

Spotlight thông minh hơn trong Tahoe: nó gợi ý app, tệp gần đây và đề xuất, hành động bạn có thể làm, và cả lịch sử clipboard. Đổi lại, Apple bỏ Launchpad, thay bằng giao diện “Applications” kiểu App Library sắp xếp app theo danh mục — một thay đổi đáng kể với thói quen của người dùng Mac lâu năm.

Mốc cắt Intel

Dòng quan trọng nhất với dev là: macOS Tahoe là bản macOS cuối cùng hỗ trợ Mac Intel. Từ macOS 27 — dự kiến thu 2026 với tên Golden Gate — Mac Intel sẽ không được hỗ trợ. Tahoe chạy trên mọi Mac Apple silicon cùng một số ít Mac Intel ra từ 2019.

Nếu bạn ship app Mac, đây là mốc lên kế hoạch. Universal binary và kiểm thử Intel có hạn dùng rõ ràng. Đội ngũ có thể bắt đầu coi Apple silicon là mục tiêu duy nhất cho chu kỳ phát hành lớn tiếp theo.

Ý nghĩa với Flutter và desktop đa nền tảng

Hỗ trợ macOS desktop của Flutter bám bộ công cụ hiện tại, và các bản gần đây hỗ trợ đầy đủ macOS 26. Với đội ship app Flutter desktop, Tahoe là dịp để xác nhận bản build chạy sạch trên Apple silicon và loại bỏ mọi giả định riêng cho Intel trước mốc cắt của macOS 27.

Kết luận

macOS 26 Tahoe là bản “nhìn về phía trước, khép cửa sau lưng”. Liquid Glass và app Điện thoại làm mới trải nghiệm, Spotlight thực sự mạnh hơn, và mốc cắt Intel kẻ một đường rõ dưới quá trình chuyển đổi nhiều năm. Với dev, việc cần làm đơn giản: quen với Apple silicon ngay, vì từ bản sau nó là lựa chọn duy nhất.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

Apple được cho là sắp làm điều chưa từng có trong kỷ nguyên iPhone hiện đại: tách dòng flagship qua hai mùa. Theo nhiều nguồn chuỗi cung ứng và phân tích, thu 2026 sẽ mang tới iPhone 18 Pro, iPhone 18 Pro Max và chiếc iPhone gập đầu tiên của Apple, trong khi iPhone 18 tiêu chuẩn, iPhone 18e và có thể iPhone Air 2 dời sang xuân 2027. Như mọi phần cứng chưa ra mắt, hãy coi các chi tiết là tin đồn — nhưng hướng đi thì nhất quán giữa các nguồn.

Chiếc iPhone gập đầu tiên

Phần quan trọng nhất là iPhone gập, thường gọi là “iPhone Fold”. Các nguồn nói màn hình khoảng 5,4 inch khi gập và khoảng 7,8 inch khi mở, với nếp gấp “gần như vô hình” nhờ bản lề chất lượng cao. Giá đồn khởi điểm quanh 2.500 USD, định vị nó như thiết bị hào quang chứ không đại trà.

Nếu chính xác, điều này quan trọng vượt ngoài dòng sản phẩm Apple. Một chiếc gập từ Apple sẽ xác nhận dạng máy này cho lượng lớn người dùng và dev iOS vốn coi máy gập là chuyện của Android. Chỉ sau một đêm, “app của bạn có chạy khi mở ra không?” trở thành câu hỏi đội iOS cũng phải trả lời.

iPhone 18 Pro: nâng cấp có mục tiêu

iPhone 18 Pro dự kiến là bản tinh chỉnh của 17 Pro được đánh giá tốt. Tin đồn gồm Dynamic Island thu nhỏ — có thể nhờ Face ID dưới màn hình, chỉ còn một lỗ camera trước ở góc trên bên trái — camera Wide khẩu độ thay đổi, và chip A20 2nm nhanh hơn. Một màu đỏ đậm mới được đồn là màu đặc trưng của năm.

Face ID dưới màn hình và Dynamic Island co lại là kiểu thay đổi lan tới thiết kế app: safe-area inset và bố cục nhận biết notch phải thích ứng mỗi khi Apple đổi phần trên màn hình.

Dev nên rút ra điều gì

• Sẵn sàng cho máy gập giờ là chuyện đa nền tảng. Nếu Apple ship iPhone gập, bố cục responsive/adaptive thôi là mối lo chỉ của Android. Dùng framework xử lý tốt hình học màn hình biến đổi — Flutter nằm trong số đó — là một cách phòng thân.
• Để ý safe area. Dynamic Island nhỏ hơn và cảm biến dưới màn hình sẽ đổi inset phía trên. Bố cục hard-code kích thước notch sẽ hỏng.
• Chuẩn bị cho mùa iPhone dài hơn. Lịch tách đôi nghĩa là “iPhone mới” không còn là một khoảnh khắc mùa thu.

Kết luận

Thu 2026 có thể là đợt ra mắt iPhone quan trọng chiến lược nhất nhiều năm — không phải vì iPhone 18 Pro cách mạng, mà vì một iPhone gập và lịch tách đôi sẽ định hình lại cách dev nghĩ về kích thước màn hình, safe area và thời điểm phát hành. Chưa gì chính thức cho tới khi Apple xác nhận, nhưng đội nào dựng UI adaptive, thân thiện với máy gập ngay bây giờ sẽ sẵn sàng trong mọi trường hợp.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

iPhone 17 Pro — Apple ra mắt tháng 9/2025, giá khởi điểm 1.099 USD — nay là thiết bị mà người dùng iPhone khó tính nhất đang cầm, và là mốc tham chiếu đa số dev di động nên kiểm thử. Gần một năm sau, câu chuyện rõ hơn lúc ra mắt: một cuộc tư duy lại về nhiệt và hiệu năng, gói trong vật liệu Apple từng bỏ hai thế hệ trước.

Nhôm trở lại — và đó là điểm mấu chốt

Thay đổi phần cứng nổi bật là Apple đưa bản Pro trở lại thân nhôm nguyên khối, rời khỏi titan các đời gần đây. Nghe như bước lùi cho tới khi hiểu vì sao: nhôm nhẹ hơn titan và tản nhiệt tốt hơn. Apple hàn laser một buồng hơi (vapor chamber) vào khung nhôm đó, và kết quả là thứ Apple gọi là hiệu năng bền bỉ tốt nhất từ trước tới nay cùng “bước nhảy khổng lồ về thời lượng pin”.

Với ai từng thấy iPhone bị bóp xung khi export dài, chơi game nặng hay chạy AI trên thiết bị, đây là thay đổi có ý nghĩa. Điểm benchmark đỉnh ít quan trọng bằng hiệu năng bền — và đó chính là thứ tản nhiệt tốt mang lại.

A19 Pro và AI trên thiết bị

Cả hai bản Pro chạy A19 Pro, chip Apple gọi là mạnh và hiệu quả nhất cho iPhone. Năm 2026, tải công việc thú vị không chỉ là game mà là Apple Intelligence và AI trên thiết bị. Một con chip giữ được xung dưới tải nhiệt là con chip có thể chạy mô hình cục bộ mà không biến máy thành lò sưởi. Với dev thử suy luận trên thiết bị, 17 Pro là chiếc khiến các tính năng đó khả thi chứ không chỉ là demo.

Camera: ba cảm biến 48MP và zoom 8x

Hệ camera là ba camera Fusion 48MP — Main, Ultra Wide và Telephoto hoàn toàn mới — mà Apple nói tương đương tám ống kính. Tele dùng thiết kế tetraprism thế hệ mới với cảm biến lớn hơn 56% và tiêu cự tương đương 200mm, cho zoom quang học 8x và dải quang tổng 16x — tele dài nhất từng có trên iPhone.

Độ bền cũng cải thiện: Ceramic Shield 2 mặt trước chống xước tốt hơn 3 lần, và lần đầu Ceramic Shield bảo vệ cả mặt lưng.

Ý nghĩa với người làm app

• Kiểm thử trên bản Pro hiện tại. Màn hình, camera và hồ sơ nhiệt của nó định nghĩa “cao cấp” mà app của bạn bị đem ra so.
• Thiết kế cho hiệu năng bền. Tản nhiệt của 17 Pro khiến người dùng mong tính năng nặng — AR, video, AI trên thiết bị — chạy mượt không giật.
• App nặng camera có nhiều đất diễn. Tele 8x và cảm biến 48MP mở ra cơ hội thật cho app nhiếp ảnh, quét và AR.

Kết luận

iPhone 17 Pro không phải thiết kế lại hào nhoáng; nó là một cuộc tái kỹ thuật. Thân nhôm cộng buồng hơi phá trần nhiệt vốn giới hạn hiệu năng bền, A19 Pro khiến AI trên thiết bị khả thi, và hệ camera là bước nhảy thật cho ai sáng tạo bằng ống kính. Nếu bạn làm cho iPhone, đây là thiết bị cần nhắm tới — và là bản xem trước hướng đi của Apple với iPhone 18 Pro cuối 2026.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.