@DTS Engineer Sorry for the delay, and thank you for looking into this. The previously posted code was a minimized extraction to reproduce the issue. In the actual application we provide an SDK component (a video player module). After playback completion we control a “remaining time” label and related UI using AVPlayerItem.didPlayToEndTimeNotification. The problem occurs when the user presses Play again while the item remains at the end position. Reproduction outline: During initialization (setupPlayer-equivalent) we create the AVPlayerItem and register for AVPlayerItem.didPlayToEndTimeNotification. When the view becomes visible (e.g. via scrolling), playback starts and a remaining‑seconds label is shown. When playback finishes, the notification fires and we hide the label. While the currentTime stays at the end, the user presses Play again. Up to iOS 18, this second Play still caused the notification to fire again, allowing us to reuse the same unified end-state hook (the label stayed hidden). On iOS 26 the notification does not fire, so the label may remain visible, producing an unexpected UI inconsistency. We had treated “play() invoked while the item is already at end causes the notification to re-fire” as a reliable centralized hook for updating the terminal UI state in an idempotent way. Since this assumption no longer holds on iOS 26, we now branch using an internal playback-state flag. Point of clarification we request: Is the iOS 26 behavior (no re‑post of AVPlayerItem.didPlayToEndTimeNotification when calling play() at end) an intentional specification change, or a regression? If this is the intended behavior, we will continue with the internal flag approach. Thank you for the confirmation.

Hello. This issue has been improved in Xcode beta6. Thank you very much.