ios - Setting NSUserDefaults Directly In Custom Getter / Setter -

so have small value needs synced across app through nsuserdefaults. found myself saving , getting value nsuserdefaults bit , thought might nice link getter / setter directly nsuserdefaults.

here's getter / setter code:

- (void) setsomeproperty:(id)somevalue {     [[nsuserdefaults standarduserdefaults]setobject:somevalue forkey:@"someproperty"]; }  - (id) someproperty {     return [[nsuserdefaults standarduserdefaults]objectforkey:@"someproperty"]; } 

here's how access:

someclass.someproperty = @"somevalue"; // -- set's @"somevalue"  id somevalue = someclass.someproperty; // -- assigns value nsuserdefaults 

this way, when update or retrieve property, directly accessing nsuserdefault value. me seems simpler way write , retrieve values nsuserdefaults, perhaps there problematic or performance consideration i'm overlooking. feedback / concerns appreciated.

question

is acceptable practice, , cause problems later on?

what you're doing ok, has implications should aware of.

nsuserdefaults disk-based storage. such slower memory-based solutions. on ios, "disk-based" means flash memory, still slower memory-based storage.

flash memory has limited number of write cycles before fails.

for these 2 reasons, not use above technique values change rapidly, or require fast response.

also, i'm assuming since "...synced across app..." mean shared between multiple objects.

i suggest making sure document these properties in header it's clear shared, persistent properties. adding words "shared" or "saved" property names help, in addition descriptive text in header.

if requirement shared access, , don't need persistence, might @ using data container singleton instead of using user defaults. (you create singleton object has properties want share, , fetch pointer singleton anywhere in app , use read/write properties want share.)

you use hybrid approach, collect these properties in singleton, , implement persistence in singleton. has advantage of centralizing save/read logic in 1 place, can change use different storage method if decide @ future date.