# Swift Package Manager nel 2026: Creare, Pubblicare Pacchetti e Domande da Colloquio

> Guida completa a Swift Package Manager per sviluppatori iOS. Come creare pacchetti, gestire dipendenze, pubblicare librerie e rispondere alle domande tecniche sui colloqui SPM.

- Published: 2026-09-20
- Updated: 2026-09-20
- Author: Anthony Fillion-Maillet
- Tags: swift, ios, spm, dependency-management, xcode
- Reading time: 12 min

---

Swift Package Manager (SPM) gestisce le dipendenze e la distribuzione dei pacchetti per i progetti Swift. A differenza di CocoaPods o Carthage, SPM si integra direttamente in Xcode e nella toolchain Swift, senza richiedere installazioni esterne. Swift 6.2 e 6.3 hanno introdotto impostazioni rigorose di memory safety, isolamento degli actor predefinito e il nuovo sistema Swift Build, rendendo SPM la scelta definitiva per lo sviluppo iOS moderno.

> **Cosa fa SPM**
>
> Swift Package Manager risolve le dipendenze, scarica il codice sorgente, compila i moduli e li collega nel binario finale. Un singolo file manifest `Package.swift` definisce tutto: dipendenze, target, prodotti e impostazioni di build.

## Struttura e Sintassi del Manifest Package.swift

Ogni pacchetto Swift inizia con un file `Package.swift` nella root del repository. Questo manifest utilizza codice Swift per dichiarare la struttura del pacchetto, le dipendenze e la configurazione di build.

```swift
// Package.swift
import PackageDescription

let package = Package(
    name: "NetworkKit",
    platforms: [
        .iOS(.v15),
        .macOS(.v12)
    ],
    products: [
        .library(
            name: "NetworkKit",
            targets: ["NetworkKit"]
        )
    ],
    dependencies: [
        .package(
            url: "https://github.com/Alamofire/Alamofire.git",
            from: "5.9.0"
        )
    ],
    targets: [
        .target(
            name: "NetworkKit",
            dependencies: ["Alamofire"]
        ),
        .testTarget(
            name: "NetworkKitTests",
            dependencies: ["NetworkKit"]
        )
    ]
)
```

L'array `platforms` specifica i target di deployment minimi. La sezione `products` definisce cosa altri pacchetti possono importare. La sezione `targets` elenca le unità di compilazione con le rispettive dipendenze.

## Creare un Pacchetto Swift dalla Riga di Comando

Il comando `swift package init` crea la struttura di un nuovo pacchetto con la directory standard. Il flag `--type` determina se il pacchetto produce una libreria o un eseguibile.

```bash
# Create a library package
mkdir NetworkKit && cd NetworkKit
swift package init --type=library

# Generated structure:
# NetworkKit/
# ├── Package.swift
# ├── Sources/
# │   └── NetworkKit/
# │       └── NetworkKit.swift
# └── Tests/
#     └── NetworkKitTests/
#         └── NetworkKitTests.swift
```

L'esecuzione di `swift build` compila il pacchetto. L'esecuzione di `swift test` esegue la suite di test. Entrambi i comandi utilizzano la configurazione da `Package.swift` senza configurazioni aggiuntive.

## Requisiti di Versione delle Dipendenze e Risoluzione

SPM supporta tre strategie di specifica della versione: versione esatta, range di versioni e riferimento a branch o commit. La scelta influisce sulla riproducibilità e flessibilità.

```swift
// Package.swift
dependencies: [
    // Semantic versioning: 5.9.0 up to next major
    .package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.9.0"),
    
    // Exact version: locks to 5.9.1
    .package(url: "https://github.com/Alamofire/Alamofire.git", exact: "5.9.1"),
    
    // Version range: 5.8.0 to 5.9.9
    .package(url: "https://github.com/Alamofire/Alamofire.git", "5.8.0".."5.9.9"),
    
    // Branch reference: for development
    .package(url: "https://github.com/Alamofire/Alamofire.git", branch: "main"),
    
    // Commit reference: pinned to specific commit
    .package(url: "https://github.com/Alamofire/Alamofire.git", revision: "abc123")
]
```

Il file `Package.resolved` registra le versioni esatte risolte durante la risoluzione delle dipendenze. Questo file dovrebbe essere committato nel version control per garantire build riproducibili tra i membri del team e i sistemi CI.

> **Dipendenze Branch in Produzione**
>
> I riferimenti a branch e commit bypassano il semantic versioning. Usare `branch: "main"` in un'app di produzione significa che qualsiasi push su main può rompere la build. I riferimenti a branch dovrebbero essere riservati allo sviluppo attivo di feature non ancora rilasciate.

## Aggiungere Pacchetti a un Progetto Xcode

Xcode integra SPM tramite il menu File. Il percorso passa da File, poi Aggiungi Dipendenze Pacchetto. Dopo aver inserito l'URL del repository, si seleziona la regola di versione e si sceglie quali target devono linkare la dipendenza.

```swift
// AppDelegate.swift
import UIKit
import Alamofire // Available after adding via Xcode

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        AF.request("https://api.example.com/health").response { response in
            print(response.result)
        }
        return true
    }
}
```

Xcode memorizza i riferimenti ai pacchetti nel file `.xcodeproj` e le versioni risolte in `Package.resolved` nella root del progetto. La cartella Derived Data fa cache dei pacchetti scaricati.

## Sviluppo Locale di Pacchetti con Dipendenze Path

Durante lo sviluppo, puntare a un path locale invece di un URL remoto permette iterazioni rapide senza pubblicare versioni intermedie. Questa tecnica si adatta a setup monorepo e sviluppo di feature.

```swift
// Package.swift in consuming package
dependencies: [
    // Local path for development
    .package(path: "../NetworkKit"),
    
    // Remote URL for release
    // .package(url: "https://github.com/company/NetworkKit.git", from: "1.0.0")
]
```

Il passaggio tra dipendenze locali e remote avviene commentando la riga inattiva. Xcode e la CLI Swift risolvono le dipendenze path relative al pacchetto consumatore.

## Pubblicare un Pacchetto Swift su GitHub

La pubblicazione richiede un repository Git con tag di versione semantici. SPM tratta i tag Git come versioni di release. Il [Swift Package Index](https://swiftpackageindex.com) indicizza automaticamente i pacchetti pubblici.

```bash
# Initialize repository and push
git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/username/NetworkKit.git
git push -u origin main

# Create version tag
git tag 1.0.0
git push origin 1.0.0

# Other packages can now depend on:
# .package(url: "https://github.com/username/NetworkKit.git", from: "1.0.0")
```

Le convenzioni del [semantic versioning](https://semver.org) vanno seguite: incrementare la versione major per breaking changes, minor per nuove feature e patch per bug fix. SPM assume l'aderenza a queste regole quando risolve i requisiti di versione `from:`.

## Impostazioni Pacchetto Swift 6.2 e 6.3

Swift 6.2 ha introdotto la configurazione del language mode per target e impostazioni rigorose di memory safety. Swift 6.3 aggiunge l'integrazione Swift Build come sistema di build opt-in.

```swift
// Package.swift with Swift 6.2+ features
import PackageDescription

let package = Package(
    name: "SafeNetworkKit",
    platforms: [.iOS(.v17)],
    products: [
        .library(name: "SafeNetworkKit", targets: ["SafeNetworkKit"])
    ],
    targets: [
        .target(
            name: "SafeNetworkKit",
            swiftSettings: [
                // Enable Swift 6 language mode for this target only
                .swiftLanguageMode(.v6),
                // Enable strict memory safety checking (SE-0458)
                .enableExperimentalFeature("StrictMemorySafety"),
                // Set default actor isolation (SE-0466)
                .enableExperimentalFeature("GlobalActorIsolation")
            ]
        )
    ]
)
```

L'impostazione `swiftLanguageMode` permette l'adozione graduale delle feature Swift 6 in un codebase. I target possono usare language mode differenti all'interno dello stesso pacchetto.

## Generazione SBOM per Conformità di Sicurezza

SE-0509 ha aggiunto la generazione nativa di Software Bill of Materials in Swift 6.3. I documenti SBOM elencano tutte le dipendenze e le loro versioni per audit di sicurezza e conformità normativa.

```bash
# Generate SBOM in CycloneDX format
swift build --sbom-spec cyclonedx

# Generate SBOM using dedicated subcommand
swift package generate-sbom --format spdx

# Output includes:
# - Package name and version
# - All transitive dependencies
# - License information
# - Source repository URLs
```

Gli ambienti enterprise e i contratti governativi richiedono sempre più documentazione SBOM. I formati CycloneDX e SPDX si integrano con gli strumenti standard di vulnerability scanning.

## Binary Target e Distribuzione XCFramework

I binary target permettono la distribuzione di framework precompilati invece del codice sorgente. Gli XCFramework raggruppano binari per piattaforme e architetture multiple.

```swift
// Package.swift with binary target
import PackageDescription

let package = Package(
    name: "AnalyticsSDK",
    platforms: [.iOS(.v14)],
    products: [
        .library(name: "AnalyticsSDK", targets: ["AnalyticsSDK"])
    ],
    targets: [
        .binaryTarget(
            name: "AnalyticsSDK",
            url: "https://releases.example.com/AnalyticsSDK-2.0.0.xcframework.zip",
            checksum: "abc123def456..."
        )
    ]
)

// Generate checksum:
// swift package compute-checksum AnalyticsSDK-2.0.0.xcframework.zip
```

I binary target riducono i tempi di build per i consumatori e proteggono implementazioni proprietarie. Il checksum garantisce l'integrità del download.

## Domande Comuni da Colloquio su Swift Package Manager

I colloqui tecnici per posizioni iOS includono frequentemente domande su SPM. Queste spaziano dall'uso base alle decisioni architetturali.

**D: Come si differenzia SPM da CocoaPods e Carthage?**

SPM si integra in Xcode e nella toolchain Swift senza strumenti esterni. CocoaPods usa un repository spec centrale e modifica la struttura del workspace Xcode. Carthage compila framework in uno step separato senza integrazione Xcode. SPM risolve le dipendenze e compila in un singolo processo unificato. La [documentazione Apple sui pacchetti Swift](https://developer.apple.com/documentation/xcode/swift-packages) copre gli strumenti ufficiali.

**D: Cosa succede durante la risoluzione delle dipendenze?**

SPM legge i manifest `Package.swift` ricorsivamente, costruendo un grafo delle dipendenze. Poi applica i vincoli di versione per trovare versioni compatibili per tutti i pacchetti. Il resolver scrive le versioni esatte in `Package.resolved`. I conflitti si verificano quando due pacchetti richiedono versioni incompatibili di una dipendenza condivisa.

**D: Come si gestisce un conflitto di dipendenza diamond?**

Quando il pacchetto A e B dipendono entrambi dal pacchetto C con requisiti di versione incompatibili, la risoluzione SPM fallisce. Le soluzioni includono: aggiornare un consumatore per supportare un range di versioni più ampio, fare fork del pacchetto restrittivo, o usare module aliasing se il conflitto è tra pacchetti diversi con lo stesso nome di modulo.

```swift
// Module aliasing for name conflicts
.target(
    name: "MyApp",
    dependencies: [
        .product(name: "Logging", package: "swift-log", moduleAliases: ["Logging": "SwiftLogging"])
    ]
)
```

**D: Quando usare un binary target invece della distribuzione sorgente?**

I binary target si adattano a SDK proprietari dove l'esposizione del sorgente è inaccettabile, grandi dipendenze dove il tempo di compilazione impatta la produttività degli sviluppatori, e librerie vendor precompilate. La distribuzione sorgente rimane preferibile per progetti open source e librerie interne dove il debug nelle dipendenze aggiunge valore.

## Migrazione da CocoaPods a Swift Package Manager

La migrazione richiede la sostituzione delle voci del Podfile con riferimenti a pacchetti SPM. Non tutti i CocoaPods hanno equivalenti SPM, quindi verificare la disponibilità su [Swift Package Index](https://swiftpackageindex.com) prima di iniziare.

```ruby
# Before: Podfile
pod 'Alamofire', '~> 5.9'
pod 'SwiftyJSON', '~> 5.0'
pod 'Kingfisher', '~> 7.0'
```

```swift
// After: Package dependencies in Xcode
// File > Add Package Dependencies for each:
// https://github.com/Alamofire/Alamofire.git from 5.9.0
// https://github.com/SwiftyJSON/SwiftyJSON.git from 5.0.0
// https://github.com/onevcat/Kingfisher.git from 7.0.0
```

Dopo la migrazione, rimuovere Podfile, Podfile.lock e la directory Pods. Eseguire `pod deintegrate` per rimuovere le modifiche al workspace CocoaPods. Le dichiarazioni import nei file Swift rimangono invariate.

## Best Practice SPM per App di Produzione

- Pinnare le versioni major con `from:` per stabilità ricevendo aggiornamenti minor e patch
- Committare `Package.resolved` per garantire build riproducibili in tutto il team
- Usare pacchetti locali durante lo sviluppo attivo, passando a URL remoti prima del merge
- Separare le dipendenze solo per test usando `testTarget` per evitare di includerle nelle build di release
- Documentare la versione minima Swift tools all'inizio del manifest: `// swift-tools-version: 5.10`
- Validare le build dei pacchetti su CI prima di taggare le release

> **Swift Tools Version**
>
> Il commento `// swift-tools-version:` deve apparire nella prima riga di Package.swift. Determina quale versione dell'API PackageDescription usa il manifest. Swift 6.0 ha aggiunto flessibilità per permettere questo commento in righe successive per header di licenza.

## Punti Chiave per Sviluppatori iOS che Usano SPM

- SPM si integra nativamente in Xcode, eliminando l'overhead di setup di CocoaPods e Carthage
- Il manifest `Package.swift` usa codice Swift, permettendo dichiarazioni di dipendenze type-checked
- I requisiti di versione supportano range di semantic versioning, versioni esatte e riferimenti a branch
- `Package.resolved` blocca le versioni delle dipendenze per build riproducibili
- Swift 6.2 ha aggiunto language mode per target e impostazioni rigorose di memory safety
- Swift 6.3 ha introdotto la generazione SBOM per documentazione di conformità
- I binary target distribuiscono XCFramework precompilati quando la distribuzione sorgente non è praticabile
- Le domande da colloquio si concentrano su conflitti di risoluzione, strategie di migrazione e trade-off architetturali tra SPM e alternative

Per una preparazione completa ai colloqui iOS, consultare i moduli su [SwiftUI state management](/technologies/ios/interview-questions/swiftui-state-management) e [protocol-oriented programming](/technologies/ios/interview-questions/protocol-oriented-programming) su SharpSkill.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/it/blog/ios/swift-package-manager-tutorial-2026