Repository navigation
Description
The engine never passes an optimization flag to swiftc. Since swiftc defaults to -Onone, every Swift source in the Darwin embedders is compiled unoptimized in profile and release as well as debug, and assert() / assertionFailure() remain live in shipping binaries.
I wrote most of the original Swift build config myself in #167530 and I'm 99.9% sure this was an oversight on my part; nowhere in that patch did I mention optimisation. I remember getting derailed by some tricky issues in clang module support with libc++. It looks like the swiftflags half of the optimisation configs was simply never filled in. //build/config/compiler:optimize and :no_optimize set cflags and ldflags, but not swiftflags. The only swiftflags assignments in the build are:
build/config/darwin/BUILD.gn:54:-sdk,-target,-swift-version 5build/config/compiler/BUILD.gn:70:swiftflags = []build/config/compiler/BUILD.gn:163:-sanitize=threadunderis_tsanbuild/config/compiler/BUILD.gn:1119:-gunderconfig("symbols")
which means the flags are identical in all build variants. Looking at the generated ninja files:
ios_debug_unopt : -sdk <sdk> -target arm64-apple-ios15.0 -swift-version 5 -g …
ios_profile : -sdk <sdk> -target arm64-apple-ios15.0 -swift-version 5 -g
ios_release : -sdk <sdk> -target arm64-apple-ios15.0 -swift-version 5 -g
host_release : -sdk <sdk> -target arm64-apple-macos12.0.0 -swift-version 5 -g …
swiftc.py does pass --whole-module-optimization, which sounds like optimisation is enabled, but it's not. WMO is a separate feature that controls how the module is partitioned across frontend invocations. The compiler optimisation level is still -Onone.
The following commits later touched swiftflags and none of them mention optimisation either, though the asan/ubsan patch was, like this, me going back noticing I'd left configs out:
- Rename apple -> darwin across our buildroot #168558
- Enable Swift testing in the iOS embedder #185712
- [ios,macos] Update swiftc.py flags to match swiftc #189174
- iOS,macOS: add tsan and ubsan support for Swift #190497
What needs to happen
Add swiftflags to the optimization configs alongside the existing cflags. -Onone in :no_optimize, and in :optimize either -O or -Osize. is_ios already picks -Os for C/C++ to favour size over speed, so -Osize is probably the right choice for Swift.
Whether we should be optimising for size over speed in 2026 is a separate issue we should investigate.
Activity
iOS,macOS: Compile Swift with opt flags in opt builds
iOS,macOS: Compile Swift with opt flags in opt builds
LongCatIsLooong commentedon Aug 25, 2026
I assume we would also need to hook up LTO?
iOS,macOS: Compile Swift with opt flags in opt builds (flutter#191622)
iOS: Key the platform view factory registries by NSString (flutter#19…
macOS: Record test accessibility notifications in a dictionary (flutt…
macOS: Compare accessibility strings as NSStrings in tests (flutter#1…
cbracken commentedon Sep 15, 2026
This is fixed.
github-actions commentedon Sep 29, 2026
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.