Skip to content

fix: MessageView rendering on sizes smaller than screen size - #287

Closed
mrzzy wants to merge 1 commit into
exyte:mainfrom
mrzzy:main
Closed

fix: MessageView rendering on sizes smaller than screen size#287
mrzzy wants to merge 1 commit into
exyte:mainfrom
mrzzy:main

Conversation

@mrzzy

@mrzzy mrzzy commented Jul 20, 2026

Copy link
Copy Markdown

Fix MessageView rendering in containers narrower than the screen

Motivation

image

MessageView currently uses UIScreen.main.bounds.width to determine the available width for laying out message content and choosing the time view arrangement (hstack, overlay, or vstack).

This works when the chat occupies the full screen, but breaks when MessageView is embedded in a container that is narrower than the device screen (for example, side panels, sheets, split views, or custom layouts).

Because the layout logic overestimates the available width, it may incorrectly choose the horizontal (hstack) layout, resulting in truncated or clipped message content.

Changes

  • Replace the use of UIScreen.main.bounds.width in the layout calculation with the actual rendered width of MessageView.
  • Introduce a @State property to track the current view width.
  • Update the width dynamically using onGeometryChange and GeometryReader so layout decisions are based on the real available space instead of the device screen width.

This preserves the existing behavior for full-screen chats while allowing MessageView to render correctly when hosted inside narrower containers.

by reading view size from onGeometryChange
maxWidth: UIScreen.main.bounds.width,
alignment: message.user.isCurrentUser ? .trailing : .leading
)
.onGeometryChange(for: CGFloat.self) { proxy in

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GeometryChange on every cell is a big overhead, let's replace this with only calculating the width once. cells all have the same width - chatView's width. it can be calculated once on the very top of hierarchy and passed wherever it's needed

@f3dm76

f3dm76 commented Aug 18, 2026

Copy link
Copy Markdown
Collaborator

Hey @mrzzy, please check out version 3.2.9, should be fixed there, have a great day!

@f3dm76 f3dm76 closed this Aug 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants