fix(ios): add directory array items recursively in zip/zipWithPassword (#339)

[plrthink]

Fixes #339.

Problem

zip(string[]) behaved inconsistently across platforms when an array item is a directory:

• Android adds the directory's contents recursively, with entry names relative to the listed directory (a.txt, sub/b.txt).
• iOS passed the array straight to SSZipArchive's createZipFileAtPath:withFilesAtPaths:, which writes a directory as an empty entry — contents were silently dropped.

Fix

iOS now expands the array itself before writing, using SSZipArchive's public instance API (initWithPath:/open/writeFileAtPath:withFileName:.../close`):

• file item → entry name is its base name (unchanged)
• directory item → each contained file is written with its path relative to the listed directory, matching Android's entry names

Applied to both zipFiles and zipFilesWithPassword.

Preserved behaviors

• Per-entry progress events (total = expanded entry count)
• zipFilesWithPassword still writes with AES:YES, matching the previous withFilesAtPaths: code path
• compressionLevel remains ignored for file arrays on iOS (pre-existing; already documented)

Residual divergence

Android preserves empty directories (zip4j folder entries); iOS skips directory entries. Documented in the README along with the aligned behavior.

Verification

• playground-rn iOS app builds successfully (xcodebuild, Debug / iOS Simulator)
• npx jest — 27/27 pass

---

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🔍 Progress event denominator differs from Android for directory inputs

The new iOS writeZipEntriesToPath precomputes total = entries.count where entries are the fully recursively-expanded files (ios/RNZipArchive.mm:202). Android's processZip instead accumulates totalFiles incrementally and, for a directory item, counts only the immediate children (android/.../RNZipArchiveModule.java:381-393), calling addFolder once per immediate subdirectory while still incrementing the counter by 1. This means for directory inputs the two platforms emit a different number of intermediate progress ticks and different intermediate progress fractions. REVIEW.md states the progress contract was aligned in v9 and that divergence should be treated as a bug. In practice the iOS side is arguably more correct (monotonic, precomputed denominator), while Android's incremental denominator can jump around, so I did not flag this as a hard bug — but reviewers relying on strict cross-platform progress parity should be aware the tick counts diverge for directory array items.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[plrthink]

Re: Devin's comment on the progress denominator — acknowledged, and we're leaving it as-is in this PR on purpose. The iOS side (precomputed, monotonic denominator over fully expanded entries) is the more correct behavior and closer to the v9 progress contract; Android's processZip counting (incremental denominator, immediate-children-only for directory items) is the weaker side. Aligning Android's zip progress accounting is a separate piece of work and out of scope for this fix, which targets the content-level divergence from #339 (silently dropped directory contents).