Quando in Windows Phone, e in generale in XAML, si fa riferimento ad un colore si utilizza la forma esadecimale o i nomi dei colori, con i quali si va ad indicare le componenti ARGB con valori che vanno da 0 a 255 per l'alpha (la trasparenza), il red, il green e il blue. Questo formato, di 32 bit, permette di utilizzare un ampio spazio di colori, di 2 alla 24 esima (la trasparenza non amplifica la gamma).

In realtà, ciò che si esprime non è detto che sia poi quello visualizzato sul display. Oltre alle differenze tecnologiche che influenzano contrasto e bilanciamenti, con la versione 7.0 di Windows Phone quello che viene visualizzato a video è una riduzione del valore, portato a 16 bit, al fine di ridurre i calcoli da effettuare e ottimizzare i consumi della batteria. Questo in molti casi non è un problema, perché difficilmente la qualità del display potrebbe far notare la differenza, se non comparandola, e i requisiti grafici di Metro non mettono in risalto limiti sulla gamma dei colori. Diminuendo infatti da 32 a 16 bit, con immagini o superfici da ampie gamme, come i gradienti, si possono sicuramente notare differenze sgradevoli; come già detto è raro dovere usare questo genere di immagini, perché non uniforme alle linee guida di Metro.

Per questo motivo anche in Windows Phone 7.5 il comportamento predefinito è sempre quello di lavorare a 16 bit, ma qualora l'applicazione o il gioco dovesse sentire la necessità di avere una gamma di colori completa, è possibile abilitare i 32 bit. Per farlo occorre intervenire sul file WMAppManifest.xml e in particolare sull'elemento App, ponendo l'attributo BitsPerPixel="32", come nell'esempio.

<Deployment xmlns="http://schemas.microsoft.com/windowsphone/2009/deployment" AppPlatformVersion="7.1">
  <App BitsPerPixel="32" ...>
    <!-- altro -->

Non serve fare altro e rilanciando l'app si ottiene automaticamente i benefici dei 32 bit. Da notare che non tutti i device supportano questa profondità di colore, perciò potrebbe non sortire alcun effetto. E' poi importante sottolineare che i 32 bit, per evitare uno spreco inutile di risorse, andrebbero abilitati solo se si ottiene un evidente vantaggio in base al tipo di applicazione.