Files
fileworkbench/ios/README.md
T
zemion db873063f8
Verify source and build Android / android (push) Canceled after 0s
initial commit v 0.2.0
2026-09-24 22:49:27 +02:00

60 lines
3.5 KiB
Markdown

# 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.