We build cross-platform apps in Flutter, so we are not neutral, and we say below when React Native is the better pick anyway.

TL;DR

• Rendering: Flutter paints every pixel with its own engine; React Native drives the real iOS and Android UI components from JavaScript.
• Look: Flutter looks the same everywhere; React Native looks native everywhere.
• Staffing: in Stack Overflow's 2024 survey, 62.3% of respondents used JavaScript and 38.5% TypeScript, against 6% for Dart.
• Performance: for typical business apps, users cannot tell. Flutter leads on heavy custom animation, React Native on standard platform screens.
• Web: neither should build your marketing website. React Native's real web advantage is sharing TypeScript with a React or Next.js site.
• Rule: React team already? React Native. Starting fresh with a branded, identical-on-both-phones design? Flutter.

Where they stand in October 2026

One draws the pixels, the other borrows them

Flutter brings its own drawing engine. Dart is compiled ahead of time to machine code, and Impeller, the default renderer on iOS and on Android 10 and newer since Flutter 3.27, paints every button, text run and animation itself through the GPU. Impeller precompiles its shaders when the engine is built, which is what removed the first-run animation stutter older Flutter apps were known for.

React Native does the opposite. Your JavaScript runs in Hermes, the engine Meta built for phones, and tells iOS and Android which of their own components to show. Since 0.82 it runs only on the New Architecture, where JavaScript calls native code directly instead of serialising messages over the old bridge, and since 0.84 a new version of Hermes is the default engine.

The same button makes the difference concrete. In Flutter:

ElevatedButton(
  onPressed: checkout,
  child: const Text('Pay now'),
)

That is a Flutter widget, drawn by Flutter. It is pixel for pixel identical on both phones, and it only looks like an iOS button if someone designs it to. In React Native:

import { Button } from 'react-native'

<Button title="Pay now" onPress={checkout} />

That renders the platform's own button: a UIKit button on iOS, an Android button on Android. It picks up each system's look, text handling and accessibility behaviour for free, and it changes when Apple or Google change theirs.

Neither is better in general: a bank or a shop with a strong brand usually wants the first, a utility that should feel like part of the phone usually wants the second. That is the question to answer before any benchmark.

The language is a staffing decision

Dart is a pleasant language, and anyone who knows TypeScript, Kotlin or Swift picks it up quickly. The issue is the pool. A React Native app can be maintained by any React developer, and the Stack Overflow numbers above show how many more of those there are. Outside Flutter, Dart is rarely used, so a Flutter app needs people who chose Flutter.

The bigger practical gain on the React Native side is sharing code with a website. If the product already has a React or Next.js frontend, the data models, validation and API client can live in one TypeScript package used by both:

// packages/shared/order.ts — imported by the Next.js site and the React Native app
export type OrderLine = { sku: string; qty: number }

export function orderTotal(lines: OrderLine[], prices: Record<string, number>) {
  return lines.reduce((sum, l) => sum + (prices[l.sku] ?? 0) * l.qty, 0)
}

A Flutter app next to a React website is two codebases in two languages, and that logic gets written twice. For a team that owns both, this often decides it on its own.

Performance: mostly a wash, with two edges

For lists, forms, a map, payments and push notifications, both are fast enough that users cannot tell which was used. The edges are real but narrow. Flutter has the advantage with heavy custom animation and complex drawn interfaces, because it owns every frame. React Native has the advantage when the app is mostly standard platform screens, long native lists and system components, because those are the platform's own code.

Be careful with the benchmarks you find. Most compare a small demo built by one person who knows one of the two frameworks much better than the other, and both frameworks replaced their rendering path in the last two years, so anything older than that measures software that no longer ships. What makes real apps slow is usually the same in both: work on the main thread, images far larger than the screen, and too many requests to a slow API.

The web is where they differ most

Both can run in a browser: Flutter directly, React Native through React Native for Web, which Expo sets up for you. Neither is how you should build the pages people find on Google. Flutter's own documentation says it is not suitable for static, text-rich websites and that its output does not match what search engines need to index it properly; its advice is to build landing pages, marketing and help content in normal HTML and keep Flutter for the app.

That is our advice for both frameworks. The website is a website, ideally a fast static one. The app is what people use once they are customers.

When a native feature is the whole point

Building natively means two apps, Swift and SwiftUI for iPhone and Kotlin for Android, at roughly twice the build and maintenance cost. It is worth it when the app lives on platform features: home-screen and lock-screen widgets, Apple Watch or Wear OS, CarPlay, augmented reality, heavy background work such as tracking or Bluetooth devices, or when you only need one platform.

For everything else, neither framework locks the platform out. You write the one native piece per platform and call it from the shared code. In Flutter that is a platform channel:

const channel = MethodChannel('app/battery');

final level = await channel.invokeMethod<int>('getBatteryLevel');

with a small Swift and Kotlin handler on the other end. React Native's New Architecture does the same through native modules. Either way, the piece written twice is one feature, not the whole app.

Plan for upgrades from day one

Flutter ships a stable release about every three months: 3.38 in November 2025, then 3.41, 3.44 and 3.47 through 2026. React Native ships roughly every two months, 0.84 to 0.87 between February and August 2026, and since February it belongs to the React Foundation under the Linux Foundation, with Meta, Microsoft, Amazon, Expo, Callstack, Software Mansion, Vercel and Huawei among its founding members. Neither is going anywhere.

That pace is the real maintenance cost. Apple and Google raise the minimum SDK versions they accept every year, and the framework, its plugins and the build tools have to move with them. An app nobody updates for a year eventually cannot ship an update at all. A small upgrade every few months is routine. A jump across two years of versions is a project, so it belongs in the budget from the start.

How we choose

If the team already writes React, choose React Native; if you are starting fresh and the design should be identical on both phones, choose Flutter. Then check the exceptions: an app that should look exactly like the system leans to React Native, rich custom animation leans to Flutter, widgets, wearables or hardware lean to native. If none of them applies, the deciding question is who will maintain the app in three years.

When a project calls for one codebase, we build it in Flutter, because the apps we are asked for are usually branded products that should look the same everywhere, and because the same Figma design goes to both stores without platform differences. When a client already has a React team, React Native is the better choice, and we tell them so.

Originally published on levelui.com, with who uses each framework in production, the full source list and answers to the questions clients ask: whether Google is abandoning Flutter, who owns React Native now, and when to build natively. Also available in German and Romanian.

This copy is a snapshot from the day it was posted, and it will not be updated here. The original on levelui.com is the version we keep current: when a framework ships a new version, a figure changes or a tool is renamed, that is where the correction lands. If you want the up-to-date version, follow the link above.

We are Level UI, a web design and development agency in Bucharest.

We encoded 12 typical web images, from photorealistic scenes to 3D renders to page screenshots, as JPEG, WebP and AVIF, matched them to the same visual quality and measured the bytes, the encode time and the decode time in Chrome. AVIF came out a median 20% smaller than WebP, and JPEG needed a median 37% more bytes than WebP. But on the three grainiest images AVIF needed more bytes than WebP, at the settings most tools use it took 7.6 times as long to encode, and on our own server that cost is why our site still serves WebP.

TL;DR

• Size: at the quality of WebP q85, AVIF was a median 20% smaller than WebP; JPEG was a median 37% larger.
• Grain: on the three noisiest images, AVIF was 17–22% larger than WebP.
• Encode: AVIF took a median 7.6× as long as WebP with sharp's defaults (1.8× at the effort Next.js uses).
• Decode: practically a tie, AVIF a median 3% slower in Chrome.
• Rule: AVIF where images are encoded once, ahead of time; WebP where a server encodes them on demand.

The three formats in one paragraph

JPEG is the format every browser and every tool has read for decades. WebP is Google's format, built on the VP8 video codec. AVIF is the image format of AV1, the video codec of the Alliance for Open Media. All three compress photos with loss; WebP and AVIF can also do lossless images, transparency and animation. The question for a website is which one gives the smallest file at the quality you would publish, what it costs to make, and whether every visitor can see it.

How we measured

We picked 12 images of the kinds that end up on business websites: two photorealistic scenes, one clinic website with a portrait photo, six 3D renders from our own article art and three screenshots of pages on our site. Every source was a lossless PNG resized to 1,600 px wide. We encoded each one with sharp, the image library behind Next.js and many other tools, as JPEG (mozjpeg) at eight quality settings from 50 to 95, WebP at the same eight, and AVIF at eleven from 30 to 80, with sharp's defaults otherwise.

To compare at equal quality we measured SSIM, a standard similarity score, between each file and its source, and for each image took the score WebP reached at quality 85, the setting our site uses. We then read off how many bytes JPEG and AVIF needed to reach the same score.

Encode times are wall-clock on an Intel Core i7-6700K. Decode times were measured in Chrome 142 with createImageBitmap, 12 rounds per file in rotating order after a warm-up round. None of our sources is a straight-from-camera photo; the photorealistic scenes are renders, which is why the image types are reported separately.

The results

File size of each image at the quality of WebP q85:

Each image 1,600 px wide, encoded with sharp 0.35.5 (mozjpeg, libwebp 1.6.0, libaom 3.15.1) on 10 October 2026. JPEG and AVIF were interpolated to the SSIM that WebP reached at quality 85, so every row compares files that look equally good by that measure; the q in brackets is the setting that gets there. "Not reached": JPEG stayed below that quality even at q95.

File size at the same quality

At the quality we serve, AVIF was a median 20% smaller than WebP, and JPEG was a median 37% larger than WebP. The AVIF advantage was largest on screenshots (a median 30%) and on the simple, clean render of a figure in a hospital bed, which came out at half the size. On the photorealistic scenes it was 19 to 33%. JPEG was the largest file wherever it could reach WebP's quality at all; on the screenshots and the grainy renders it could not, even at quality 95.

At a lower quality the gap widens. Matched to WebP at quality 75, the default of Next.js, AVIF was a median 27% smaller and JPEG a median 56% larger. Compared with the lossless PNG sources, the WebP files were about a twelfth of the size: 2.2 MB against 26 MB for all 12 images together.

Where AVIF loses: grain and fine noise

On three images AVIF needed more bytes than WebP, not fewer: 17% more on two of them and 22% more on the third. All three are renders with visible film grain, and they are the three noisiest images in the set by a simple measure of pixel-to-pixel detail, between 24 and 28 against 2 to 16 for the other nine. AVIF tends to smooth that kind of fine noise away, and keeping it costs bits.

Because those three are also among the largest files, the 12 AVIF files together came out 1% larger than the 12 WebP files; without them, AVIF saved 24% in total.

So if your images are grainy photos or renders with deliberate texture, test them before switching. If they are clean product shots, illustrations or screenshots, AVIF will almost certainly be smaller.

Encoding: where AVIF's cost is paid

With sharp's default settings, AVIF took a median 7.6 times as long to encode as WebP: about a second per image here, against 0.15 seconds for WebP and 0.13 for JPEG. The ratio ranged from 3 to 15 times, and the slowest were the large, detailed images. Next.js encodes AVIF at a lower effort setting, effort 3 instead of sharp's default 4; at effort 3, AVIF took 1.8 times as long as WebP, and the files were a median 4% larger at the same quality setting.

AVIF's cost is paid when the image is encoded, so whether it matters depends on where that happens. In a build step or a CDN that encodes each image once and caches it, a second per image is nothing. On a server that encodes on the first request, the first visitor waits for it.

We measured that on our own hosting before deciding: a 24-megapixel portfolio image took 40.07 seconds as AVIF against 2.57 seconds as WebP through the same Next.js optimiser, to save 17% of the bytes, and it kept one CPU busy the whole time. Our site serves WebP for that reason.

Decoding in the browser: practically a tie

Decoding took about the same time for AVIF and WebP: AVIF was a median 3% slower, around 14 milliseconds for a 1,600-pixel image on a desktop, and JPEG was 20% faster than WebP. Slowing the CPU down fourfold in Chrome changed almost nothing, because Chrome decodes images off the main thread.

The download is what counts. At the 1.6 Mbps that Lighthouse uses to simulate a mobile connection, the median AVIF file arrived 69 milliseconds sooner than its WebP version, and the smaller photorealistic scene 128 milliseconds sooner. That is the difference that shows up in Largest Contentful Paint when the image is the largest element on the page.

Browser support in 2026

Both formats are safe for almost every visitor. Can I Use puts global support at 96.74% for WebP and 95.35% for AVIF. AVIF has worked in Chrome since version 85, Firefox since 93, Safari on iPhone since iOS 16 and Edge since 121; Safari on the Mac lists it as partial, because it needs macOS Ventura or later and does not support AVIF's noise synthesis.

The few browsers left without either are the reason a fallback still makes sense: a picture element that offers AVIF first, then WebP, then JPEG:

<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" width="1600" height="900" alt="…">
</picture>

Or an image service that picks the format from what the browser says it accepts. In Next.js that is the built-in optimiser, which serves WebP only by default; AVIF is opt-in:

// next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
  },
}

Read the encoding section before you add that line if your optimiser runs on the same box as your app.

Which format to use

Use AVIF where images are encoded once, ahead of time, and WebP where a server encodes them on demand. A static site, a build pipeline or an image CDN can afford AVIF's encoding time and gets files a fifth smaller for it, with WebP as the fallback. A self-hosted optimiser on modest hardware, like ours, is better off with WebP, which is already about a quarter smaller than JPEG. Keep JPEG as the last fallback only.

Whatever you choose, it matters less than serving images at the right size: a 1,600-pixel image where 800 would do costs more than any format change saves.

Quality settings that match

The matches in our test were:

In sharp, that is:

import sharp from 'sharp'

await sharp('in.png').resize({ width: 1600 }).webp({ quality: 85 }).toFile('out.webp')
await sharp('in.png').resize({ width: 1600 }).avif({ quality: 67 }).toFile('out.avif')

Lower AVIF numbers do not mean worse images than the same number in WebP: the scales are different. One trap: Next.js turns its quality setting into an AVIF quality by multiplying it by 0.625, so 85 becomes 53. By our measure that is noticeably below its WebP at 85, so part of the saving you see from switching on AVIF in Next.js is lower quality.

Images and web fonts are the two parts of page weight a designer decides most directly.

Originally published on levelui.com, with the full source list. Also available in German and Romanian.

We are Level UI, a web design and development agency in Bucharest.