Skip to content

[iOS][macOS] Swift code is compiled -Onone in all build modes #191616

Closed

Description

@cbracken

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 5
  • build/config/compiler/BUILD.gn:70: swiftflags = []
  • build/config/compiler/BUILD.gn:163: -sanitize=thread under is_tsan
  • build/config/compiler/BUILD.gn:1119: -g under config("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:

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

  1. self-assigned this
    on Aug 24, 2026
  2. added
    platform-iosiOS applications specifically
    platform-macosBuilding on or for macOS specifically
    P2Important issues not at the top of the work list
    c: tech-debtTechnical debt, code quality, testing, etc.
    on Aug 24, 2026
  3. LongCatIsLooong commented on Aug 25, 2026

    @LongCatIsLooong
    Contributor

    I assume we would also need to hook up LTO?

  4. cbracken commented on Sep 15, 2026

    @cbracken
    MemberAuthor

    This is fixed.

  5. github-actions commented on Sep 29, 2026

    @github-actions

    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 -v and a minimal reproduction of the issue.

  6. locked as resolved and limited conversation to collaborators on Sep 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P2Important issues not at the top of the work listc: tech-debtTechnical debt, code quality, testing, etc.platform-iosiOS applications specificallyplatform-macosBuilding on or for macOS specifically

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions