Protobuf v38 chiuderà il supporto Objective-C: la linea 37.x offre più tempo

Protocol Buffers eliminerà il supporto a Objective-C nella versione v38, secondo l’avviso pubblicato il 21 ottobre. La linea 37.x con supporto a lungo termine offre una fase di transizione: l’annuncio più recente indica che Objective-C resterà supportato fino al primo trimestre del 2028. È una decisione sulla manutenzione di una dipendenza, non l’annuncio che le applicazioni Objective-C smetteranno di funzionare in quella data.

Il cambiamento è collegato a un’altra scadenza vicina. CocoaPods trunk dovrebbe diventare di sola lettura il 2 dicembre 2026. Insieme, le due novità rendono questo un momento utile per capire quale parte di un’applicazione per piattaforme Apple dipenda davvero dall’implementazione Objective-C di Protobuf.

Gestore dei pacchetti e runtime sono dipendenze diverse

Protocol Buffers descrive messaggi strutturati attraverso file di schema e genera il codice per leggerli e scriverli in linguaggi differenti. Le librerie runtime forniscono le funzioni comuni usate da quel codice. Un’applicazione può quindi dipendere da Protobuf attraverso una libreria o un SDK, anche se il suo gruppo di sviluppo modifica raramente uno schema.

La distinzione cambia la prima domanda da porsi. Trovare CocoaPods in un progetto non dimostra che venga usato Protobuf per Objective-C. Trovare Protobuf non dimostra che sia coinvolta proprio quell’implementazione. Un inventario utile segue la catena delle dipendenze, senza trasformare uno dei due nomi nel motivo per riscrivere tutto.

Il nuovo avviso sul supporto precisa inoltre che non è prevista la pubblicazione di questa implementazione Objective-C tramite Swift Package Manager, citando domanda e supporto al codice non-ARC. Cambiare gestore dei pacchetti non è quindi una soluzione sostitutiva promessa per continuare a usare lo stesso componente sulla nuova linea di versioni.

Sola lettura non significa cancellazione dell’archivio

Il piano CocoaPods, pubblicato originariamente nel 2024 e poi aggiornato, riguarda l’invio di nuovi contenuti al repository centrale trunk. Indica che le build esistenti dovrebbero continuare a funzionare e distingue i repository privati e le dipendenze incluse direttamente nei progetti. Il passaggio di dicembre non viene descritto come la cancellazione dei pacchetti già archiviati.

Ciò che si perde è la possibilità di ricevere nuove versioni pubblicate attraverso quel canale. Una vecchia dipendenza che continua a installarsi rassicura sulla riproducibilità, ma non dimostra che sia ancora mantenuta. Le due domande devono restare separate quando si valuta lo stato di un’applicazione.

Sono piani pubblicati, non cambiamenti futuri già avvenuti. La rimozione in Protobuf è legata alla v38; la data di CocoaPods riguarda il repository. Riunirli in un unico “finisce tutto a dicembre” traviserebbe entrambe le decisioni.

Codice generato e runtime devono restare compatibili

Le regole di compatibilità tra versioni di Protobuf mettono in guardia dall’abbinare codice appena generato a un runtime precedente. Un generatore più nuovo può produrre chiamate che la vecchia libreria non fornisce. Bloccare soltanto il runtime e lasciare avanzare la generazione non costituisce quindi una strategia di transizione completa.

Per chi mantiene un’applicazione meno recente per piattaforme Apple, il lavoro concreto è registrare generatore, file generati, runtime e canale di distribuzione, poi individuare chi gestisce la libreria coinvolta. Se arriva attraverso un altro SDK, il percorso previsto dal suo manutentore conta più della preferenza per un gestore dei pacchetti. Si può iniziare questa analisi senza interrompere una versione funzionante.

Il periodo di supporto della linea 37.x offre tempo per decidere con criterio. Il vantaggio non è poter dimenticare più a lungo una vecchia build. È spostare la dipendenza interessata prima che la semplice possibilità di installarla diventi l’unica prova rimasta per continuare a fidarsene.