Una trappola importante in cui mi sono imbattuto oggi è la seguente:
In molti progetti ho visto un'unica destinazione dell'app e con diversi identificatori di bundle impostati per ogni configurazione di quella destinazione. Qui le cose si complicano. L'obiettivo degli sviluppatori era creare un'app di debug per la configurazione di debug e un'app di produzione per l'obiettivo di rilascio.
Se lo fai, entrambe le app condivideranno gli stessi NSUserDefaults quando sono impostate in questo modo
var userDefaults = NSUserDefaults(suiteName: "group.com.company.myApp")
userDefaults!.setObject("user12345", forKey: "userId")
userDefaults!.synchronize()
Ciò causa problemi in molti punti:
- Immagina di impostare SÌ per una chiave quando una speciale schermata introduttiva dell'app è stata mostrata all'utente. Anche l'altra app ora leggerà SÌ e non mostrerà l'introduzione.
- Sì, alcune app memorizzano anche token oAuth nelle impostazioni predefinite dell'utente. Comunque ... A seconda dell'implementazione, l'app riconoscerà che c'è un token e inizierà a recuperare i dati usando il token sbagliato. È molto probabile che questo fallisca con strani errori.
La soluzione a questo problema in generale è anteporre alle chiavi di default la configurazione corrente creata. È possibile rilevare facilmente la configurazione in fase di esecuzione impostando diversi identificatori di bundle per le proprie configurazioni. Quindi leggi l'identificatore del bundle da NSBundle.mainBundle(). Se hai gli stessi identificatori di bundle, devi impostare diverse macro del preprocessore come
#ifdef DEBUG
NSString* configuration = @"debug";
#elif RELEASE
NSString* configuration = @"release";
#endif
In Swift sembrerà quasi lo stesso:
#if DEBUG
let configuration = "debug"
#elseif RELEASE
let configuration = "release"
#endif