Hi Apple Developer Community, I’m investigating an HEVC/H.265 playback issue in an iOS application and would appreciate some guidance regarding device-level HEVC compatibility and AVFoundation/VideoToolbox behavior. Our application plays video content encoded in both H.264 and H.265 (HEVC). Current observations The same H.265 video content produces the following results: Device H.264 H.265 iPhone X Works Does not play iPhone 13 Works Works iPhone 15 Works Works iPhone 17 Pro Max Works Does not play H.264 playback works consistently across all tested devices. The interesting part is that H.265 works on the iPhone 13 and iPhone 15, but does not work on either the older iPhone X or the newer iPhone 17 Pro Max. This makes me unsure whether the issue is related to the device's HEVC hardware decoder, a specific HEVC profile/level/pixel format, codec/container signaling, or the playback framework. Questions Are there known differences in HEVC/H.265 decoding capabilities or supported profiles between these iPhone generations that could explain this behavior? Can a newer device such as the iPhone 17 Pro Max have compatibility limitations with a particular HEVC stream that successfully plays on an iPhone 13 or iPhone 15? Are there specific HEVC parameters that I should compare when troubleshooting this, such as: HEVC profile (Main / Main 10) Level and tier 8-bit vs 10-bit Pixel format Chroma subsampling (4:2:0 / 4:2:2) Resolution and frame rate Bitrate HDR10 / HLG / SDR Color primaries / transfer characteristics hvc1 vs hev1 MP4/fMP4 vs MPEG-TS container Audio codec Is there an Apple-recommended API or method to determine at runtime whether a particular HEVC stream is supported by the current device before attempting playback? If using AVPlayer/AVPlayerItem, what is the recommended way to diagnose whether a failure is caused by: Unsupported HEVC characteristics VideoToolbox decoding Container/codec signaling Audio decoding AVFoundation Network/streaming configuration? Are there any differences in HEVC support between local MP4 playback and HLS/fMP4 playback that I should take into account? Additional investigation I am planning to inspect the exact video characteristics using ffprobe/MediaInfo and compare a working stream against a failing stream. For example, I intend to compare: Codec Codec tag (hvc1 / hev1) Profile Level Tier Bit depth Pixel format Resolution Frame rate Bitrate Chroma subsampling Color space HDR metadata Container Audio codec I will also test the same video outside the application to determine whether this is specific to our playback implementation or to the HEVC stream/device combination. Main question The main thing I would like to understand is: How can the same H.265 content be successfully decoded on an iPhone 13 and iPhone 15, while failing on both an older iPhone X and a much newer iPhone 17 Pro Max? Is there an Apple-documented compatibility matrix or recommended diagnostic approach for identifying which HEVC characteristic is responsible for this behavior? Any guidance on the relevant Apple documentation, AVFoundation APIs, VideoToolbox APIs, or known device-specific HEVC limitations would be greatly appreciated. Thank you.

Hi, I’d like to confirm something regarding the hosting of the apple-app-site-association (AASA) file. We have a server that publicly hosts the AASA file and is accessible globally. However, this server sits behind an additional security layer (a security server/reverse proxy). My question is: Will this security layer affect Apple’s ability to access and validate the AASA file for Universal Links or App Clips? Are there specific requirements (e.g. headers, redirects, TLS versions, etc.) that we need to ensure the security server does not block or modify? Any guidance or best practices would be appreciated.

I’d like to confirm something regarding the hosting of the apple-app-site-association (AASA) file. We have a server that publicly hosts the AASA file and is accessible globally. However, this server sits behind an additional security layer (a security server/reverse proxy). My question is: Will this security layer affect Apple’s ability to access and validate the AASA file for Universal Links or App Clips? Are there specific requirements (e.g. headers, redirects, TLS versions, etc.) that we need to ensure the security server does not block or modify? Any guidance or best practices would be appreciated. Thanks!