feat: support SPM by using capacitor migration tool

[paulstelzer]

Add support for SPM using the official capacitor tool https://github.com/ionic-team/capacitor-plugin-converter

All changes made by the tool. I am only adjusted the Package.swift to add ZIPFoundation and SQLCipher.

I have tested in my own project and it seems to work. Would be great if other could test it too. I am only tested with unencrypted data (not with decrypted data)

Fixes #568

[robingenz]

Here is a dev version for testing:

npm i @capacitor-community/sqlite@7.0.2-dev.5a79381.1766041651

[marcosav]

Hi, I have tested it with encrypted data and works with no issues.

[true-perfect-code]

@robingenz

Thank you for taking care of the further development of the plugin! Good luck with it.

We have installed the development version, but we are getting SCALAR VIOLATION errors. Looking at GitHub, it seems that this problem was already solved in 2022 (see #319 )

Currently, we obtain values as follows

const result = await this._db.query({
    database: this._dbName,
    statement: sql,
    values: cleanValues
});

if (result && Array.isArray(result.values) && result.values.length > 0) {
    const rows = result.values;
    const firstRow = rows[0];
    const keys = Object.keys(firstRow);

    /**
     * STRICT CHECKING (Methodology: Fail-Fast)
     * If more than one row OR more than one column is returned,
     * there is a logical error in the SQL.
     */
    if (rows.length > 1 || keys.length > 1) {
        const violationMsg = `SCALAR VIOLATION: SQL delivered ${rows.length} rows and  ${keys.length} columns. Exactly what is expected 1x1.`;
        pE_Common.log(violationMsg, "error");

        // Error case: We abort so that the developer can correct the SQL.
        finalModel = pE_Common.toScalar(null, false, violationMsg);
        return JSON.stringify(finalModel);
    }

Now we would have to do it this way (so that it also works on Android)

if (result && Array.isArray(result.values) && result.values.length > 0) {
    // --- NEW: iOS Metadaten-Shift ---
    let rows = result.values;

    // If the first object only contains the column names for iOS, we remove it for validation.
    if (rows.length > 1 && rows[0].hasOwnProperty('ios_columns')) {
        pE_Common.log("iOS Metadaten-Header erkannt und für Validierung entfernt.", "info");
        rows = rows.slice(1); // Erstellt eine Kopie ohne den Header
    }
    // --------------------------------

Which is correct, option 1 or 2?

Thanks
pc

EDIT:
After investigating the codebase, we found that in the current master branch, there's an addToResponse function in UtilsSQLCipher.swift that explicitly filters out ios_columns entries:

let keysInArray1 = ["ios_columns"]
mRespSet = mRespSet.filter({ dict2 in
    // ... filtering logic to remove ios_columns
})

This indicates that somewhere in the iOS code, ios_columns is still being generated (likely in fetchColumnData or similar), but should be filtered out before returning results to the JavaScript layer.
Our hypothesis: The Capacitor Migration Tool may have either:

1. Not correctly migrated this filter logic, or
2. The filter isn't being called in certain query code paths (e.g., direct query() calls)

Impact: This breaks API consistency between Android and iOS. Our workaround (Option 2) works but forces platform-specific handling in JavaScript, which defeats the purpose of a cross-platform plugin.
Expected behavior: Option 1 should be correct - the plugin should return clean data arrays on both platforms without the ios_columns header. The filtering should happen in the native Swift layer before data reaches JavaScript.
Could you verify that addToResponse (or similar filtering) is properly called in all query paths in the SPM version?

[jibbewillem]

I tested this build and went from

⚡️  [warn] - DataSource initialization error: "CapacitorSQLite" plugin is not implemented on ios
⚡️  [error] - Failed to initialize database: {"code":"UNIMPLEMENTED"}

to a working app.

[robingenz]

We should only allow patch and minor versions here to prevent breaking changes. Same for zipfoundation.

[robingenz]

Please restore the order of the properties so that it's easier to identify the important changes.

[robingenz]

Please resolve the merge conflicts.

[true-perfect-code]

Hi @robingenz @paulstelzer,

quick follow-up: Any timeline or update on when this PR might progress?

The key goal is consistent cross-platform query results—no more iOS-specific ios_columns metadata causing SCALAR VIOLATION errors or forcing platform checks in JS. Without fixing the native filtering inconsistency, the SPM support won't deliver a truly unified API.

Thanks for any info!

[robingenz]

@true-perfect-code Feel free to debug it and suggest a solution. It would be great if you could coordinate with @paulstelzer to include the fix in the PR.

[true-perfect-code]

Thanks for the quick reply and the invitation @robingenz!

We coming from a pure .NET C# background and using Capacitor only from the Blazor WASM / JS side, we're unfortunately not in a position to propose changes to the native Swift/Objective-C layer.

Any suggestions from a team without deep native iOS experience could unfortunately introduce subtle issues that would then require even more time and effort from the actual native developers to review and correct.

For that reason we'd prefer to leave the native-side work to folks more familiar with that part of the codebase. We're happy to keep helping with reproduction steps, logs or web/JS-side observations if useful.

Thanks again for maintaining the project!