It's certainly possible to develop on a Windows machine, in fact, my first application was exclusively developed on the old Dell Precision I had at the time :)
There are three routes;
- Install OSx86 (aka iATKOS / Kalyway) on a second partition/disk and dual boot.
- Run Mac OS X Server under VMWare (Mac OS X 10.7 (Lion) onwards, read the update below).
- Use Delphi XE4 and the macincloud service. This is a commercial toolset, but the component and lib support is growing.
The first route requires modifying (or using a pre-modified) image of Leopard that can be installed on a regular PC. This is not as hard as you would think, although your success/effort ratio will depend upon how closely the hardware in your PC matches that in Mac hardware - e.g. if you're running a Core 2 Duo on an Intel Motherboard, with an NVidia graphics card you are laughing. If you're running an AMD machine or something without SSE3 it gets a little more involved.
If you purchase (or already own) a version of Leopard then this is a gray area since the Leopard EULA states you may only run it on an "Apple Labeled" machine. As many point out if you stick an Apple sticker on your PC you're probably covered.
The second option is more costly. The EULA for the workstation version of Leopard prevents it from being run under emulation and as a result, there's no support in VMWare for this. Leopard server, however, CAN be run under emulation and can be used for desktop purposes. Leopard server and VMWare are expensive, however.
If you're interested in option 1) I would suggest starting at Insanelymac and reading the OSx86 sections.
I do think you should consider whether the time you will invest is going to be worth the money you will save though. It was for me because I enjoy tinkering with this type of stuff and I started during the early iPhone betas, months before their App Store became available.
Alternatively, you could pick up a low-spec Mac Mini from eBay. You don't need much horsepower to run the SDK and you can always sell it on later if you decide to stop development or buy a better Mac.
Update: You cannot create a Mac OS X Client virtual machine for OS X 10.6 and earlier. Apple does not allow these Client OSes to be virtualized. With Mac OS X 10.7 (Lion) onwards, Apple has changed its licensing agreement in regards to virtualization. Source: VMWare KnowledgeBase
Have a look at NSUserDefaults. It is a dictionary style collection class designed for this particular purpose.
You store and retrieve defaults like so:
// Fetch a default
BOOL deleteBackup = [[NSUserDefaults standardUserDefaults] boolForKey:@"DeleteBackup"];
// Save a default
[[NSUserDefaults standardUserDefaults] setObject:@"NO" forKey:@"DeleteBackup"];
NSUserDefaults will automatically take care of reading from and serializing to disk.
Concerning your other question, it depends on the overall architecture of your app. Sending out notifications when the OptionsViewController is finished sounds like a reasonable approach to me. However, you could also just define a method on your MainViewController or app delegate (ie. "-reloadUserDefaults") that you can invoke from your OptionsViewController when it's finished.
Best Answer
For my own use, I have created some kind of MVC construction. I have a DataManager (a singleton), which holds all the required data (mostly represented in Models; plain NSObjects) in array's or dictionaries.
Views (Nib files and ViewControllers) talk to the DataManager to get their data via get functions .. if the data is already present in the DataManager, it returns the data (via a Notification). If not; it forwards the call to a Controller which then gets it.
In that Controller, I seperate the call in an offline/online modus (probably not important for you) where if online, the call is an XML request, and if offline the call is to a SQLite database.
The Controller can then set the data on the DataManager, and dispatch a Notification to the View.
Then the cycle starts again, where the View can access the data through the DataManager.. All of this happens in asynchronous calls, hence the Notifications (if I'd let the DataManager or Controllers mess with the Views, it would not be thread safe).
My AppDelegate only does the very first initialization of the main view, controllers and DataManager, and those then take over.
It is good to have your models (data) in a central place, so you could easily access it throughout every class, without creating to much class dependencies.
I split up most types of functionalities into separate classes also, like the DataManager for data, a DownloadManager for asynchronized URL requests, an XML Parser, a factory to build models from NSDictionaries, a DatabaseConnector, etc, etc.