Skip to content

Add SwiftUI native read bindings#845

Open
ubermensch1218 wants to merge 3 commits into
edwardkim:mainfrom
ubermensch1218:swiftui-native-read
Open

Add SwiftUI native read bindings#845
ubermensch1218 wants to merge 3 commits into
edwardkim:mainfrom
ubermensch1218:swiftui-native-read

Conversation

@ubermensch1218
Copy link
Copy Markdown

@ubermensch1218 ubermensch1218 commented May 12, 2026

Summary

  • add a Swift Package wrapper for the native RHWP C ABI
  • package the native library as an Apple XCFramework for Swift app integration
  • add direct HWP text reads via rhwp_read_text and expose RhwpDocumentTextView for SwiftUI display

Verification

  • cargo test --manifest-path bindings/Native/Cargo.toml
  • cargo build --manifest-path bindings/Native/Cargo.toml
  • swift test -Xlinker -L../../bindings/Native/target/debug
  • ./scripts/package-swift-xcframework.sh
  • unpacked generated XCFramework ZIP and linked the macOS slice to call rhwp_read_text against samples/KTX.hwp
  • launched a temporary macOS SwiftUI smoke app using RhwpDocumentTextView and confirmed HWP text rendered on screen

Notes

  • iOS Simulator app target runtime smoke is still not covered; the generated XCFramework includes iOS device and Apple Silicon simulator slices.

강정석 added 3 commits May 12, 2026 14:44
The native binding crate already provides a stable C ABI for text and Markdown export, so the Swift port starts as a thin SwiftPM package over that ABI instead of duplicating parser logic. The wrapper keeps file-based export semantics intact while giving Swift callers typed results and errors.

Constraint: Existing portable surface is the bindings/Native C ABI

Rejected: Rewrite the parser in Swift | would duplicate the Rust document model before the ABI is proven in apps

Confidence: high

Scope-risk: narrow

Directive: Keep Swift API additions aligned with bindings/Native symbols until an XCFramework packaging step is introduced

Tested: cargo build --manifest-path bindings/Native/Cargo.toml

Tested: swift test -Xlinker -L../../bindings/Native/target/debug

Not-tested: iOS app bundle/XCFramework runtime packaging
Swift app integration needs an Apple-native binary artifact, so the native FFI crate now emits a static library and the release helper assembles device, simulator, and macOS slices into RhwpNative.xcframework with a zipped archive and checksum.

Constraint: Xcode consumes native Rust code most cleanly through XCFramework artifacts

Rejected: Commit generated XCFramework output | binary release artifacts should stay under ignored dist/swift

Confidence: high

Scope-risk: narrow

Directive: Keep the generated archive out of git; rerun scripts/package-swift-xcframework.sh for release assets

Tested: ./scripts/package-swift-xcframework.sh

Tested: swift test -Xlinker -L../../bindings/Native/target/debug

Not-tested: importing the generated XCFramework into a real iOS app target
Swift app callers need document content in memory, not a TXT export side effect. The native ABI now exposes rhwp_read_text, Swift decodes that into page models, and the package includes a SwiftUI text view that loads an HWP URL and displays extracted pages.

Constraint: SwiftUI display should not depend on temporary export files

Rejected: Reuse rhwp_export_text for UI display | it writes TXT files and returns paths instead of document content

Confidence: high

Scope-risk: moderate

Directive: Keep read APIs side-effect free; export APIs remain the file-writing surface

Tested: cargo test --manifest-path bindings/Native/Cargo.toml

Tested: cargo build --manifest-path bindings/Native/Cargo.toml

Tested: swift test -Xlinker -L../../bindings/Native/target/debug

Tested: ./scripts/package-swift-xcframework.sh

Tested: unpacked XCFramework ZIP macOS slice linked to rhwp_read_text against samples/KTX.hwp

Not-tested: rendering inside a live iOS simulator app target
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant