Conversation
Declare iOS 15+ as a supported platform in Package.swift and document supported platforms in README.md. Made-with: Cursor
Replace #file-based currentDirectory() with Bundle.module resource loading for cross-platform compatibility. Write tests now use the system temporary directory instead of the source tree. Made-with: Cursor
Add xcodebuild test job on macos-15 runner with dynamic simulator selection for resilience against runner image updates. Made-with: Cursor
|
@sidpug-arcana Could you review this? |
There was a problem hiding this comment.
Pull request overview
Formalizes iOS support for the Arrow Swift package by declaring iOS as a supported platform, making IPC reader tests work inside Xcode/iOS test bundles, and adding CI coverage for iOS Simulator runs.
Changes:
- Declare iOS 15+ support in
Package.swiftand bundle IPC test.arrowfiles as SwiftPM test resources. - Update IPC tests to load testdata via
Bundle.moduleand write outputs to the system temp directory (iOS-safe). - Add an iOS Simulator GitHub Actions job and document supported platforms in the README.
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| Tests/ArrowTests/IPCTests.swift | Switch testdata loading to Bundle.module and write generated test output files to a temp directory for iOS/Xcode compatibility. |
| README.md | Document supported platforms including iOS 15+. |
| Package.swift | Add iOS platform declaration and declare test .arrow files as bundled test resources. |
| .gitignore | Ignore generated .arrow files in test and generator directories. |
| .github/workflows/test.yaml | Add an iOS Simulator CI job (macOS runner, dynamic simulator selection, xcodebuild test). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Tests/ArrowTests/IPCTests.swift
Outdated
| fatalError("Test data file \(filename).arrow not found in bundle. " | ||
| + "Run the Go data generator first.") |
There was a problem hiding this comment.
Using fatalError here will crash the entire test process if the resource is missing, which is harder to diagnose and can mask other failures. Consider making testDataURL throws and using XCTUnwrap/XCTFail so the failure is reported as a normal XCTest failure instead of aborting the run.
| fatalError("Test data file \(filename).arrow not found in bundle. " | |
| + "Run the Go data generator first.") | |
| XCTFail("Test data file \(filename).arrow not found in bundle. " | |
| + "Run the Go data generator first.") | |
| // Return a neutral placeholder URL so the test process does not crash. | |
| return URL(fileURLWithPath: "/dev/null") |
There was a problem hiding this comment.
Changed testDataURL to throws, using ArrowError.ioError.
| resources: [ | ||
| .copy("testdata_bool.arrow"), | ||
| .copy("testdata_double.arrow"), | ||
| .copy("testdata_struct.arrow") | ||
| ], |
There was a problem hiding this comment.
The test target declares .copy("testdata_*.arrow") resources, but those .arrow files are not present under Tests/ArrowTests/ in this branch. SwiftPM validates resource paths when loading the package, so this will break swift build/dependency resolution unless the files are checked in (or generated by a build tool plugin). Either commit these files (and keep them tracked), or switch to a generation approach that guarantees the resources exist before SwiftPM evaluates the package graph (e.g., a SwiftPM build-tool plugin), otherwise consumers will not be able to build the package.
| resources: [ | |
| .copy("testdata_bool.arrow"), | |
| .copy("testdata_double.arrow"), | |
| .copy("testdata_struct.arrow") | |
| ], |
There was a problem hiding this comment.
I've committed the three .arrow files. The CI still regenerates them from the Go data generator, so the data should be fresh. This is the only way I was able to find.
| cp *.arrow ../../Tests/ArrowTests/ | ||
| - name: Select iOS Simulator | ||
| run: | | ||
| SIMULATOR_ID=$(xcrun simctl list devices available 2>/dev/null | \ |
There was a problem hiding this comment.
Could you add a comment that shows example output of xcrun ... and each filter something like the following?
# Example:
# (xcrun ... output)
# ->
# (awk ... output)
# ->
# (sort ... output)
# ->
# (head -1 output)
# ->
# (grep ... output)It'll help us when the command line doesn't work as expected.
There was a problem hiding this comment.
Added a example from real macos-15 runner output.
.gitignore
Outdated
| Tests/ArrowTests/*.arrow | ||
| data-generator/swift-datagen/*.arrow |
There was a problem hiding this comment.
Added as suggested.
| .copy("testdata_bool.arrow"), | ||
| .copy("testdata_double.arrow"), | ||
| .copy("testdata_struct.arrow") |
There was a problem hiding this comment.
Can we copy them from ../../data-genrator/swift-datagen/?
There was a problem hiding this comment.
Unfortunately SwiftPM's .copy() only accepts paths within the target's source directory, so referencing ../../data-generator/swift-datagen/ isn't possible. Instead I've committed the three generated .arrow files directly (they're small -- 650 to 810 bytes). This ensures the package resolves cleanly without needing to run the Go generator first. The CI still regenerates them, so if the generator changes, any drift will be caught.
There was a problem hiding this comment.
OK. But we don't want to add auto generated files into this repository.
Let's copy to Tests/ArrowTests/ manually (or by script) instead of adding them to this repository.
- Commit generated .arrow test data files so SwiftPM resource declarations resolve without running the Go generator first - Replace fatalError in testDataURL with throws for cleaner test failure reporting - Add example pipeline output comments to simulator selection script for easier debugging - Prepend / to .gitignore patterns to match repo conventions Made-with: Cursor
ad7fb9c to
7341ee5
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 8 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| xcodebuild test \ | ||
| -scheme Arrow-Package \ | ||
| -destination "platform=iOS Simulator,id=$SIMULATOR_ID" \ | ||
| -only-testing ArrowTests |
There was a problem hiding this comment.
The new iOS CI job only runs xcodebuild test with -only-testing ArrowTests, which won’t compile (or run) ArrowFlightTests and may not even build the ArrowFlight target. This leaves a gap where the package can be declared iOS-supported but still regress for ArrowFlight on iOS without CI catching it. Consider adding an additional xcodebuild build step for the ArrowFlight scheme (or otherwise ensuring all package products compile) on the selected simulator destination.
| -only-testing ArrowTests | |
| -only-testing ArrowTests | |
| - name: Build ArrowFlight for iOS Simulator | |
| run: | | |
| xcodebuild build \ | |
| -scheme ArrowFlight \ | |
| -destination "platform=iOS Simulator,id=$SIMULATOR_ID" |
| "Test data file \(filename).arrow not found in bundle. " | ||
| + "Run the Go data generator first." |
There was a problem hiding this comment.
The failure message in testDataURL tells contributors to “Run the Go data generator first,” but the .arrow files are now checked into Tests/ArrowTests and bundled as SwiftPM resources. This can be misleading when the real issue is a missing/incorrect test resource configuration. Consider updating the message to mention verifying the test resources in Package.swift (and running the generator only when regenerating/updating the committed testdata).
| "Test data file \(filename).arrow not found in bundle. " | |
| + "Run the Go data generator first." | |
| "Test data file \(filename).arrow not found in test bundle. " | |
| + "Verify that the .arrow test resources are correctly declared in Package.swift, " | |
| + "and run the Go data generator only when regenerating or updating the committed test data." |
| let package = Package( | ||
| name: "Arrow", | ||
| platforms: [ | ||
| .macOS(.v10_15) | ||
| .macOS(.v10_15), | ||
| .iOS(.v15) | ||
| ], |
There was a problem hiding this comment.
Declaring .iOS(.v15) at the package level makes it easy for consumers to expect both Arrow and ArrowFlight to be usable on iOS. Right now the iOS CI job only exercises ArrowTests, so it’s possible for ArrowFlight to drift out of iOS compatibility unnoticed. Consider either (a) expanding iOS CI to compile/build the ArrowFlight product too, or (b) explicitly documenting that iOS support applies only to the core Arrow library if that’s the intent.
What's Changed
I'm working on an iOS project that depends on this library. It already compiles and runs correctly on iOS, but there is no official platform declaration or CI coverage. This PR formalises that support so it stays tested and other iOS developers can adopt it with confidence.
.iOS(.v15)toPackage.swiftplatforms#file-based paths toBundle.moduleresources (the#fileapproach doesn't work in Xcode test bundles)macos-15runner, dynamic simulator selection)Testing
swift test(macOS/Linux) and lint jobs pass unchangedmacos-15runner (verified on fork)xcodebuild teston an iPhone simulatorAI disclosure
An AI coding assistant (Cursor) was used during development. I reviewed, tested, and debugged all changes myself and can fully own them.
Closes #142.