Category: Mac OS X

Categories
ios iphone Mac OS X

Xcode: “No match for certificate/private key” error and resolution

An app we were building for the iPad was recently approved by the client. Being a more capable organization, the client wanted us to build the app for them using their Apple developer and app store credentials for submission. To do that they sent us the three necessary files:

  • Public Key (Distribution)
  • Private Key (Distribution)
  • Mobile Provisioning Profile (Distribution > AppStore)

I also modified the app's bundle identifier to reflect the identifier specified by the client.

I merrily added the keys and certificate to the OS X key chain. Yet Xcode was unable to build using these updated credentials. The error that was reported was:
"Profile does not match any valid certificate/private key pair in the default keychain"

After digging around I pinged my friend Glenn Martin from Intrepid Development to see if he knew what was wrong. Glenn actually knew what went wrong: apparently OS X 10.6.8 imports keys to the System key chain instead of the Login key chain. Xcode only looks at the Login key chain. All the was necessary to fix the issue was to drag and drop the key in the Keychain Access application from the System key chain to the Login one. Mindless fix to a truly frustrating problem.

Hope it helps you.

Share
Categories
Computing iphone Mac OS X

Why I am uninstalling Xcode 4 gm seed Beta

The person who helps tutor me into iOS happiness recommended that I try Xcode 4's beta. He felt is was ripe and ready to go. I followed his advice, installing Xcode in a separate directory than Xcode 3 (.2.5). Today I am uninstalling Xcode 4's beta. Here's are some of my impressions from my experience:

  1. Git integration: great step forward here. Xcode embraces the Git version control system and detects existing command-line setups. Only thing is that Xcode only allows you to commit to your local repository. There is no push capability.
  2. Adding files – source code or images – is a huge issue. Drag and drop does not work properly and mostly ends up with an error message. More crippling is the fact that if you use the navigation menu to import files into your project, it imports them into a purgatory area that appears above the root project icon in the file listings view. What causes the real issue is the fact that if you then try to move those files back into the project by dragging them, they will be copied into the project. There is no way to delete them from the purgatory state inside Xcode. If you try to compile the project, the compiler will complain about duplicate files (even images) with the same name. If you delete the file from the command line or finder, you are stuck with 'ghostly' listings. The project will compile but the clutter grows.
  3. Xcode 4 sets up a new project structure, different than Xcode 3. It has fewer folders and overall seems a bit more cluttered to my newb eyes. Adding groups is also unintuitive as the only way to name a new group is by creating it first, and then single-clicking its name.
  4. Project properties are a huge step forward. Configuring Xcode to use libraries and set up apps on the iPhone and iPad is now outside of the source plists and in a pleasant user experience.
  5. Xcode 4 integrates Interface Builder into the IDE's window; no longer a separate app. It uninstalled Xcode 3's version of Interface Builder and if you try to open xib files in Xcode 3 it opens Xcode 4's version. That would still be cool had it not for the fact that the new Xcode 4 Interface Builder has issues in detecting properties in the files you create in Xcode 4.  

In summary – Xcode 4 works, mostly. It does crash – but gracefully. Yet I would recommend against installing it for serious development and even more, against installing it side by side with Xcode 3. 

Share
Categories
Computing iphone Mac OS X

Private methods in Objective-C

Coming from the Java world, I love, care and embrace all things private, including private methods. Objective-C supports the feature but it appears to me (based on very shallow Googling) that there is not too much familiarity (or use) with it. I looked in a book I recently acquired, Learn Objective-C for Java Developers (Learn Series). While not a book a perfect book, it does cover the how-to of private methods in Objective-C.  

The key to the approach is to leverage Objective-C categories. Categories are a mind-blowingly nifty in the fact that they allow you, among other things, to augment objects you did not create with your own methods. While there are other ways of 'hiding' private methods, most of them result in warnings in Xcode. So here goes…

Say you have an object called CoolWidget. You create the header file (CoolWidget.h)for it as usual, i.e.:

@interface CoolWidget:NSObject
{
    int publicVar;

    @private
    int somePrivateVar;
}

// public methods
-(void) doSomething:(BOOL)cool;

@end

To add private methods to it, you would create a category for the object in a separate header file (CoolWidget+Private.h):

@interface CoolWidget (Private)

// private methods
-(void) doSomethingPrivate:(BOOL)cooler;

@end

All that's left for you to do is to include the additional header file, CoolWidget+Private.h in your implementation file, CoolWidget.m (though categories are often/normally implemented in their own .m file).

Update:

As my friend Glenn Barnett points out in his tweet, there is no such think as private methods in Objective-C. Unlike C++ or Java, there is no real 'enforcement' of access to the methods. Privacy, overall, is purely by convention. 

Share
Share