Confirming that this is resolved in Xcode 27 beta 6 — the original configuration now builds without any changes on our side. Thanks to you and the engineering team for taking care of it.

Hi Albert, Thanks — I've added the details to the report, but I need to correct my previous message before the engineering team acts on it. My earlier comparison was incomplete, and the follow-up testing points somewhere narrower than "static linkage." The issue: Lottie-Dynamic isn't offered by the package our report actually uses. Our setup depends on the Lottie product from lottie-spm, which doesn't build from source at all — it declares a binaryTarget pointing at a precompiled Lottie.xcframework.zip from a lottie-ios release (statically linked, as I confirmed locally). Lottie-Dynamic is declared in the separate source package, lottie-ios. So switching to it changed both the linkage and the distribution form. I've since tested the plain Lottie product from lottie-ios as well — static, but built from source: Package Product Form Result lottie-spm Lottie prebuilt static XCFramework via binaryTarget fails lottie-ios Lottie static, built from source succeeds lottie-ios Lottie-Dynamic dynamic, built from source succeeds Since the source-built static product builds fine, static linkage across multiple targets isn't sufficient to trigger this. What reproduces it is a prebuilt static XCFramework distributed via a binaryTarget and linked into more than one target — which also fits with the manual .xcframework route being the workaround you suggested. Apologies for the detour with the earlier conclusion. Everything above is now in the report, and I'll keep re-testing with each beta. Thanks again for your help.

Thank you, Albert! Appreciate you routing the bugs to the right team, and thanks for the explanation on tracking the status in Feedback Assistant. Thanks as well for the .xcframework suggestion. We'd rather keep our current SPM setup and wait for a fix in a subsequent beta than restructure the project around manually managed binaries, but it's good to know there's a way out if we need one. One data point that may help narrow things down: Lottie ships a dedicated dynamic product (.library(name: "Lottie-Dynamic", type: .dynamic, targets: ["Lottie"])), and switching our dependency to that product avoids the issue. The package dependency stays in place there — SPM still generates its build tasks, and the only thing that changes is the linkage (static → dynamic). That makes me suspect the problem is specific to a static library being linked into multiple targets, rather than SPM task generation in general. Happy to add this to the report if it would help. We'll keep re-testing with each beta. Thanks again for your time.

I also submitted feedback FB23932975.

I’ve found a workaround that avoids the truncation issue on iOS 18 and later using the new textRenderer(_:) modifier. It ensures that all lines are rendered properly without truncation. @available(iOS 17, *) struct MyTextRenderer: TextRenderer { func draw(layout: Text.Layout, in ctx: inout GraphicsContext) { for line in layout { ctx.draw(line) } } } extension View { @ViewBuilder func avoidTextTruncationBug() -> some View { if #available(iOS 18, *) { textRenderer(MyTextRenderer()) } else { self } } } struct MessageTextView: View { var text: String var body: some View { Text(text) .fixedSize(horizontal: false, vertical: true) .font(.body) .padding(.leading, 16) .padding(.trailing, 16) .padding(.top, 8) .padding(.bottom, 8) .avoidTextTruncationBug() } }

I’ve submitted feedback to Apple as well: FB17223576.

Thank you! You’re right — the Spacer()s themselves are not strictly necessary. However, I do need to apply trailing padding and align the text to the leading edge. I tried removing the Spacer() and simplifying the layout, but the issue still reproduces with the following code: HStack { MessageTextView(text: sampleText1) .layoutPriority(100) .padding(.trailing, 20) .frame(maxWidth: .infinity) }

I found that calling .simultaneousGesture(TapGesture()) on a Button can avoid this issue.

Hi Thank you for your reply. The environment I tested on below. Xcode Version: 16.0 (16A242) OS: iOS 18.0 Device: iPhone 16 Pro simulator, iPhone 12 mini