ChatChannelView floating composer leaves extra bottom gap in iOS 26 tabViewBottomAccessory hosts

[kdbrooks]

Updated findings

• This does not reproduce in the stock Stream demo app.
• The issue appears when stock ChatChannelView is embedded under a root TabView that uses iOS 26 tabViewBottomAccessory.
• The same class of regression can also be triggered by applying .toolbar(.hidden, for: .tabBar) on the pushed channel screen.
• If chat bypasses the accessory shell and we do not hide the tab bar from the channel screen, the layout looks correct.
• So this now looks less like a generic “floating composer always reserves space” bug and more like a compatibility issue between ChatChannelView's floating composer layout and Apple’s new tab accessory / tab-bar visibility environment.

What did you do?

• Presented stock ChatChannelView full-screen in SwiftUI.
• Used composerPlacement = .floating.
• Tested on the current Stream v5 beta line (develop branch revisions listed below).
• Reproduced inside a host app whose root TabView uses iOS 26 tabViewBottomAccessory.
• Also tested the same host flow with .toolbar(.hidden, for: .tabBar) on the pushed channel screen.
• Compared against the stock Stream demo app and against a host configuration where chat bypasses the accessory shell.

What did you expect to happen?

• With composerPlacement = .floating, the newest message should rest directly under the visible floating composer chrome, without a persistent reserved bottom band.
• The composer should still remain correctly positioned above the keyboard.
• ChatChannelView should coexist with tabViewBottomAccessory just as it does in a normal tab/push setup.

What happened instead?

• In the accessory-hosted configuration, the transcript keeps an extra bottom band/gap under the latest message.
• Hiding the tab bar on the pushed channel screen with .toolbar(.hidden, for: .tabBar) can trigger the same class of regression.
• If the host forces .ignoresSafeArea(edges: .bottom) to remove the band, the keyboard can cover the composer.
• If chat bypasses the accessory shell, the gap disappears.

Current findings

• MessageListConfig.handleTabBarVisibility alone is not the fix.
• This is not fundamentally caused by modal vs push navigation.
• This is not caused by our extra wrapper chrome; a slimmed-down wrapper still reproduces if chat is routed through the accessory shell.
• During SDK-side instrumentation, tabViewBottomAccessoryPlacement was nil from inside ChatChannelView during the bad host repro, so detecting accessory presence from that environment alone may not be sufficient.
• We also observed cases where the floating transcript inset tracked the raw measured composer container height (76pt) rather than the visible overlap (48pt), suggesting the composer/list inset logic may be sensitive to container state and/or padded composer measurements in this environment.

Minimal repro shape

1. App root has a TabView.
2. TabView applies tabViewBottomAccessory.
3. One tab contains Stream channel list and pushes into stock ChatChannelView.
4. ChatChannelView uses composerPlacement = .floating.
5. Observe extra space under the floating composer.
6. Remove the accessory or bypass it for chat, and the gap disappears.

GetStream Environment

GetStream Chat version: v5 beta line from develop
GetStream Chat frameworks: StreamChat, StreamChatSwiftUI
iOS version: iOS 26.4
Swift version: Apple Swift 6.3
Xcode version: Xcode 26.4
Device: iPhone 17 Simulator

Additional context

• composerPlacement = .floating
• Exact revisions in our repro:
  • StreamChatSwiftUI: d46ad84161a8d69f913fd160c5a707e6afb244c4
  • StreamChat: dd9866b59db06bcadca614892b2ed006297ac73b
• These develop revisions are ahead of the 5.0.0-beta tag, so this repro is on the current v5 beta line rather than the exact beta tag.
• Current local workaround: bypass the shell modifier that applies tabViewBottomAccessory for chat, keep handleTabBarVisibility enabled, and avoid .toolbar(.hidden, for: .tabBar) on the channel screen.
• This now appears upstream-relevant as a compatibility issue between Stream’s floating composer layout and Apple’s iOS 26 tab accessory / tab-bar visibility model, rather than just a missing public underlap hook.

[laevandus]

Hi @kdbrooks, thank you for trying out upcoming v5 with refreshed design.

With composerPlacement = .floating, the transcript should be able to visually extend to the bottom edge / underlap behind the floating composer without leaving a persistent reserved bottom band.

Could you please share a screenshot of this problem. I tried with our demo app in the same repository and it looks like it is doing what you are asking for (this is with the liquid glass style which can be configured in the demo app through the configuration button on the login view). I would like to make sure I fully understand the problem and expected behaviour.

If you have some more feedback around the new design, we're happy to hear your thoughts.

Thank you!

[kdbrooks]

Hi @laevandus - We are really liking the v5 redesign so far! It has greatly reduced the custom code we needed to get the look we want.

Here is a screenshot of what we see:

One difference between the demo and our app is we use a glass toolbar and allow the messages to go to the top with a gradient fade overlay similar to iMessage.

Here is our View that hosts the ChatChannelView:

//
//  StreamChannelScreen.swift
//  Lucho
//
//  Chat channel shell used by the canonical list route.
//

import StreamChat
import StreamChatSwiftUI
import SwiftUI
import UIKit

struct StreamChannelScreen<Factory: ViewFactory>: View {
  @Injected(\.utils) private var utils
  @Environment(\.colorScheme) private var colorScheme

  let viewFactory: Factory
  let channelController: ChatChannelController
  var messageController: ChatMessageController?
  var scrollToMessage: ChatMessage?
  let channelIdRaw: String

  private var backgroundColor: Color {
    Color.appCardBackground(for: colorScheme)
  }

  private var fadeColor: Color {
    colorScheme == .dark ? .black : .white
  }

  private var windowSafeAreaInsets: UIEdgeInsets {
    UIApplication.shared.connectedScenes
      .compactMap { $0 as? UIWindowScene }
      .flatMap(\.windows)
      .first(where: \.isKeyWindow)?
      .safeAreaInsets ?? .zero
  }

  private var topFadeHeight: CGFloat {
    windowSafeAreaInsets.top + 52
  }

  private var composerReserveHeight: CGFloat {
    utils.composerConfig.inputViewMinHeight + 60 + windowSafeAreaInsets.bottom
  }

  private var bottomFadeHeight: CGFloat {
    min(max(composerReserveHeight * 0.5, 48), 72)
  }

  private var bottomFadeContainerHeight: CGFloat {
    bottomFadeHeight + windowSafeAreaInsets.bottom
  }

  private var bottomFadeBottomInset: CGFloat {
    max(composerReserveHeight - bottomFadeContainerHeight + 12, 0)
  }

  var body: some View {
    ChatChannelView(
      viewFactory: viewFactory,
      channelController: channelController,
      messageController: messageController,
      scrollToMessage: scrollToMessage
    )
    // Let Stream keep ownership of bottom safe-area and keyboard behavior.
    .ignoresSafeArea(edges: .top)
    .scrollEdgeEffectHidden()
    .background(backgroundColor.ignoresSafeArea())
    .overlay(alignment: .top) {
      ChannelEdgeFade(
        color: fadeColor,
        edge: .top
      )
      .frame(height: topFadeHeight)
      .ignoresSafeArea(edges: .top)
      .allowsHitTesting(false)
      .accessibilityHidden(true)
    }
    .toolbar(.hidden, for: .tabBar)
    .onAppear {
      TranslationPreference.shared.startObservingKeyboardLanguage()
    }
    .onDisappear {
      TranslationPreference.shared.stopObservingKeyboardLanguage()
    }
  }
}

private struct ChannelEdgeFade: View {
  enum Edge {
    case top
    case bottom
  }

  let color: Color
  let edge: Edge

  var body: some View {
    Rectangle()
      .fill(color)
      .mask(opacityRamp)
  }

  private var opacityRamp: LinearGradient {
    LinearGradient(
      stops: [
        .init(color: .black, location: 0),
        .init(color: .black.opacity(0.82), location: 0.3),
        .init(color: .black.opacity(0.28), location: 0.72),
        .init(color: .clear, location: 1),
      ],
      startPoint: .top,
      endPoint: .bottom
    )
  }
}

If I change the line .ignoresSafeArea(edges: .top) to .ignoresSafeArea(edges: [.top, .bottom]), the messages go to the bottom of the device screen but then when the composer is clicked and the keyboard appears it covers the composer and the user can't see what they are typing.

Thank you for your help!

[kdbrooks]

@laevandus - We have determined the cause of this issue is a compatibility issue with stream and the new iOS 26 tabViewBottomAccessory. I'm not sure if I should close this issue and make a new one. I'm leaning towards just updating this one once I dig in more. We turned off the tab accessory and removed the toolbar(.hidden, for: .tabBar) and now it looks correct:

[kdbrooks]

Adding one more finding from our local fork/debugging pass in case it helps narrow the upstream investigation.

What we saw in the bad host repro:

• The stock Stream demo app looked correct.
• The issue reappeared when chat was hosted under a root TabView using iOS 26 tabViewBottomAccessory.
• Applying .toolbar(.hidden, for: .tabBar) on the pushed channel screen could trigger the same class of regression even outside the full accessory-shell setup.

From instrumentation in ChatChannelView / MessageListView:

• In the failing host path, tabViewBottomAccessoryPlacement was nil from inside ChatChannelView, so accessory presence may not be directly detectable there via that environment value alone.
• In one path, Stream was still reacting to tab-bar/container state even when the observed tab bar was hidden.
• After removing that hidden-tab-bar safe-area contribution locally, the remaining bad inset still matched the raw measured floating composer container height (76pt) rather than the visible overlap height (48pt).

So our current best guess is that there may be two overlapping assumptions that break under this container model:

1. legacy bottom safe-area / tab-bar compensation being keyed off container state that is no longer a good proxy under tabViewBottomAccessory
2. floating composer transcript reservation following the padded composer container height instead of the visible overlap height

We did not get to a fix that we felt comfortable proposing upstream, but the current host workaround is to bypass the accessory shell for chat and avoid .toolbar(.hidden, for: .tabBar) on the channel screen.

If you investigate upstream, I’d focus on ChatChannelView / floating composer bottom inset behavior specifically under:

• TabView
• tabViewBottomAccessory
• pushed ChatChannelView
• hidden vs visible tab bar state

[laevandus]

Hi @kdbrooks, thank you for your investigation. We added this ticket to our internal issue tracker for further analysis.