Uma armadilha importante que descobri hoje é a seguinte:
Em muitos projetos, vi um único destino de aplicativo e com diferentes identificadores de pacote definidos para cada configuração desse destino. Aqui as coisas ficam complicadas. O que os desenvolvedores pretendiam era criar um aplicativo de depuração para a configuração de depuração e um aplicativo de produção para o destino de lançamento.
Se você fizer isso, os dois aplicativos compartilharão os mesmos NSUserDefaults quando forem configurados dessa forma
var userDefaults = NSUserDefaults(suiteName: "group.com.company.myApp")
userDefaults!.setObject("user12345", forKey: "userId")
userDefaults!.synchronize()
Isso causa problemas em muitos lugares:
- Imagine que você definiu SIM para uma tecla quando uma tela de introdução de aplicativo especial foi mostrada ao usuário. O outro aplicativo agora também lerá SIM e não mostrará a introdução.
- Sim, alguns aplicativos também armazenam tokens oAuth em seus padrões de usuário. De qualquer forma ... Dependendo da implementação, o aplicativo reconhecerá que há um token e começará a recuperar os dados usando o token errado. A chance é alta de que isso falhe com erros estranhos.
A solução para este problema em geral é prefixar as chaves padrão com a configuração atual construída. Você pode detectar a configuração facilmente em tempo de execução, definindo diferentes identificadores de pacote para suas configurações. Em seguida, basta ler o identificador do pacote de NSBundle.mainBundle()
. Se você tiver os mesmos identificadores de pacote, você precisa definir diferentes macros de pré-processador, como
#ifdef DEBUG
NSString* configuration = @"debug";
#elif RELEASE
NSString* configuration = @"release";
#endif
Em Swift será quase o mesmo:
#if DEBUG
let configuration = "debug"
#elseif RELEASE
let configuration = "release"
#endif