> Fixing the fmt consteval Error in Xcode 26.4 for React Native

If you just updated to Xcode 26.4 and your previously healthy React Native iOS build is now throwing something like this at you, you're not alone:

Call to consteval function 'fmt::basic_format_string<char, unsigned int &>::basic_format_string<FMT_COMPILE_STRING, 0>' is not a constant expression

The error is ugly, the stack trace points deep into the bundled {fmt} library, and nothing in your own code changed. It's frustrating, but the root cause is reasonably straightforward and so is the fix.

What Changed

Xcode 26.4 ships with a newer Clang that tightened how it validates C++20 consteval functions. The version of the {fmt} library vendored inside React Native relies on compile-time format string checking, and the pattern it uses no longer satisfies the stricter constant-expression rules. The compiler is technically correct, but the practical result is that an unmodified React Native project suddenly refuses to build.

The cleanest workaround is to compile only the fmt pod against the C++17 standard. Since consteval didn't exist before C++20, the problematic code path is simply skipped and fmt falls back to its runtime format string validation. The rest of your project keeps using C++20, which matters because React Native's own code genuinely needs it.

The Podfile Fix

Open ios/Podfile and add a small block inside your existing post_install hook. If you already have a react_native_post_install call in there, leave it alone and append to it:

post_install do |installer|
  react_native_post_install(installer, config[:reactNativePath])

  installer.pods_project.targets.each do |target|
    if target.name == 'fmt'
      target.build_configurations.each do |config|
        config.build_settings['CLANG_CXX_LANGUAGE_STANDARD'] = 'c++17'
      end
    end
  end
end

The key detail is the target.name == 'fmt' check. Without it, you'd downgrade every pod in your project to C++17, and plenty of React Native internals will refuse to compile that way. Keep the scope narrow and you avoid creating new problems while fixing the current one.

After saving the Podfile, reinstall your pods and do a clean build:

cd ios
pod install
cd ..

Then in Xcode, use Product > Clean Build Folder (or the shortcut Shift + Command + K) before hitting build again. The stale derived data from the failed build will otherwise linger and can mask whether the fix actually worked.

When You Can Remove This

This is a workaround, not a permanent solution. The {fmt} maintainers have been iterating on their compile-time checking code to keep up with Clang's evolving constant-expression enforcement, and React Native will eventually pull in a version that builds cleanly under Xcode 26.4 without any intervention. When you upgrade React Native and see that the fmt pod has moved to a newer release, it's worth trying a build without the Podfile override to see if you can drop it.

Until then, scoping the C++ standard downgrade to a single pod is the right trade-off. You keep your build green, you don't touch the rest of the dependency tree, and the change is trivial to remove later.

If you want to follow progress on a proper upstream fix, the issue is being tracked on both facebook/react-native#55601 and expo/expo#44229. For more background on the underlying library, the fmt documentation is also a good reference.