Le migliori piattaforme CI/CD per app Cordova nel 2026: un confronto

La migliore piattaforma CI/CD per un'app Cordova nel 2026 è solitamente una CI generica in grado di eseguire la CLI di Cordova su Linux per Android e su macOS per iOS: GitHub Actions, GitLab CI, Bitrise, Codemagic, Appcircle, CircleCI o Azure DevOps. Ciò che nessuna di esse può sostituire è il servizio live update gestito che i team Cordova ricevevano da App Center e Appflow. Questo confronto analizza il supporto alla build, la firma, la pubblicazione sugli store, le live updates e le prospettive a lungo termine di ogni opzione.

Lo stato attuale della CI/CD per Cordova

Tre servizi gestiti hanno costruito l'ecosistema Cordova, e sono tutti scomparsi o in chiusura:

Il framework Cordova pubblica ancora release delle piattaforme. Il lavoro che ora è a tuo carico è tutto ciò che gira intorno al build: archiviazione delle firme, upload sugli store, numeri di versione e aggiornamenti over-the-air.

Se ti serve solo una pipeline funzionante oggi, parti da CI/CD per app Cordova, che dispone di un workflow GitHub Actions completo. Questo articolo ti aiuta a scegliere dove eseguirlo.

Cosa deve confrontare un team Cordova

1. Supporto per Cordova. La piattaforma offre step o template per Cordova, o devi scrivere tu lo cordova build script? Lo scripting va bene; sono sempre gli stessi tre comandi ovunque.
2. Runner macOS con Xcode 26, richiesto da App Store Connect dal 28 aprile 2026.
3. Archiviazione delle firme per il keystore Android, i certificati iOS e i provisioning profile.
4. Pubblicazione store su TestFlight e sulle track di Google Play.
5. Live Update per fix dello strato web.
6. Hosting Git e self-hosting, fondamentale per app enterprise e governative che spesso usano ancora Cordova.

Tabella comparativa

Capgo si affianca alla CI che scegli anziché sostituirla: la tua CI esegue la build dei binari Cordova, e Live updates di Capgo distribuisce modifiche web-only alle app installate. Build Capgo è documentato per i progetti Capacitor, quindi non è un'opzione per la build di un binario Cordova.

Piattaforma per piattaforma

Azioni GitHub

La scelta più comune per i team Cordova su GitHub. I build Android su ubuntu-latest con actions/setup-java. I build iOS su macos-26 con Xcode 26 preinstallato. Decodifichi la keystore e .p12 dai secrets, scrivi un build.json, ed esegui cordova build. Gli upload usano fastlane, xcrun altool, o action di community per l'upload su Play. Nessuna feature specifica per Cordova, ma nulla ti ferma. Controlla i costi al minuto di macOS sui repository privati.

GitLab CI

Stesso approccio basato su script. Su GitLab.com sono disponibili runner macOS per i piani Premium e Ultimate (in beta), con immagini come macos-26-xcode-26. Le istanze GitLab self-managed, usate da molti team Cordova in settori regolamentati, richiedono runner Mac dedicati. Secure files è l'ideale per keystore e provisioning profile. Vedi Configura la CI/CD su GitLab.

Bitrise

La CI mobile con il supporto Cordova più esplicito. La sua libreria di step include step Cordova per preparare il progetto e archiviare le build iOS e Android, oltre alla gestione delle firme code e al deploy sugli store. Se vuoi un workflow guidato dalla UI e non hai problemi con un pricing a crediti, è la cosa più vicina alla vecchia esperienza di build di App Center.

Codemagic

Codemagic documenta le build Ionic Cordova in codemagic.yaml, con Android keystore gestiti, firma iOS automatica tramite chiave API di App Store Connect e pubblicazione su TestFlight e Google Play. Il pricing è a minuto di build oppure con un piano annuale fisso. Ideale per i team a cui piace lo YAML nel repository ma vogliono la firma gestita.

Appcircle

Appcircle esegue il build di Cordova tramite script personalizzati nei workflow, sopra le sue pipeline di build iOS e Android, e aggiunge storage delle identità di firma, distribuzione ai tester, un enterprise app store e la pubblicazione sugli store. Appcircle Server può girare interamente sulla tua infrastruttura: la proposta self-hosting più solida di questa lista.

CircleCI

Build Cordova tramite script su executor Linux Docker per Android e executor macOS Apple Silicon per iOS. Firma e upload passano da fastlane o dalla shell. Una scelta ragionevole se CircleCI gestisce già il tuo backend.

Azure DevOps

Azure Pipelines esegue il CLI di Cordova come step di script e aggiunge task first-party per installare certificati Apple e provisioning profile da secure file, per la firma Android e per il rilascio sugli store tramite estensioni del marketplace. Azure DevOps Server copre le esigenze on-premises. Molti ex clienti App Center sono finiti qui.

Xcode Cloud

Possibile solo per la parte iOS. Un ci_scripts/ci_post_clone.sh hook installa Node, ripristina le piattaforme Cordova e builda il layer web prima che Xcode Cloud archivi il progetto generato. Poiché Cordova genera platforms/ios al momento della build, il percorso del workspace deve esistere all'avvio del workflow, il che rende la configurazione scomoda. La maggior parte dei team Cordova lo usa solo se già lo impiega per app native.

VoltBuilder

Un servizio di build più che una CI: carichi uno zip del progetto con i file di firma e ricevi i binari pronti per lo store per progetti Cordova e Capacitor. Niente trigger Git, pipeline o live updates. Utile per piccoli team senza una CI. Vedi la Alternativa a Voltbuilder pagina di confronto.

Alternative a Ionic Appflow

Resta la piattaforma Cordova più completa, con build, firma, pubblicazione e live updates. È però anche quella con una data di fine supporto. Se usi Appflow, la domanda non è se lasciarlo, ma quando. Vedi Alternativa ad Appflow.

Colmare il gap di live update

Ogni CI generica in questo elenco produce binari firmati. Nessuna di esse offre aggiornamenti over-the-air per le app installate, e i vecchi plugin della community per il push code non sono più mantenuti. Per Cordova, le opzioni rimaste sono Appflow fino alla fine del 2027, un server di update self-hosted o Capgo.

Capgo supporta Cordova tramite @capgo/cordova-updater, che rispecchia l'updater Capacitor API e utilizza lo stesso backend, canali e CLI. Richiede Cordova iOS 7+ e Cordova Android 13+, e non deve essere combinato con cordova-plugin-ionic-webview. Installalo con il tuo ID app Capgo:

cordova plugin add @capgo/cordova-updater --variable APP_ID=com.example.app
cordova prepare android ios

Chiama cordova.plugins.Updater.notifyAppReady() dopo deviceready ad ogni avvio, quindi aggiungi uno step alla tua CI per i release web-only:

bun run build
bunx @capgo/cli@latest bundle upload --channel=production

L'aggiunta o l'aggiornamento di plugin richiede comunque un build per lo store; Capgo segnala i bundle i cui plugin nativi differiscono da quelli live. Dettagli nella Documentazione updater Cordova e compatibilità live update. L'intera pipeline, incluso il job live update, si trova in CI/CD per app Cordova.

Opzionale: cosa aggiunge passare a Capacitor in CI

Non è necessario migrare per ottenere i live updates. I team che scelgono di farlo lo fanno principalmente per la parte di build.

Capacitor esegue la maggior parte dei plugin Cordova così come sono, mantiene il tuo code web e effettua il commit dei progetti nativi su Git invece di generarli, rendendo le build CI più prevedibili. Il tuo app ID Capgo e i canali vengono mantenuti, cambia solo il plugin updater. Una volta migrato:

• Il tuo job CI su Linux esegue bun run build, bunx cap sync, e uno bunx @capgo/cli@latest build request per piattaforma. Non serve un runner macOS per iOS.
• I rilascio solo web vengono distribuiti come live updates con canali, rollback e controlli di compatibilità: bunx @capgo/cli@latest bundle upload --channel production.
• bunx @capgo/cli@latest build needed indica alla pipeline se sia effettivamente necessaria una Native Build.

Guida alla migrazione: Migrare da Cordova a Capacitor. Se ti serve aiuto, consulta Da Cordova a Capacitor.

Come scegliere

Checklist di migrazione da App Center o Appflow

• Scarica l'upload keystore Android e la distribuzione iOS .p12 con chiavi private. Se la vecchia piattaforma le ha generate, esportale prima di perdere l'accesso.
• Registra i version code e i build number attuali per evitare collisioni con la prima build sulla nuova piattaforma.
• Crea un account di servizio Google Play e una chiave API per App Store Connect per il nuovo CI.
• Elenca ogni variabile d'ambiente iniettata dalla vecchia piattaforma al momento del build.
• Esegui un build su canale interno e uno su TestFlight prima di passare alla produzione.
• Definisci il tuo piano live update prima che il vecchio servizio venga disattivato, non dopo.

Per approfondire le decisioni su iOS e Android, leggi Confronto tra piattaforme CI/CD per app iOS e Confronto tra piattaforme CI/CD per app Android.