Quali limitazioni e differenze ci sono tra le app della Piattaforma Universale? Cosa possono fare gli sviluppatori per continuare a supportare un’applicazione e con quali restrizioni si può decidere di escludere una determinata fetta di dispositivi e utenti?
Spesso agli utenti non è chiaro perché gli sviluppatori decidano di supportare o meno un’app e quali siano le reali motivazioni dietro queste scelte. In questo articolo analizzeremo le app UWP, in particolare parleremo di distribuzione, pacchetti e compatibilità.

Le modalità di distribuzione

Un editore può decidere di distribuire la propria app tramite diversi mezzi.

  • Tramite il Windows Store
    Con questo metodo, gli editori – ovvero coloro che pubblicano l’app – possono avere un controllo maggiore sulla distribuzione delle app, andando a selezionare diversi parametri relativi a prezzo, paesi, piattaforme supportate, visibilità (pubblica, privata, nascosta). L’app deve, ovviamente, rispettare delle regole e degli standard di qualità e ciò viene effettuato durante la certificazione, che dura, generalmente, 1-5 giorni (dipende se viene effettuata da un bot o da persone).
  • All’infuori del Windows Store
    Un editore può decidere di rilasciare la propria app all’infuori del Windows Store, facendo scaricare almeno un pacchetto che verrà poi installato manualmente dall’utente. Ciò permette di rilasciare un’app in beta privata in tempi brevi o di rilasciare un’app non pubblicabile o rimossa dal Windows Store. In questo caso, però, l’editore può perdere il controllo del pacchetto e l’utente rischia di installare del contenuto non certificato e, quindi, non certamente sicuro.

I pacchetti

Se avete sempre utilizzato il Windows Store per scaricare le vostre app, potreste non avere familiarità con i formati Appx, AppxBundle, AppxUpload ed EAppx.
I file Appx e AppxBundle non sono altro che file ZIP, ovvero cartelle compresse che contengono altri file. I pacchetti vengono certificati per non permetterne l’uso improprio, come condivisione o modifica non autorizzata.
I file AppxBundle contengono al loro interno diversi file Appx appartenenti allo stesso prodotto, ma non tutti i pacchetti Appx all’interno di un AppxBundle verranno installati: sarà Windows a decidere quali pacchetti installare, in base alla loro funzione e al loro contenuto.

In un AppxBundle possono essere presenti:

  • I pacchetti principali
    Un Appx di questo tipo contiene il prodotto in sé (come app, temi, estensioni.).
    Tra i file che troviamo all’interno possiamo individuare eseguibili, librerie, immagini, tile, manifesti (file di testo XML che contengono dati importanti riguardo l’app), font, certificati, ecc.
    Possono essere presenti più pacchetti principali, dato che, per ogni architettura (x86, x64, ARM) viene creato un Appx contenente una copia dell’app appositamente compilata.
  • Altre risorse
    Questi sono pacchetti opzionali e vengono creati qualora lo sviluppatore volesse supportare, tramite questa opzione, più lingue, diverse dimensioni dello schermo o altre risorse di accessibilità.

L’Appx non è solamente un formato utile alla distribuzione di app. Possiamo, infatti, dividere i pacchetti in tre categorie:

  • Applicazioni
    Questi pacchetti installano un’applicazione, ovvero un programma con interfaccia utente e con il quale è possibile interagire.
  • Estensioni
    Questi pacchetti estendono le funzionalità di un’applicazione o del sistema operativo. Tutte le applicazioni possono essere estese – se supportato – e anche i pacchetti delle app potrebbero contenere estensioni per altre app.
    Le estensioni più comuni sono:
    • WebExtensions per Microsoft Edge.
    • Temi – Disponibili da Creators Update per PC ed eredi del formato Themepack.
    • DLC (DownLoadable Content, ovvero contenuto scaricabile) – Utilizzati soprattutto per i giochi.
    • Codec – Utili per aggiungere il supporto a diversi formati in tutti i player del sistema (se non usano motori proprietari).
  • Dipendenze
    Vi è mai capitato che un programma (anche nei sistemi precedenti a Windows 10) vi abbia richiesto altri componenti come il .NET Framework o altre librerie per funzionare? Con la piattaforma universale, questo processo è stato notevolmente semplificato con la creazione di diversi pacchetti dedicati, uno per ogni libreria e versione.
    Queste librerie sono comuni per tutte le app, quindi basterà installarle solo la prima volta, quando un’app ne avrà bisogno. Una panoramica generale di queste dipendenze è disponibile in questo nostro articolo dedicato.
    Le dipendenze possono essere distribuite:
    • Tramite il Windows Store
      La procedura non richiede alcun intervento da parte dell’utente. Sarà Windows a scaricare dal Windows Store le dipendenze necessarie prima dell’installazione.
    • Tramite la distribuzione manuale dei pacchetti
      Qui la procedura è più complessa. L’editore deve distribuire, assieme al pacchetto della propria app, anche i file Appx con tutte le dipendenze necessarie per ogni architettura. L’utente dovrà prima installare tutte le dipendenze e poi procedere all’installazione dell’app.
  • I file AppxUpload sono pacchetti creati appositamente per essere caricati sul DevCenter, mentre i file EAppx sono versioni criptate dei file Appx e AppxBundle non leggibili come file compressi.

Compatibilità

Non tutte le app universali sono installabili su tutti i dispositivi Windows 10. Qui di seguito vi elencheremo delle restrizioni che gli sviluppatori possono decidere di applicare direttamente all’interno delle loro app.

NOTA | Non sono incluse le limitazioni applicabili dal pannello di controllo del DevCenter. Le classificazioni riportate qui vengono applicate direttamente all’interno del pacchetto e sono quasi impossibili da bypassare senza l’accesso al progetto originale.

  • Famiglia di dispositivi
    Anche se basati su un kernel comune, ogni tipo di dispositivo ha le sue particolarità, come hardware esclusivo, restrizioni o modalità d’uso differenti. Un’app creata o portata con Project Centennial, ad esempio, funzionerà solo su PC.
    Uno sviluppatore può scegliere di supportare queste famiglie (questi possono anche essere combinati tra di loro, con diverse opzioni per ogni famiglia):
    • Universal – Tutti i dispositivi Windows 10, il più diffuso e utilizzato (ovviamente esclude tutti gli altri)
    • Mobile
    • Desktop
    • Xbox – Da Xbox One in poi
    • IoT – Windows 10 Core, edizione per i dispositivi orientati all’internet delle cose
    • Holographic – HoloLens e Realtà Mista
    • Altre meno diffuse o in arrivo
  • Architettura
    Le architetture supportate, al momento, sono x86, x64 e ARM. Anche ARM64 è tecnicamente supportato, ma non sono ancora presenti delle implementazioni pubbliche.
    Se, ad esempio, viene effettuato il porting di un’app per Windows 7 tramite Project Centennial, questa non funzionerà su processori ARM.
    Come già scritto prima, ogni applicazione o dipendenza viene compilata per una singola architettura. Se un’app supporta x86, x64 e ARM, questa verrà compilata tre volte in tre pacchetti diversi.
  • Versione minima supportata e versione obiettivo
    Con ogni aggiornamento importante di Windows 10 (TH2, Anniversary Update, Creators Update, Fall Creators Update, ecc.) viene anche aggiornato il set di funzioni utilizzabili dagli sviluppatori. Questi possono impostare due parametri per decidere quale set utilizzare e fino a quanto l’app risulterà retro-compatibile:
  • Versione minima supportata
    L’app è installabile solo sui sistemi aggiornati ad almeno la versione di Windows 10 richiesta dall’app.
  • Versione obiettivo
    L’app utilizzerà il set di istruzioni della versione di Windows 10 impostata. Deve essere maggiore o uguale alla versione minima.

Le scelte degli sviluppatori

  • Non aggiornare la versione obiettivo dell’app
    Le app create per una versione precedente di Windows 10 continueranno a funzionare anche con gli aggiornamenti successivi. Lo sviluppatore può decidere di non effettuare modifiche al codice e di mantenere la retrocompatibilità senza, però, utilizzare le nuove funzioni proposte con l’ultimo aggiornamento.
    Esempio – Un’app con versione obiettivo Anniversary Update non potrà avere l’effetto dello sfondo sfocato di Neon, dato che fa parte del set di Creators Update; l’app funzionerà comunque su Creators Update.
  • Aggiornare l’app per supportare le nuove funzioni, continuando a supportare le versioni precedenti di Windows 10
    In questo caso lo sviluppatore dovrà inserire – direttamente nel codice – delle condizioni che impediscano l’esecuzione di codici non supportati. L’app risulterà al passo coi tempi e raggiungerà più utenti possibili, ma il codice verrà “sporcato” da queste condizioni aggiuntive e l’app potrebbe risultare più soggetta a crash o rallentamenti rispetto alle versioni dedicate.
    Esempio – Un’app in esecuzione su Anniversary Update potrebbe crashare o restituire valori non previsti nel caso venissero chiamate determinate funzioni di Creators Update.
  • Rendere l’app compatibile esclusivamente con l’ultima versione di Windows 10
    In questo caso, non solo l’app sfrutterà a pieno le funzionalità dell’ultimo aggiornamento, ma il codice ottenuto risulterà più pulito. Ovviamente, il numero degli utenti che potranno utilizzare l’app aggiornata sarà nettamente minore.

Conclusioni

Per come è strutturata la piattaforma universale di Windows, molte app potrebbero continuare a funzionare senza problemi anche in futuro. Con Windows 10, Microsoft ha creato quella che riteniamo la piattaforma definitiva (per Windows). I cambiamenti (fin troppo marcati, a nostro avviso) avvenuti da Windows Phone 7 a Windows 10 hanno portato gli sviluppatori a dover riscrivere quasi totalmente il codice o ad abbandonare la piattaforma.

Avete delle domande o delle curiosità a riguardo? Lo spazio dei commenti è a vostra disposizione, fateci sapere.

Articolo di Windows Blog Italia