Xcode – How to keep a clean production version of your iOS App?

as a precursor, i’m not familiar with Game Center, so there may be concerns there that i haven’t accounted for. so, with that, my instinct in solving this starts out with launch arguments. there is a great article on how to do this here: https://www.swiftbysundell.com/articles/launch-arguments-in-swift/.

Now that you’re able to start changing behavior based off of launch arguments from different schemes, you can start to look at how to segment your test / prod data.

As I’m not a CoreData expert, i can’t say with 100% confidence that this is possible (or easy), but i would investigate how to setup separate persistent stores based off of a launch argument. using this article as a reference, it seems like you could roughly do something like the below after creating a -testGameCenter launch argument to a new TestGameCenter scheme to create an in-memory data store when testing Game Center

lazy var persistentContainer: NSPersistentContainer = {
  let container = NSPersistentContainer(name: "YourDataStore")

  if CommandLine.arguments.contains("-testGameCenter") {
    let description = NSPersistentStoreDescription()
    description.url = URL(fileURLWithPath: "/dev/null")
    container.persistentStoreDescriptions = [description]  
  }

  container.loadPersistentStores(completionHandler: { _, error in
    if let error = error as NSError? {
      fatalError("Failed to load stores: (error), (error.userInfo)")
    }
  })

  return container
}()

if you’re able to solve the CoreData problem above, it’s time to start looking at how to segment your UserDefaults data. this gross but easy solution that immediately comes to mind is prefixing your UserDefault keys with test when running from your test scheme. below is an example of how could structure a wrapper around UserDefaults to manage this

struct UserDefaultsWrapper {
    let userDefaults: UserDefaults
    let keyPrefix: String

    init(userDefaults: UserDefaults, keyPrefix: String) {
        self.userDefaults = userDefaults
        self.keyPrefix = keyPrefix
    }

    func setValue(_ value: Any?, forKey key: String) {
        self.userDefaults.setValue(value, forKey: prefixedKey(forKey: key))
    }

    func value(forKey key: String) -> Any? {
        self.userDefaults.value(forKey: prefixedKey(forKey: key))
    }

    func prefixedKey(forKey key: String) -> String {
        return "(keyPrefix)(key)}"
    }
}

where you could make use of the wrapper like so

    let userDefaultsPrefix = CommandLine.arguments.contains("-testGameCenter") ? "testGameCenter_" : ""

    let userDefaultsWrapper = UserDefaultsWrapper(userDefaults: .standard, keyPrefix: userDefaultsPrefix)

to get something more elegant, you could look a little more into UserDefaults to see if you could apply a solution similar to the one for CoreData where there are two entirely separate stores. from a quick glance at this initializer, maybe you could do something as simple as this with your wrapper instead

struct UserDefaultsWrapper {
    let userDefaults: UserDefaults

    init(userDefaults: UserDefaults) {
        self.userDefaults = userDefaults
    }

    func setValue(_ value: Any?, forKey key: String) {
        self.userDefaults.setValue(value, forKey: key)
    }

    func value(forKey key: String) -> Any? {
        self.userDefaults.value(forKey: key)
    }
}

where you construct it like so

    let userDefaultsSuiteName: String? = CommandLine.arguments.contains("-testGameCenter") ? myTestingGameCenterSuiteName : nil

    let userDefaults = UserDefaults(suiteName: userDefaultsSuiteName)
    let userDefaultsWrapper = UserDefaultsWrapper(userDefaults: userDefaults)

lastly, from a comment you made on another reply, it sounds like you are also concerned with fresh install scenarios. that said, the approaches i’ve outlined will not help (at least i don’t think) with persisting data across deletes/installs. but, what i think you should think about is if it’s necessary to test those delete/install concerns from your production bundle id. could you instead either manually test those concerns from your test bundle id and/or write unit tests around the components that involve those concerns? when you are approaching your testing strategy, it’s important to make sure that you’re testing the right things at the right layers; testing the wrong things at the wrong layers makes each testing layer much, much harder to execute