Loading Configurations from plist into singleton In my iOS application, I've created a singleton class that reads a configuration plist file and provides accessor methods to easily retrieve the values:

class Configuration{

    struct Key{
        static let searchRadius = "searchRadius"
        static let significantUserMovementThreshold = "movementThreshold"
    }

    enum ConfigurationError : ErrorType{
        case FileNotFound
    }

    static let sharedInstance = Configuration()
    var configDictionary : NSDictionary?

    func loadConfigurationFromPropertyList() throws{

        if let filePath = NSBundle.mainBundle().pathForResource("Config", ofType: "plist"){
            self.configDictionary = NSDictionary(contentsOfFile: filePath)
        }else{
            throw ConfigurationError.FileNotFound
        }

    }

    func searchRadius()-&gt; Double?{
        return configDictionary?.objectForKey(Key.searchRadius) as? Double
    }

    func significantUserMovementThreshold() -&gt; Double?{
        return configDictionary?.objectForKey(Key.significantUserMovementThreshold) as? Double
    }


}


In the AppDelegate, I call Configuration.loadConfigurationFromPropertyList to load the configurations into memory.

I have a number of questions regarding this approach:


Is it a good idea to have accessor method for each property in the configuration file? I think it provides a cleaner and more reliable approach than using subscripts. 
Is it better for the Configuration class to read the file in its constructor or that AppDelegate invoke loadConfigurationFromPropertyList()?
I don't have a whole lot to add, as this is pretty straightforward and seems like a completely reasonable way to do what you're trying to do.

In regards to your questions:


There's a tradeoff for using accessor methods for properties. Every time you add a new one, you need to add a constant to the Key struct, and add an accessor method to the Configuration class to get its value. If you misspell either of them (in the plist or the string in the Key struct), you won't have the compiler to tell you so, and you can end up with some odd bugs that become hard to track down. However, I personally prefer the way you're doing it because it's easier to read for the future. Your set of configurations is currently fairly small, so it's pretty easy to maintain. I'd go with what you've got unless you think there will be a lot of configuration options that will be controlled by a plist file.
It's better to read the file in the constructor in my opinion. This is known as RAII - Resource Acquisition is Initialization. The idea being that if you do it in the constructor, if it fails, you don't end up with a partially initialized object.