Does adding the trackType field break existing SegmentMetric consumers?

No. The field is additive and existing code reading other SegmentMetric fields requires no changes.

Why are there pure Swift formatters if Kotlin already has the logic?

The overlay renders natively per platform. Swift formatters avoid a KMP bridge round-trip for simple UI string work and are covered by unit tests alongside the Kotlin equivalents.

What does the Xcode scheme pre-action actually run?

It triggers the Kotlin Gradle task that produces the XCFramework debug build before Xcode compiles the iOS target. Any shared KMP changes are picked up automatically without a separate terminal step.

Segment Track-Type Badges and iOS XCFramework Build Automation

Q: What platforms support track-type classification?

Android classification is driven by Media3's `MediaLoadData.trackType`. The `trackType` field lives in the shared KMP `SegmentMetric`, so it's available on iOS through the same data pipeline.

Stream Probe introduces color-coded track-type badges and file extension labels to the segment timeline overlay in this update. Each segment is now classified as Video, Audio, or Text so you can spot interleaving patterns without squinting at raw data.

TL;DR

A new SegmentTrackType enum classifies every segment in the timeline. The overlay on both Android and iOS now shows a color-coded badge and the segment's file extension alongside existing timing metrics. iOS local dev also got faster with an automated XCFramework rebuild step.

What's New

Added SegmentTrackType enum (VIDEO, AUDIO, TEXT, UNKNOWN) to the shared KMP layer
Added trackType field to SegmentMetric so track classification flows through the full data pipeline
Android: classification reads from Media3's MediaLoadData.trackType at load time
Android and iOS overlays both display a color-coded badge (Video, Audio, Text) and the segment's file extension per timeline row
Pure Swift formatters added for segment extension parsing, mirroring the Kotlin logic, with unit tests covering both sides
Xcode scheme pre-action now automatically rebuilds the Kotlin XCFramework before each iOS run, cutting manual steps out of the local dev loop
Added a design spec doc for the track-type distinction feature

How to Use

No API changes are required if you're consuming SegmentMetric downstream. The trackType field is populated automatically on Android via the existing MediaLoadData callback. On iOS, the Swift adapter maps it through the shared Kotlin mapper the same way other segment fields work.

If you're extending the overlay UI, the badge color is driven by SegmentTrackType:

VIDEO: blue badge
AUDIO: green badge
TEXT: orange badge
UNKNOWN: grey badge

For iOS local development, the XCFramework pre-action runs on every scheme build. No manual ./gradlew call needed before hitting Run.

FAQ

What platforms support track-type classification?

Android support is in this release, using Media3's MediaLoadData. iOS segment data flows through the shared KMP layer, so the trackType field is available on iOS too once the Android-side classification is mapped through.

Does this change break existing `SegmentMetric` consumers?

No breaking changes. The trackType field is additive. Existing code that reads other SegmentMetric fields continues to work without modification.

Why add pure Swift formatters when Kotlin logic already exists?

The overlay renders natively on each platform. Keeping Swift formatters in sync with Kotlin logic (and covering both with unit tests) avoids a round-trip through the KMP bridge just for string formatting in the UI layer.

What is the Xcode pre-action doing exactly?

It runs the Kotlin Gradle task that produces the XCFramework debug build before Xcode compiles the iOS target. This means any changes to shared KMP code are picked up automatically without a separate terminal step.