getstream/stream-video-swift/development

Development

Apply shared rules.

TDD gate

Use test-driven development (TDD) for every code change. Write the behavior test first and observe its expected failure before implementing the change. For new APIs, add only declarations needed to compile the written test before observing that failure. For behavior-preserving refactors, establish a passing baseline and add missing coverage before production edits. Skipped tests, unrelated compilation errors, and infrastructure failures do not satisfy the gate. If the runner or required environment is unavailable, stop before production edits and report the blocker. For prose-only changes, use structural and link checks.

Workflow

1. Define expected behavior and affected callers. Read the owning type.

Check shared contracts and dependencies against related repositories. For WebRTC APIs, signaling, media, threading, or teardown, read Working with WebRTC.

1. Complete the TDD gate with the smallest test at the responsible component.

Follow the test design rules.

1. Make the smallest change that passes the test.

Rerun the same test without weakening its assertions. Reuse existing helpers and dependencies. Fix the shared owner once. Enforce request preconditions in the owning public method, such as Call.ring(). Do not classify encoded requests in middleware. Check cancellation, stale completions, teardown, and error paths when asynchronous state changes.

1. Update affected callers, behavior tests, and target membership.

Match sibling membership in StreamVideo.xcodeproj/project.pbxproj. Check Package.swift for package resources and module changes. Follow the documentation decision for public interface changes.

1. Refactor only while the relevant tests pass. Rerun them after refactoring.

Use the test skill for repeated runs and broader checks.

Public interface documentation

For changes to public symbols, signatures, defaults, or documented behavior, ask whether to update documentation and documentation tests together. Identify affected DocC comments, guides, migration notes, and DocumentationTests/ examples. Explain why updates are likely required. Use the repository access procedure when external guides need the private docs repository. Reuse explicit instructions already given for this task. With approval, update the material and follow documentation tests. Otherwise, report pending updates and continue independent work, including TDD checks.

Changelog

Update CHANGELOG.md only for added or updated public interfaces or bugs fixed in this change. Internal refactors, tests, tooling, and documentation alone do not qualify. Place every entry under # Upcoming, before the first released version heading. Never add or edit entries under a released version. Include a real, relevant URL in every entry, preferably its pull request or issue. If no URL is available, ask the user and leave the entry pending. Never invent links or use placeholders. Describe the user-visible change briefly.

Binary size

Avoid unnecessary binary growth from code, dependencies, or resources. Keep test assets outside shipping targets. When size can change, compare Release artifacts from the same SDK target or representative consumer app. Match architecture, toolchain, optimization, stripping, and packaging. Disable code coverage instrumentation for Release size comparisons. Report binary and resource sizes separately: baseline, candidate, and delta in bytes and percent. Explain necessary growth and alternatives. Preserve behavior, compatibility, security, and accessibility. If measurement cannot run, report size impact as unverified.

Repository conventions

• Use four spaces and nearby naming patterns. Use // MARK: - Group for sections.
• Import Foundation explicitly in every Swift file by default.
• Preserve deployment targets, media quality, and public API compatibility.

Follow semantic versioning and deprecate breaking APIs with a transition path. Discuss new dependencies or breaking changes before implementation.

Result

In the chat handoff, include the failing test and its passing result after the change. For behavior-preserving refactors, report baseline and final test results. For PR descriptions, follow the template and content rules. Keep local validation reports and implementation-process details out of the PR description.