Swift Style

Swift style and repo layout – Contentstack Utils Swift

When to use

• Editing any Swift under Sources/ or Tests/.
• Adding files or changing platform/deployment assumptions.

Tooling

• Run SwiftLint with .swiftlint.yml. Do not relax rules for new code without team agreement.
• `Sources/Kanna/` is excluded from SwiftLint—do not copy patterns into Sources/ContentstackUtils/ that would fail lint there.

Package layout

• Library code: Sources/ContentstackUtils/.
• Vendored Kanna: Sources/Kanna/—treat as third-party unless you are deliberately upgrading the vendored copy; prefer fixes in ContentstackUtils or documented Kanna upgrades.

Platforms and libxml2

• Deployment targets: macOS 10.13+, iOS/tvOS 11+, watchOS 4+ (Package.swift). Avoid newer SDK-only APIs without availability checks or a deliberate target bump.
• libxml2: Apple platforms use system libxml where applicable; Linux uses the libxml2 system target and pkg-config. Keep Modules/ and Package.swift conditionals in sync when changing platform support.

Naming and API surface

• Swift conventions: types UpperCamelCase, members lowerCamelCase.
• Preserve established public names even when imperfect (e.g. historical typos) unless doing a semver-major cleanup with maintainer agreement.

Imports and access control

• import Foundation as needed; HTML parsing follows existing Kanna usage in this package.
• Mark `public` / `open` intentionally; keep implementation internal or private unless tests use established @testable patterns.

References

• skills/framework/SKILL.md (SPM, podspec, CI)
• skills/testing/SKILL.md (lint exclusions in tests)