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

I am trying to submit an app which is only for iPhone.

The error showed " iPhone/iPod Touch: Icon.png: icon dimensions (0 x 0) don't meet the size requirement. The icon file must be 57x57 pixels, in .png format.

May I know why this happens? I try to change the plist setting and i am sure my icon is at the right size. It shows perfectly on my iPhones.

I have searched for few post here but still cannot find the solution.

Could anyone knows the problem?

Thanks

According to this solution https://devforums.apple.com/message/612098#612098 make this steps:

1. Install ApplicationLoader_2.5.1.dmg (Just install it, you don't need to launch/use it)
2. Quit & restart Xcode
3. Clean Project
4. Archive (again)
5. Validate/Submit now works

This solution fixed my problems with submission.

I recently upgraded to 10.7.3, and when I try to debug my iOS project in the simulator for the first time after logging in, I'm prompted with the following two alerts:

My user is an admin user. I never saw these alerts before. How do I get them to stop?

EDIT

I've verified that I'm a member of the _developer group using id -a.

Reinstalling Xcode 4.2.1 after upgrading to 10.7.3 seems to have fixed it for me.

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 have tried dozens of configuration settings trying to get this to work, but still to no avail...

When I am trying to submit to the app store, the application loader is reporting the following error

iPhone/iPod Touch: application executable is missing a required architecture. At least one of the following architecture(s) must be present: armv7.

My understanding is that fpc 2.4 can only generate armv6 code anyway.

I have tried setting all build settings to only reference armv6, installed the previous version of XCode 3.2.6 and linked with the iOS SDK 4.3, hoping that this will address any references to armv7, but still no joy.

According to the XE2 Update 4 release notes, fpc 2.6 supports armv7, but despite the release notes having been available for weeks, there is no sign of the update!

Has anyone successfully uploaded an app using current tools (it surely has to be possible), and if so, could you please share your secret!

Thank you

Answering my question (sorry)...

I have upgraded to FPC 2.6 and all is okay.

I was reluctant to do this as it would make my development environment 'non-standard', however it was quite painless.

There is a paragraph in the release notes to the effect that nothing has changed in the xcode environment. This is probably accurate to an extent, but it is at least a little misleading as the compiler now builds armv7 code okay which is the issue I needed resolved.

Some iOS controls have localised strings built in by Apple. The "Done", "Edit", "Back" bar button items are some examples. Is there a way to access these strings?

I am making a UIActionSheet with standard "Delete" or "Cancel" options, just like when you delete a contact in the Contacts app.

Is there a way to reference these strings in code? If not, is there somewhere I can at least get these strings (like extracting them from the resources of an Apple app)? It would save extra localisation work and would ensure consistency with the platform.

If iOS is like Mac OS each app carries their own Localizable.strings file. And in each strings file you have all those little strings like Done, Edit, Cancel and so on.

These are some strings I copied from the English Localizable.string file from Finder.app:

<key>AL1</key>
<string>Cancel</string>
<key>AL4</key>
<string>OK</string>
<key>AL9</key>
<string>Don’t Save</string>
<key>FF24</key>
<string>Save</string>
<key>U32</key>
<string>Yes</string>
<key>U33</key>
<string>No</string>

You get the idea. Each little string is localized in each app.

This one is from iTunes.app.

/* ===== Ask User Strings ===== */
"23987.001" = "Yes";
"23987.002" = "No";
"23987.003" = "OK";
"23987.004" = "Cancel";
"23987.005" = "Ignore";
"23987.006" = "Quit";
"23987.007" = "Don’t Quit";
"23987.008" = "Apply";
"23987.009" = "Don’t Apply";
"23987.010" = "Later";
"23987.011" = "Don’t Save";
"23987.012" = "Save";
"23987.013" = "Stop";
"23987.014" = "Continue";
"23987.015" = "Delete";
"23987.016" = "Remove";
"23987.017" = "Replace";
"23987.018" = "Don’t Replace";
"23987.019" = "Do not ask me again";

Looks a little bit more structured. Copying their files is probably not allowed though ;-)

---

An answer in apples devforum by Quinn (eskimo1) from Apple Developer Relations.

Some UI elements are automatically localised for you. For example, the artwork on a UIBarButtonItem. However, there's no supported way to get to the strings like "OK" and "Cancel" as they are used in a UIActionSheet. They should, however, be trivial for your localiser to cope with.

2 years old though. But newer threads have the same outcome. No way to get those strings.

I want to use that anti piracy code for my app.

NSString* bundlePath = [[NSBundle mainBundle] bundlePath];
BOOL fileExists = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/_CodeSignature", bundlePath)];
if (!fileExists) {
    //Pirated
    NSLog(@"Pirated");
}
BOOL fileExists2 = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/CodeResources", bundlePath)];
if (!fileExists2) {
    //Pirated
    NSLog(@"Pirated2");
}
BOOL fileExists3 = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/ResourceRules.plist", bundlePath)];
if (!fileExists3) {
    //Pirated
    NSLog(@"Pirated3");
}

Has anyone used it before? Can it be used for some basic protection, or is it just crap? What suggestions do you have on this topic?

My two cents is that I think you are going to spend a lot of time trying to stop something that you cannot fully stop. From what is said in some of the comments it sounds lie you are concerned about piracy because there are a lot of jail broken phones in Greece. Greece is just one part of the world and I suspect if you stop thinking locally and start thinking globally you will find that the magority of phones are not jail broken and are running legit apps.

My suggestion would be to concentrate on those customers who will pay and spend your time making your app so appealing that they will jump at the chance to buy it.

Second, I would suggest that you look for ways to endear the jail breakers so that they like your app and want to give you money or buy it. There is a lot of discussion on the net about new business models and how the older piracy hating models are just not working. Hunt around and I think you will find cases where people have embraced the fact that their product is being copied and used it to their advantage. Can you pull off the same trick? If you can, then concerns about piracy will disappear and the people concerned will quite likley become an asset rather than a liability.

Just my thoughts :-)

I've been writing iOS apps for a while now and gradually went from doing the UI entirely programmatically to using the Interface Builder intensively. I'm now thinking about using the new Storyboarding feature for some of my new projects, but I don't have enough experience or knowledge with it to calculate the advantages and disadvantages of doing so. Can anybody give some examples or information about when using Storyboarding payed off and when it was a waste of time?

Advantages of Storyboarding

• It's cool - suave way to design interfaces
• Use of StoryBoardSegues to identify navigation/modal relationships
• If your app supports multiple devices, good way to organize different views (by storyboard file rather than naming, etc)
• Nice for prototyping
• Prototype UITableViewCell can save time

Disadvantages of Storyboarding

• It's a runtime feature, so I believe it is only available in iOS 5
• StoryBoardSegues are kind of rigid in my experience and you may make use of prepareForSegue a lot
• Like IB, not very friendly with other display engines and toolkits
• Makes it hard to share designs for a single view or set of views - you have to send all or nothing

These seem kind of superficial, I guess I haven't given it much thought... At first I was gung-ho about story boards, but now I've reverted to IB or even just programatic view configuration... The more I use them, the less I like them, and the more they feel like a gimmick/waste of time.

I have a problem with an iCloud shoebox application and hope some-one can help me (I've spent many hours fighting it in vain).

The App: - A simple library style application - containing set of categories (Cat1 .. CatN) each containing items (Item1...ItemM). I used Apple's iPhoneCoreDataRecipes to set up iCloud CoreData stack.

Everything works almost perfect with iCloud except - there should be a number of pre-filled empty categories the user can start using once he has opened the app for the first time (he can also be offline at that time). And here's the devil.

Here's what I do - Once my persistentStoreCoordinator is setup I send notification

dispatch_async(dispatch_get_main_queue(), ^{
    [[NSNotificationCenter defaultCenter]
        postNotificationName: @"RefetchAllDatabaseData"
                      object: self
                    userInfo: nil];
    });

which is received by my MasterViewController. When the notification is received MasterViewController checks the number of categories in the storage. If the number of available categories equals 0 - the pre-filled categories are inserted.

FYI - I use NSMergeByPropertyObjectTrumpMergePolicy for my ManagedObjectContext

The problem: This works well for the 1st device. But for the 2nd device the default categories from iCloud are often received later than persistentStoreCoordinator has been setup (and default categories inserted by 2nd device). In the end I have 2 sets of categories with the same names on both devices.

Any ideas how this can be solved?

Tried solutions: I tried 2 strategies to solve this. Both start in the same way. After I call

[moc mergeChangesFromContextDidSaveNotification: note];

I call

[self materializeKeysWithUserInfo: note.userInfo forContext: moc];

many thanks to Jose Ines Cantu Arrambide from https://devforums.apple.com/thread/126670?start=400&tstart=0 for his reference code - In essence

materializeKeysWithUserInfo:forContext:

get managedObjectIds from note.userInfo and retrieves corresponding objects from ManagedObjectContext putting them into a dictionary.

Strategy 1:

• All my categories have creation time-stamps.
• On insert from iCloud, get pairs of categories with same name if any
• Select older duplicate categories
• move their items to newer duplicate categories
• delete older duplicate categories

These strategy effectively removes duplicates on both devices even before they appear in the UI BUT

1) the items from 1st device are getting lost on the 2nd device - when they come to the 2nd device their parent category is absent and their category field equal nil so I don't know where to put them.

2) in some short time the items that got lost on the 2nd device are also getting lost on the first due to conflicts.

3) some items originating from the 2nd device are also lost due to conflicts.

I tried to prefer older categories against newer but it didn't give any effect

Strategy 2:

• All my categories have creation time-stamps.
• All categories have obsolete boolean field set to NO on creation
• On insert from iCloud, get pairs of categories with same name if any
• Select older duplicate categories
• move their items to newer duplicate categories
• mark older categories with obsolete = YES

These strategy almost always removes duplicates on both devices even before they appear in the UI BUT

the majority (or all) of the items from both devices are getting lost due to a bunch of conflicts on categories and items.

Some concluding thoughts:

It looks like these strategy doesn't work as we start simultaneously changing content ob both devices whereas iCloud is not suitable for such pattern.

In my tests I had both devices running simultaneously. I cannot neglect a case when a happy user who has just bought his 2nd iDevice installs my app on the 2nd device (with tre 1st device running the app) and get lost all his items in the matter of minutes.

Any ideas how this situation can be solved? Do you think iCloud + CoreData is ready for production?

Strategy 3

I've tried to put a pre-filled database (copying it from bundle) to the appropriate path. It worked out partly - I have no more pre-filled categories duplication BUT the items added to the pre-filled categories do not synchronize across the devices.

iCloud is not aware of the data that exists in the database prior to iCloud setup - my 2nd device receives items, inserted on the 1st device in pre-filled categories, with category = nil.

Items in additionally categories (as well as categories themselves) inserted into the storage after iCloud setup do synchronize properly.

Strategy 1 with some modifications appeared to be a working solutions (with some flaws though).

Legend:

• 1st device - started online without any content in the iCloud
• 2nd device - started later than first and OFFLINE. Then it gets online after some items added

So here's the updated strategy:

• All my categories have creation time-stamps

• The categories cannot be renamed (only added or deleted - this is crucial)

• All my items have a string categoryName field which gets its value upon item creation and updated whenever item is moved to a different category - this redundant information helps to achieve success;

On insertion of new Categories:

• On insert from iCloud, I get pairs of categories with same name if any

• Select newer duplicate categories (they will most probably have less items than old ones so we will have less dance in iCloud)

• Move their items if any to older duplicate categories

• Delete newer duplicate categories

On insertion of new Items - if the item belongs to deleted category:

• CoreData tries to merge it and fails as there's no parent category any more (lots of errors in console). It promisses to insert it later.

• After some short time it does merge and insert the item into storage but with NIL category

• Here we pick our item up, find out it's parent category from categoryName and put it to the correct category

VOILA! - no duplicates & everybody happy

A couple of notes:

1. I get a dance of items belonging to the 2nd device (those that will come with nil category to the 1st device) on both devices. After a couple of minutes everything is stabilized
2. No items is lost though
3. The dance happens only on the first iCloud sync of the 2nd (or any other subsequent device)
4. If the 2nd device is started online for the first time the chance that duplicate categories case appears is about 25% only - tested on 3G connection - so dance should not affect the majority of users

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.

I've recently read the news on http://allseeing-i.com that ASIHTTP is being discontinued. I have much respect for the makers of the library. However, I am now looking for a substitute that also supports queued download (multithreaded) on iOS, that also supports a progress bar with appropriate information.

Is there any (hopefully lightweight) library, that is in an active development livecycle? ARC support would also be much appreciated.

Many thanks for your thoughts.

You may want to look at MKNetworkKit. In its words:

MKNetworkKit's goal was to make it as feature rich as ASIHTTPRequest yet simple and elegant to use like AFNetworking

It has a number of very nice features for queuing and managing offline situations.

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;