# iOS integration path — reusable core, not a shipped iOS application

This release contains real common Kotlin code and opt-in Apple framework targets. It does **not**
contain an Xcode application, a ZIPFoundation integration, or a tested iOS build.

## Build the shared framework on a Mac

Use JDK 17, the project-pinned Kotlin toolchain and an Xcode version compatible with it.
Kotlin 2.2.21's compatibility table lists Xcode 26.0; see `docs/SOURCES.md` before upgrading tooling.

```sh
./gradlew -PenableIos=true :core:assembleFileworkbenchCoreReleaseXCFramework
```

Expected Gradle output location after a successful build:
`core/build/XCFrameworks/release/FileworkbenchCore.xcframework`.
Targets: `iosArm64` and `iosSimulatorArm64` (Apple Silicon simulator). Add an Intel simulator
target only if required by a particular development machine.

## What is already shareable

`CoreApi`, classification, policy values, bounded XML parsing, DOCX/XLSX/PPTX/ODF text and table
extraction, CSV/Markdown handling, document models, literal search, and preview text export.
There are no Android or Java imports in `core/commonMain`.

The 0.2.0 browser also shares `BrowserEntry`, `BrowserLocation`, `BrowserListing`, `DirectoryReader`,
`BrowserOptions`, `BrowserEntries`, MIME matching, `PickerRequest`, sanitized display labels, and
`SelectionCopyBudget`. Implement DirectoryReader with security-scoped bookmarks/URLs; keep those
platform handles opaque to common code. Reuse selection and byte limits without copying Android
Intent/Uri/FileProvider types into the core. The SwiftUI browser and Apple adapter are not implemented.

## What the Apple shell must implement

- SwiftUI document importer / document browser; security-scoped URL access and bookmarks.
- Copy chosen bytes to an application-private, bounded read-only snapshot; retain no cloud links as
  if they were file bytes. Scope access using `startAccessingSecurityScopedResource` / matching stop.
- An `ArchiveContainer` adapter around a maintained Apple-capable ZIP library, with the same
  entry/path/ratio/decompression limits and tests as `JvmZipArchive`. ZIPFoundation is a candidate,
  **not** a bundled dependency or a completed integration. Enforce limits during inflation, not after.
- SwiftUI views of `DocumentPreview`, `PreviewSection`, and `TableData`.
- Native PDF/image viewing, likely PDFKit and platform image APIs, with independent security and
  memory review. Android's isolated Service/Messenger transport is not portable to iOS and should
  not be described as an iOS capability.
- Native recent-file persistence, explicit sharing/export, and cache/grant cleanup.

`CoreApi.readText` can be the first integration target. Convert `Data` to `KotlinByteArray` in the
host, call the exported API, and display the returned blocks. Public entry points that can fail
are annotated with `@Throws(PreviewException::class)` for the native boundary. ZIP adapter errors
must be translated appropriately; do not allow unrelated Kotlin exceptions to terminate the host.

Do not rewrite the Office readers in Swift. Do not put File Provider or Android URI types into
`DocumentPreview`. A future native Office engine belongs behind its own renderer adapter; it does
not replace the common file/document models.

## Acceptance gate

A Mac CI/device run must demonstrate framework compilation, a real document-picker open, text and
ZIP previews, PDF rendering, expired bookmark recovery and release of security-scoped access.
None of those Apple-runtime checks were executed for this source release.