Fix Xcode 27 linker crash by co-locating ChatView's init with its @State properties - #302
Merged
Merged
Conversation
properties Xcode 27's Swift 6.4 compiler fails to link the default-value symbol for a @State property when the type's initializer is declared in a different file (swiftlang/swift#91700). ChatView's designated init lived in ChatBuilderParameters.swift while its @State properties are declared in ChatView.swift, so any app linking against ChatView failed with: Undefined symbols for architecture arm64: "variable initialization expression of ExyteChat.ChatView.(__chatSize ...)" Moving the init into ChatView.swift (same file as the @State declarations) resolves it, per the workaround described in the upstream issue.
nezhyborets
added a commit
to MacPaw/OpenAI
that referenced
this pull request
Sep 18, 2026
Demo/Demo.xcodeproj fails to link on Xcode 27 because ExyteChat's ChatView declares its @State properties in one file and its designated initializer in another, which trips a Swift 6.4/Xcode 27 compiler bug (swiftlang/swift#91700): the linker can't find the "variable initialization expression" symbol for each @State property's default value. - Bump exyte/Chat from 2.5.7 to 3.3.0, which required three follow-up fixes: - drop .messageUseMarkdown(true): ChatView 3.x always applies markdown attributes to message text now, the modifier no longer exists - drop Hashable from ResponsesStore.ConversationTurn: ExyteChat.Message lost Hashable in 3.x (Equatable only), and the conformance was unused - pin exyte/AnchoredPopup to >=1.2.2 explicitly: MediaPicker 3.4.x calls PopupParameters.displayMode(_:), added in AnchoredPopup 1.2.0, but MediaPicker's manifest still understates its own requirement as `from: "1.1.3"`, so SwiftPM could otherwise resolve an incompatible 1.1.3 and fail to build - Point Chat at a fork branch (nezhyborets/Chat@macpaw-xcode27-init-fix) that moves ChatView's designated init into the same file as its @State declarations, working around the Xcode 27 linker bug. Upstreamed as exyte/Chat#302. Revert to the tagged release once that lands and a fixed Xcode toolchain ships. Verified with a full clean build (not incremental) and by installing and launching Demo in the iOS Simulator. Fixes #444 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2 tasks
Collaborator
|
Thank you @nezhyborets, have a wonderful day! |
nezhyborets
added a commit
to MacPaw/OpenAI
that referenced
this pull request
Sep 19, 2026
exyte/Chat#302 merged and shipped in 3.3.3, so the fork branch used as a stopgap is no longer needed. Point back at the upstream package. Verified with a full clean build of Demo on Xcode 27. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Building any app that uses
ChatViewcurrently fails to link on Xcode 27 (tested on 27.0 RC, build 27A266a) with errors like:This is a Swift 6.4/Xcode 27 compiler bug (swiftlang/swift#91700): the compiler fails to link a
@Stateproperty's default-value symbol when the type's initializer is declared in a different file than the property.ChatView's@Stateproperties (chatSize,cellFrames,isShowingMenu,giphyConfigured,pendingScrollTo,isScrolledToBottom,selectedGiphyMedia,tableContentHeight) are declared inChatView.swift, while the designatedpublic init(messages:...)is declared inChatBuilderParameters.swift.Fix
Moves the designated initializer from
ChatBuilderParameters.swiftintoChatView.swift, alongside the@Statedeclarations it doesn't explicitly assign. No behavior change — just relocating oneextension ChatView { public init(...) }block into the same file as the properties it's implicitly initializing. Everything else inChatBuilderParameters.swift(the builder parameter structs, typealiases) stays put, since those don't have this issue.Confirmed by reproducing the failure against
main, applying this change, and rebuilding clean with zero linker errors.Test plan
swift buildfor the package