Reputation: 8179
I'm fairly new to iOS development and I am porting an Android app to iOS 7. The Android app provides a screen that allows the user to change a number of non persistent settings. Because these are not saved, it doesn't seem appropriate to me to expose them, on iOS, as preferences via a settings bundle and the built-in Settings app. So I'm looking at an in-app settings screen, which I understand is allowed - but perhaps not encouraged - by Apple.
Some questions:
Am I correct that an in-App approach is allowed by Apple? Most example code seems to use settings bundles. Am I going to have problems when the app is submitted to the App Store?
I can put the settings UI in a simple UITableViewController, but is there an approved way to expose this to the user? XCode 5 doesn't provide a settings identifier (and icon) for toolbar buttons, and the "Info" identifier (letter i inside a circle) seems to have been dropped too. Should I use a custom icon? Are there any de facto standards?
I haven't seen this kind of UI element before on iOS but my exposure to the platform as a user is limited.
Upvotes: 1
Views: 438
Reputation: 2063
There is nothing wrong with doing an in-app preference (table)view. You won't be rejected for that (this point seems to be way too much exagerated outside the iOS community). There are guidelines that you can follow: iOS Human Interface Guidelines... or not. As long as you don't use private APIs (assuming you know how to access them anyway), you're fine! So you can use a custom icon, the "i" button, or any UI element that convey the reasonable meaning of providing access to more info/preference.
In your code, you can use the class NSUserDefaults (with the standardUserDefaults) to store your preferences.
Upvotes: 3
Reputation: 318934
Upvotes: 2