Mobile: Oracle support on iOS

[datlechin]

Problem

TablePro Mobile ships six drivers covering eight database types: SQLite, DuckDB, MySQL, MariaDB, PostgreSQL, Redshift, Redis, SQL Server (IOSDriverFactory.supportedTypes() and DatabaseType.mobileSupportedTypes). Oracle is macOS only.

So an Oracle connection synced from the Mac cannot be opened on iPhone or iPad. It is not in the connection type picker either, so it cannot be created on device. Opening one falls through IOSDriverFactory.createDriver to ConnectionError.driverNotFound. The Oracle icon is already bundled in both TableProMobile/Assets.xcassets and TableProWidget/Assets.xcassets, and DatabaseTypeStyle already maps "Oracle", so the type shows up in the UI with no way to connect.

Why Oracle is the cheapest one to add

The macOS Oracle driver is pure Swift on the TableProApp/oracle-nio fork. No Instant Client, no OCI, no C bridge, nothing to build into Libs/ios. The fork (pinned at 23c7781) already declares .iOS(.v16) and TablePro Mobile deploys to iOS 18.0, so it builds for the simulator and device as-is.

This is unlike MSSQL, which needed a FreeTDS xcframework before it could ship on iOS.

Proposed solution

Follow the TableProMSSQLCore precedent: extract the engine logic into a shared module, keep the platform driver thin.

1. New TableProOracleCore module in Packages/TableProCore (alongside TableProMSSQLCore, TableProTrinoCore, TableProTeradataCore), depending on the oracle-nio fork.
2. Move the engine logic out of Plugins/OracleDriverPlugin/ (2,247 lines across OracleConnection.swift, OraclePlugin.swift, OracleCellFormatting.swift, OracleSSLMapping.swift, OracleListenerRefusal.swift) into that module, so the Mac plugin and the iOS driver share one implementation instead of two that drift.
3. TableProMobile/TableProMobile/Drivers/OracleDriver.swift conforming to TableProDatabase.DatabaseDriver, shaped like MSSQLDriver.swift.
4. Register it in IOSDriverFactory.createDriver(for:password:) and supportedTypes().
5. DatabaseType+Mobile.swift: add .oracle to mobileSupportedTypes, "Oracle" to mobileDisplayName, 1521 to defaultPort.
6. Connection form: Oracle needs the service name vs SID choice, which lives in additionalFields. ConnectionFormView has no additionalFields UI today, so this needs new fields. Without it, an imported Mac connection keeps its setting but a connection created on device cannot pick SID.
7. Tests in TableProMobileTests/Drivers/ next to MSSQLDriverTests and DuckDBDriverTests, plus pure-logic tests for the extracted module.
8. Update docs/databases/oracle.mdx with what works on mobile.

Open questions

• Dependency weight. Packages/TableProCore has zero remote SPM dependencies right now. Adding oracle-nio pulls swift-nio, swift-nio-ssl, swift-crypto, swift-collections, swift-atomics, BigInt and swift-syntax into every consumer of the package, including the widget extension. A separate local package that only the app and mobile targets link may be the better shape. Worth measuring the effect on widget launch and binary size before committing to putting it in TableProCore.
• Extraction scope. Full extraction of all five files, or start with OracleConnection.swift plus the formatting and SSL helpers and leave the plugin-facing surface in OraclePlugin.swift.
• Verification targets. Which Oracle versions to test against on device. Native network encryption negotiation (Oracle connection fails with uncleanShutdown on non-TLS server #483, 连接Oracle闪退 #1746) is the same code path, so 11g needs a real run, not just a simulator smoke test.

Alternatives considered

• Ship Oracle on iOS as a plugin. Not possible: iOS has no plugin loading, drivers are compiled into the app.
• Duplicate the driver in TableProMobile/Drivers/ without extracting a shared module. Rejected: two copies of 2,000+ lines of protocol handling that will drift on the next Oracle fix.