I got this problem: "warning: iPad: Icon-72.png: icon dimensions (0 x 0) don't meet the size requirements. The icon file must be 72x72 pixels, in .png format (-19014)" when build for archive the iPad only app. Have checked, my icon is 72x72 pixels. Also checked on info.plist file, the key CFBundleIconFiles already there. Before this have no problem to submit the app. After rejected by app review I want to resubmit (no changes has been made on my Xcode project) but the error appear. Does it because of I've upgraded to Mac OSX Lion 10.7.3? (I just update to Mac OSX Lion 10.7.3 before resubmit the app).

Wonder why does the warning says "icon dimensions (0 x 0)".

Please help me. Thanks.

I installed Application Loader and the problem with Xcode got solved. Found the solution on Apple Developer forums here

The app I'm currently working on requires me to determine the part of speech of a word in NSString.

So basically is there a library/database/class which you can access in Objective C which allows one to check if a single word (in the form of a NSString) is a noun, an adjective, an adverb or a verb?

Something along the lines of:

NSString *foo="cat";

if ([foo wordIsNoun]) {
    //do something
};

On a similar but slightly unrelated note, is it possible to check if two NSString containing verbs of the same stem but different tense (ask, asking, asked, etc) have the same stem? It would be very useful as well.

You can do this with an NSLinguisticTagger! I've never used one before, but I hacked this together:

NSString *str = @"i have a cat";

NSLinguisticTagger *tagger = [[NSLinguisticTagger alloc] initWithTagSchemes:[NSArray arrayWithObject:NSLinguisticTagSchemeLexicalClass] options:~NSLinguisticTaggerOmitWords];
[tagger setString:str];
[tagger enumerateTagsInRange:NSMakeRange(0, [str length]) 
                      scheme:NSLinguisticTagSchemeLexicalClass 
                     options:~NSLinguisticTaggerOmitWords 
                  usingBlock:^(NSString *tag, NSRange tokenRange, NSRange sentenceRange, BOOL *stop) {
                               NSLog(@"found: %@ (%@)", [str substringWithRange:tokenRange], tag);
                              }];
[tagger release];

When you run this, it logs:

found: i (Pronoun)
found: have (Verb)
found: a (Determiner)
found: cat (Noun)

Note, however, that NSLinguisticTagger is only available on iOS 5+ (and Mac OS X 10.7+).

I want to programmatically change the volume icon for a stacked file system implemented using OSXFUSE (formerly MacFUSE). The icon needs to reflect the state of a mounted file system.

The approach that I have been trying to get working is to map requests for /.VolumeIcon.icns to the appropriate icon in the application bundle. Then sending change notifications to the file system for the actual path (path) and the mount path (mountPath).

    [[NSWorkspace sharedWorkspace] noteFileSystemChanged: @"/Volumes"]; 
    [[NSWorkspace sharedWorkspace] noteFileSystemChanged: [mountPath stringByDeletingLastPathComponent]];
    [[NSWorkspace sharedWorkspace] noteFileSystemChanged: mountPath];
    [[NSWorkspace sharedWorkspace] noteFileSystemChanged: [path stringByDeletingLastPathComponent]];
    [[NSWorkspace sharedWorkspace] noteFileSystemChanged: path];

    FNNotifyByPath([[[mountPath stringByDeletingLastPathComponent] dataUsingEncoding:NSUTF8StringEncoding] bytes], kFNDirectoryModifiedMessage, kNilOptions);
    FNNotifyByPath([[[path stringByDeletingLastPathComponent] dataUsingEncoding:NSUTF8StringEncoding] bytes], kFNDirectoryModifiedMessage, kNilOptions);
    FNNotifyByPath([[@"/Volumes" dataUsingEncoding:NSUTF8StringEncoding] bytes], kFNDirectoryModifiedMessage, kNilOptions);

Stepping through the debugger I can see this code being hit but the code to map the /.VolumeIcon.icns gets called infrequently and never in response to these notifications.

I think the short answer is, you're out of luck. The long answer is while the OSXFUSE project is different than the Fuse4X project, they're both derived from the same source, and Fuse4X has this to say about volume icons in their FAQ:

Q 4.1. Why do Fuse4X volumes show up with "server" (or "network volume") icons?

A: To be precise, by default Fuse4X volumes show up as nonlocal volumes, which the Finder unfortunately treats the same as "servers". It's a good question as to why Fuse4X normally tags its volumes as nonlocal. Some people think that in the case of disk-based file systems, Fuse4X must tag the volume as local. Well, let us see.

For a vfs to be local on Mac OS X, you need a "real" disk device – a /dev/disk* style node. Such a real disk device node in Fuse4X's case is problematic: at mount time, for a local volume, the kernel would itself open the device node and pass it to Fuse4X. In doing so, the kernel would make sure that the device is not currently in use (for one, to disallow multiple mounts of the same device). This happens before control passes to Fuse4X and mounting can proceed. This would have been fine if the entire file system lived in the kernel, but in Fuse4X's case, the user-space file system program would also want to (exclusively) open the disk device.

I'm slightly confused as to why clang is emitting different code for the following two method:

@interface ClassA : NSObject
@end

@implementation ClassA
+ (ClassA*)giveMeAnObject1 {
    return [[ClassA alloc] init];
}
+ (id)giveMeAnObject2 {
    return [[ClassA alloc] init];
}
@end

If we look at the ARMv7 emitted then we see this, at O3, with ARC enabled:

        .align  2
        .code   16
        .thumb_func     "+[ClassA giveMeAnObject1]"
"+[ClassA giveMeAnObject1]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC0_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC0_1+4))
LPC0_0:
        add     r1, pc
LPC0_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC0_2+4))
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC0_2+4))
LPC0_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop.w   {r7, lr}
        b.w     _objc_autorelease

        .align  2
        .code   16
        .thumb_func     "+[ClassA giveMeAnObject2]"
"+[ClassA giveMeAnObject2]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC2_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC2_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
LPC2_0:
        add     r1, pc
LPC2_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_2+4))
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_2+4))
LPC2_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop.w   {r7, lr}
        b.w     _objc_autoreleaseReturnValue

The only difference is the tail call to objc_autoreleaseReturnValue vs objc_autorelease. I would expect both to call objc_autoreleaseReturnValue to be honest. In-fact the first method not using objc_autoreleaseReturnValue means that it will potentially be slower than the second because there will definitely be an autorelease then a retain by the caller, rather than the faster bypass of this redundant call that ARC can do if it's supported in the runtime.

The LLVM which is emitted gives some kind of reason why it's like that:

define internal %1* @"\01+[ClassA giveMeAnObject1]"(i8* nocapture %self, i8* nocapture %_cmd) {
  %1 = load %struct._class_t** @"\01L_OBJC_CLASSLIST_REFERENCES_$_", align 4
  %2 = load i8** @"\01L_OBJC_SELECTOR_REFERENCES_", align 4
  %3 = bitcast %struct._class_t* %1 to i8*
  %4 = tail call i8* bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to i8* (i8*, i8*)*)(i8* %3, i8* %2)
  %5 = load i8** @"\01L_OBJC_SELECTOR_REFERENCES_2", align 4
  %6 = tail call i8* bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to i8* (i8*, i8*)*)(i8* %4, i8* %5)
  %7 = tail call i8* @objc_autorelease(i8* %6) nounwind
  %8 = bitcast i8* %6 to %1*
  ret %1* %8
}

define internal i8* @"\01+[ClassA giveMeAnObject2]"(i8* nocapture %self, i8* nocapture %_cmd) {
  %1 = load %struct._class_t** @"\01L_OBJC_CLASSLIST_REFERENCES_$_", align 4
  %2 = load i8** @"\01L_OBJC_SELECTOR_REFERENCES_", align 4
  %3 = bitcast %struct._class_t* %1 to i8*
  %4 = tail call i8* bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to i8* (i8*, i8*)*)(i8* %3, i8* %2)
  %5 = load i8** @"\01L_OBJC_SELECTOR_REFERENCES_2", align 4
  %6 = tail call i8* bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to i8* (i8*, i8*)*)(i8* %4, i8* %5)
  %7 = tail call i8* @objc_autoreleaseReturnValue(i8* %6) nounwind
  ret i8* %6
}

But I'm struggling to see why it's decided to compile these two method differently. Can anyone shed some light onto it?

Update:

Even weirder is these other methods:

+ (ClassA*)giveMeAnObject3 {
    ClassA *a = [[ClassA alloc] init];
    return a;
}

+ (id)giveMeAnObject4 {
    ClassA *a = [[ClassA alloc] init];
    return a;
}

These compile to:

        .align  2
        .code   16
        .thumb_func     "+[ClassA giveMeAnObject3]"
"+[ClassA giveMeAnObject3]":
        push    {r4, r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC2_0+4))
        add     r7, sp, #4
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC2_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
LPC2_0:
        add     r1, pc
LPC2_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_2+4))
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_2+4))
LPC2_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        blx     _objc_retainAutoreleasedReturnValue
        mov     r4, r0
        mov     r0, r4
        blx     _objc_release
        mov     r0, r4
        pop.w   {r4, r7, lr}
        b.w     _objc_autoreleaseReturnValue

        .align  2
        .code   16
        .thumb_func     "+[ClassA giveMeAnObject4]"
"+[ClassA giveMeAnObject4]":
        push    {r4, r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC3_0+4))
        add     r7, sp, #4
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC3_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC3_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC3_1+4))
LPC3_0:
        add     r1, pc
LPC3_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC3_2+4))
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC3_2+4))
LPC3_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        blx     _objc_retainAutoreleasedReturnValue
        mov     r4, r0
        mov     r0, r4
        blx     _objc_release
        mov     r0, r4
        pop.w   {r4, r7, lr}
        b.w     _objc_autoreleaseReturnValue

This time, they are identical however there's a few things which could be optimised even more here:

1. There's a redundant mov r4, r0 followed by mov r0, r4.

2. There's a retain followed by a release.

Surely, the bottom bit of both of those methods can turn into:

LPC3_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop.w   {r4, r7, lr}
        b.w     _objc_autoreleaseReturnValue

Obviously we could then also omit popping r4 because we don't actually clobber it any more. Then the method would turn into the exact same as giveMeAnObject2 which is exactly what we'd expect.

Why is clang not being clever and doing this?!

This appears to be a bug in the optimizer and is being tracked as rdar://problem/10813093.

I usually release the object after use by

[myObject release];

But I found in some online tutorials that they assign a nil after releasing the object. Like

[myObject release];
myObject = nil;

Is it required?

It's a long-running debate as to whether setting the pointer to nil after releasing is necessary, but I come down on the side of it being a good idea.

After the object is released, the pointer you hold to it still points to the same place. If your release has taken the retain count to 0 then the object will be deallocated. If you then try and send a message to the deallocated object you'll get an EXC_BAD_ACCESS error. However, sending a message to the pointer after it's been set to nil won't error - it just won't do anything.

The other side of the argument is that if you're messaging a deallocated object it's good to know about it and fix your code to make sure it doesn't happen.

There are smart people in both camps.

I'm looking through the source code for the CocoaHTTPServer project, more specifically the HTTPServer.m file and I just don't understand this line:

connectionClass = [HTTPConnection self];

What does this do (is it documented anywhere)? How does it even compile? Should it not be

connectionClass = [HTTPConnection class];

In this context, - (id)self is a method defined on NSObject. It returns the receiver. For a Class it should obviously do the same as a call to the -(Class)class.

Class objects are thus full-fledged objects that can be dynamically typed, receive messages, and inherit methods from other classes. They’re special only in that they’re created by the compiler.

I'm not sure how much use this question is but it seems interesting to me...

I thought that using property/synthesize statements was equivalent to me creating the getter/setter. Therefore

// .h
@property (nonatomic) BOOL on;

// .m
@synthesize on = _on;

// In my mind synthesizes the following methods

// - (BOOL)on;
// - (void)setOn:(BOOL)on;

However if I change the declarations to the following:

                              v
@property (nonatomic, getter=isOn) BOOL on;

@synthesize on = _on;

// In my mind synthesizes the following

// - (BOOL)isOn;
// - (void)setOn:(BOOL)on;

Then given the above I override the getter so I know when it is called:

- (BOOL)isOn;
{
    NSLog(@"I was called");
    return _on;
}

Now calling the following on an instance (myClass) results in:

NSLog(@"%d", [myClass isOn]);

//=> 2012-02-09 22:18:04.818 Untitled[1569:707] I was called
//=> 2012-02-09 22:18:04.820 Untitled[1569:707] 1

NSLog(@"%d", myClass.isOn);

//=> 2012-02-09 22:18:24.859 Untitled[1599:707] I was called
//=> 2012-02-09 22:18:24.861 Untitled[1599:707] 1

NSLog(@"%d", myClass.on);         // This is the one I didn't expect to work

//=> 2012-02-09 22:18:55.568 Untitled[1629:707] I was called
//=> 2012-02-09 22:18:55.570 Untitled[1629:707] 1

I had always assumed that if I was using a property in this sense it was perfectly valid to use the getter/setter with dot syntax in the form

myClass.isOn;
myClass.on = on;

From another question it was suggested that when using dot syntax I should use the property name like this:

myClass.on   // Correct
myClass.isOn // Incorrect

Although this works it seem slightly less logical because I know there is no underlying method - (BOOL)on it is instead mapped to - (BOOL)isOn

My questions are (using the latter example)

• Is this a bug or should myClass.on really be silently changed to call - (BOOL)isOn
• Semantically speaking I am accessing state not invoking behaviour so is my current use of dot syntax correct? (e.g. myClass.isOn)

---

Update

Although no one has explicitly said it I have reasoned that using .isOn is bad form because regardless of the fact that under the hood the same method is called, semantically isOn is asking a question, which is more behaviour rather than state.

However I am still unclear on where the "magic" wiring goes on that turns calls to myClass.on into [myClass isOn]

---

Update 2

After looking around the docs some more I found this section on Declared Properties. Using the following code I can inspect a class' properties:

id MyClass = objc_getClass("MyClass");
unsigned int outCount, i;

objc_property_t *properties = class_copyPropertyList(MyClass, &outCount);
for (i = 0; i < outCount; i++) {
    objc_property_t property = properties[i];
    NSLog(@"Name: %s, attributes: %s\n", property_getName(property), property_getAttributes(property));
}

//=> 2012-02-10 07:10:28.333 Untitled[934:707] Name: on, attributes: Tc,GisOn,V_on

So we have the following attributes:

• name = on
• type = char (Tc)
• getter = isOn (GisOn)
• variable = _on (V_on)

With all of this information available at runtime it kind of leaves the question is this lookup done at runtime or compile time like some answers suggest?

However I am still unclear on where the "magic" wiring goes on that turns calls to myClass.on into [myClass isOn]

The logic surely goes as follows, when compiling an obj.name in a getting context:

if(there is an accessible @property for name in scope)
{
   if(there is a custom getter specified)
      compile "[obj customGetter]"
   else
      compile "[obj name]"
}
else if (there is an an accessible instance method name in scope)
   compile "[obj name]"
else
{
   compile "[obj name]"
   warn obj may not respond to name
}

There are other ways a language/execution environment can handle custom getter names, but given that Obj-C puts the declaration in the header (which is public) the above is a good guess as to where the custom getter logic is performed - when compiling the call site.

I've been looking at the best way to implement the Visitor design pattern in Objective-C. Since the language doesn't support method overloading, a 'traditional' implementation such as one might find in Java seems impossible.

In my current implementation, I have a Visitor protocol, a Visitor class, and several subclasses of that Visitor class, along with the various objects to visit. Once a visited object accepts the Visitor, they call the visit method of the Visitor, passing themselves as an argument. The visit method takes an id, then type-casts it and calls

[self performTasksOnObjectClass: (ObjectClass *)object];

as part of an if/elseif/else block. These calls are them picked up by the relevant Visitor subclass and the Visitor performs whatever tasks it needs to on the object.

Is there a better way of implementing the Visitor pattern than this? I dislike resorting to 'isKindOfClass' or 'isMemberOfClass' calls inside if/elseif/else blocks. It just seems clunky and inelegant. Additionally, is it still 'worth' implementing a Visitor method in this way? The visited objects can still remain ignorant of the Visitor, but there are other ways in which this can be achieved.

It has already been suggested that either delegation or class clusters might be more suitable alternatives to the Visitor pattern. I'd be interested to see what you all think!

Edit: I actually had differently named methods being called in the subclass, I've made this clearer.

You can use some introspection/reflection to make this a bit cleaner. You can't overload method names but you can avoid writing a switch statement like this:

- (void)performTasks:(id)object
{
    Class class = [object class];
    while (class && class != [NSObject class])
    {
        NSString *methodName = [NSString stringWithFormat:@"perform%@Tasks:", class];
        SEL selector = NSSelectorFromString(methodName);
        if ([self respondsToSelector:selector])
        {
            [self performSelector:selector withObject:object];
            return;
        }
        class = [class superclass];
    }
    [NSException raise:@"Visitor %@ doesn't have a performTasks method for %@", [self class], [object class]];
}

Your actual performTasks methods would then be named as follows:

- (void)performFooTasks:(Foo *)foo
{
    //tasks for objects of class Foo
}

- (void)performBarTasks:(Bar *)bar
{
    //tasks for objects of class Bar
}

etc...

Note: If you're using ARC, you may get some spurious warnings by creating selectors from strings in this way because it can't tell at compile time what the retain rules should be for the method parameters. You can silence these warnings importing <objc/message.h> and then replacing

[self performSelector:selector withObject:object];

with

objc_msgSend(self, selector, object);

which is functionally equivalent, but doesn't trigger the warning.

What's the exact reason for using dispatch_once in the shared instance accessor of a singleton under ARC?

+ (MyClass *)sharedInstance
{
    static MyClass *sharedInstance = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        sharedInstance = [[MyClass alloc] init];
        // Do any other initialisation stuff here
    });
    return sharedInstance;
}

Isn't it a bad idea to instantiate the singleton asynchronuously in the background? I mean what happens if I request that shared instance and rely on it immediately, but dispatch_once takes until christmas to create my object? It doesn't return immediately right? At least that seems to be the whole point of Grand Central Dispatch.

So why are they doing this?

dispatch_once() is absolutely synchronous. Not all GCD methods do things asynchronously (case in point, dispatch_sync() is synchronous). The use of dispatch_once() replaces the following idiom:

+ (MyClass *)sharedInstance {
    static MyClass *sharedInstance;
    @synchronized(self) {
        if (sharedInstance == nil) {
            sharedInstance = [[MyClass alloc] init];
        }
    }
    return sharedInstance;
}

The benefit of dispatch_once() over this is that it's faster. It's also semantically cleaner, because the entire idea of dispatch_once() is "perform something once and only once", which is precisely what we're doing.

I am confused about the search list feature in NSUserDefaults. The class reference says about the standardUserDefaults class method that it sets up a standard search list consisting of five domains. The docs for that method also imply that this search list can be changed (boldness added by me):

Subsequent modifications to the standard search list remain in effect even when this method is invoked again—the search list is guaranteed to be standard only the first time this method is invoked.

Let's also look at the docs for init:

Return Value: An initialized NSUserDefaults object whose argument and registration domains are already set up.

Discussion: This method does not put anything in the search list.

In my understanding this is a contradiction: Either the search list is empty, or it contains entries for the argument and registration domains.

Anyway, I did a bit of experimentation:

NSUserDefaults* standardUserDefaults = [NSUserDefaults standardUserDefaults];
// We get nil, which is expected
NSLog(@"test 1: expecting nil, getting %@", [standardUserDefaults objectForKey:@"foo"]);
NSDictionary* registrationDomainDefaults = [NSDictionary dictionaryWithObject:[NSNumber numberWithInt:42] forKey:@"foo"];
[standardUserDefaults registerDefaults:registrationDomainDefaults];
// We get 42, which is expected
NSLog(@"test 2: expecting 42, getting %@", [standardUserDefaults objectForKey:@"foo"]);
[standardUserDefaults removeSuiteNamed:NSRegistrationDomain];
[standardUserDefaults removeVolatileDomainForName:NSRegistrationDomain];
// Here we get 42!
NSLog(@"test 3: expecting nil, getting %@", [standardUserDefaults objectForKey:@"foo"]);

NSUserDefaults* myUserDefaults = [[NSUserDefaults alloc] init];
// Here we also get 42!
NSLog(@"test 4: expecting nil, getting %@", [myUserDefaults objectForKey:@"foo"]);
[myUserDefaults removeSuiteNamed:NSRegistrationDomain];
[myUserDefaults removeVolatileDomainForName:NSRegistrationDomain];
// We still get 42 *sigh*
NSLog(@"test 5: expecting nil, getting %@", [myUserDefaults objectForKey:@"foo"]);

As you can see, I am trying to remove NSRegistrationDomain from the search list, by invoking both removeSuiteNamed: and removeVolatileDomainForName:. This does not work, at least not on iOS where I ran the tests, but I assume it's the same on Mac OS X. So these are my questions:

1. On iOS, is there a way to remove one of the five standard domains from the search list of an NSUserDefaults object? Note that it does not necessarily have to be the object returned by standardUserDefaults, I would be happy to create my own object. In case it matters: I am particularly interested in getting rid of NSRegistrationDomain.
2. If the answer to the above is "no", can we say that the five standard domains are simply "immutable" and that all the stuff in NSUserDefaults about adding/removing suites and persistent/volatile domains is about user-defined domains?
3. Is there a way to find out what is in the search list of an NSUserDefaults object?

I suspect I already know the answers (no, yes, and no), but at least I am looking for someone with more experience to confirm my suspicions.

1. To get rid of a domain like NSRegistrationDomain, you should use removeVolatileDomainForName:. However, this will not work with NSRegistrationDomain and NSArgumentDomain. These two cannot be removed. Try to register your own domain with setVolatileDomain:forName: instead. You'll be able to remove this one.

   I believe that in the five domains of the standardUserDefaults, you can remove your own domain with removePersistentDomainForName:, passing your bundle identifier. But I've not tried this out.

   Since NSGlobalDomain is persistent and you can only pass your own bundle identifier to removePersistentDomainForName:, I believe you can't remove NSGlobalDomain. Again, this is untested.

2. I believe so, except for the persistent domain with your bundle identifier.

3. No, but using -volatileDomainNames should be sufficient for most purposes.

If I understand this correctly, copy enforces the setter to create a copy of the object passed in. However, if I use it together with readonly, there won't be a setter. So is my assumption correct, that combining @property (copy, readonly) doesn't make any sense or am I missing something?

It does make sense. Consider you want to access a properties setter only in your implementation:

@interface MyClass : NSObject
@property (nonatomic, copy, readonly) NSData *data;

- (id)initWithData:(NSData *)data;

@end

and in the class continuation in the .m file:

@interface MyClass ()
@property (nonatomic, copy, readwrite) NSData *data;
@end

Note that the copy, readonly declaration in the public header is required in this case!

It may sound very silly to people who know this but I am quite new to iOS. I wanted to know, why cant we modify origin or size or may be x,y or height width of these properties of a UIView frame ?

frame is a CGRect struct and origin and size are again CGPoint and CGSize structures. when we can access them, why cant we modify them ?

There is nothing like this in a CGRect, we can modify it's attributes so why cant we do it for frame or bounds.

I assume you mean why can't you do somethIng like this:

myView.frame.origin.x = 23.0;

It's a good question, nothing silly about it. The problem is that the frame is held as the property of the view, not the individual components of the frame (the size and origin, or even deeper, the width, length, x and y).

The frame is fundamental to the view, so there are lots of actions that a view needs to do if its frame is modified. If you were to reach in and modify the origin.x directly then you would be bypassing the setFrame method where all of this magic probably happens.

When you access view.frame you are being given a CGRect that has the same value as view.frame, but is not actually the frame, so any modifications to it don't affect the view.

You can do it in steps:

CGRect frame = view.frame;
frame.origin.x = 23.0;
view.frame = frame;