How to install “command line tools” with xcode 5.0.1

With Xcode 5.0.1 and Mavericks 10.9 the command line tools are no longer available via Xcode. There is only two ways to install command line tools.

1) Download directly from Apple developer downloads (https://developer.apple.com/downloads/index.action)

2) Using command line. Run this below command to install –

xcode-select --install

After you enter this command you’ll get a popup like below –

ZSTtJ

Just press Install and it will start downloading command line tools.. and you are good to go.

FacebookSDK/FacebookSDK.h file not found

If you are getting “FacebookSDK/FacebookSDK.h file not found” error, even if you have Facebook SDK included in your project? It might be possible that project is not able to access FacebookSDK because of some mis-configuration in references.

Your best bet to resolve this error is by  removing FacebookSDK.framework from your project and then start over with these steps. Re-linking the framework won’t help in many cases –

Step 1. Go to Build Phases in your Project Target.
Step 2. In Link Binary With Libraries, click the “+” button.
Step 3. Click on “Add Other…” button
Step 4. Browse your FacebookSDK folder. Generally in ~/Documents/FacebookSDK/
Step 5. Clik on (select) “FacebookSDK.framework” and then OPEN.

Hope this will save someone’s time!

Keyboard not working in iOS simulator?

If your keyboard (mac keyboard) is not working in the iPhone simulator you must have something wrong in iPhone Simulator preference file.

To fix the problem follow this –

0) Quit Xcode and simulator
1) Press ‘command+shift+g’ .. it will open the “go to folder” dialog.
2) type “~/Library/Preferences” in this dialog to go to your preference folder.
3) Delete “com.apple.iphonesimulator.plist” in this folder
4) Done. “com.apple.iphonesimulator.plist” will be regenerated when you start simulator again.

Alternatively you can also do this with just one command.

Open terminal and fire –

rm ~/Library/Preferences/com.apple.iphonesimulator.plist

This will do the trick in one step! Just make sure you quit Xcode and simulator before running this.

Xcode 4.2 documentation offline install

If you have installed the new Xcode 4.2 (only a 1.6 GB file instead of the former 4GB file), you will notice that documentation does not work properly, actually people have been complaining about it and the solution was to download the documentation from inside Xcode preferences.

But if you are a team of iOS developers and want to download the documentation only once and install it on many machines running Xcode?
Here you are the steps:
1. Download the documentation from Xcode from any machine.
2. Go the download installation (See Figure Below)


3. Copy the “documentation set” files (it is actually packages with a lot of file so it is recommend to zip them).
4. Move them to the same location where you installed Xcode on the other machines
5. Restart Xcode.
6. Done.

Automatic Reference Counting (ARC) in Xcode 4.2

Xcode 4.2 now includes a new feature called Automatic Reference Counting aka. ARC which automates memory management for Objective-C objects. ARC makes memory management much easier, greatly reducing the chance that your program will have memory leaks. First, Xcode reviews your project to determine whether there are items that cannot be converted (and that you must therefore change manually). Then, Xcode rewrites your source code to use ARC.

ARC works by adding code at compile time to ensure that objects live as long as necessary, but no longer. Conceptually, it follows the same memory management conventions as manual reference counting, by adding the appropriate retain, release, and autorelease method calls for you.

ARC is supported in Xcode 4.2 for Mac OS X v10.6 and v10.7 (64-bit applications) and for iOS 4 and iOS 5. Weak references are not supported in Mac OS X v10.6 and iOS 4.

Instead of you having to remember when to use retain, release, and autorelease, ARC evaluates the lifetime requirements of your objects and automatically inserts the appropriate method calls for you at compile time. The compiler also generates appropriate dealloc methods for you. In general, if you’re only using ARC the traditional Cocoa naming conventions are important only if you need to interoperate with code that uses manual reference counting.

A complete and correct implementation of a Person class might look like this:

@interface Person : NSObject
@property (nonatomic, strong) NSString *firstName;
@property (nonatomic, strong) NSString *lastName;
@property (nonatomic, strong) NSNumber *yearOfBirth;
@property (nonatomic, strong) Person *spouse;
@end

@implementation Person
@synthesize firstName, lastName, yearOfBirth, spouse;
@end

Using ARC, you could implement a contrived method like this:

- (void)contrived {
    Person *aPerson = [[Person alloc] init];
    [aPerson setFirstName:@"William"];
    [aPerson setLastName:@"Dudney"];
    [aPerson:setYearOfBirth:[[NSNumber alloc] initWithInteger:2011]];
    NSLog(@"aPerson: %@", aPerson);
}

ARC takes care of memory management so that neither the Person nor the NSNumber objects are leaked.

You could also safely implement a takeLastNameFrom: method of Person like this:

- (void)takeLastNameFrom:(Person *)person {
    NSString *oldLastname = [self lastName];
    [self setLastName:[person lastName]];
    NSLog(@"Lastname changed from %@ to %@", oldLastname, [self lastName]);
}

ARC ensures that oldLastName is not deallocated before the NSLog statement.

ARC Enforces New Rules
To work, ARC imposes some new rules that are not present when using other compiler modes. The rules are intended to provide a fully reliable memory management model; in some cases, they simply enforce best practice, in some others they simplify your code or are obvious corollaries of your not having to deal with memory management. If you violate these rules, you get an immediate compile-time error, not a subtle bug that may become apparent at runtime.

  • You cannot explicitly invoke dealloc, or implement or invoke retain, release, retainCount, or autorelease.The prohibition extends to using @selector(retain), @selector(release), and so on.

    You may implement a dealloc method if you need to manage resources other than releasing instance variables. You do not have to (indeed you cannot) release instance variables, but you may need to invoke [systemClassInstance setDelegate:nil] on system classes and other code that isn’t compiled using ARC.

    Custom dealloc methods in ARC do not require a call to [super dealloc] (it actually results in a compiler error). The chaining to super is automated and enforced by the compiler.

    You can still use CFRetain, CFRelease, and other related functions with Core Foundation-style objects (see “Managing Toll-Free Bridging”).

  • You cannot use NSAllocateObject or NSDeallocateObject.You create objects using alloc; the runtime takes care of deallocating objects.
  • You cannot use object pointers in C structures.Rather than using a struct, you can create an Objective-C class to manage the data instead.
  • There is no casual casting between id and void *.You must use special casts that tell the compiler about object lifetime. You need to do this to cast between Objective-C objects and Core Foundation types that you pass as function arguments. For more details, see “Managing Toll-Free Bridging”.
  • Cannot use NSAutoreleasePool objects.ARC provides @autoreleasepool blocks instead. These have an advantage of being more efficient than NSAutoreleasePool.
  • You cannot use memory zones. There is no need to use NSZone any more—they are ignored by the modern Objective-C runtime anyway.

To allow interoperation with manual retain-release code, ARC imposes some constraints on method and variable naming:

You cannot give a property a name that begins with new.

Where is MainWindow.xib in Xcode 4.2 ?

In Xcode 4.2 the MainWindow.xib is not included for some of the project templates. Its means now we have to generate GUI elements by code or we can reconstruct the MainWindow.xib in project. I am describing you the second option here.

If you create a new project in XCode 4.2, and choose the Empty Application template to start from, change nothing and try running it in your iPhone 5.0 simulator, you will see an empty – black – screen. The only thing you get from the template is an AppDelegate.h and AppDelegate.m.

We’ll now reconstruct the MainWindow.xib file in our project. So the next thing is now to create a empty user interface file. Choose iOS > User Interface > Empty as template. The name of this file is not very important but we’ll use MainWindow.xib because this name is familiar to us.

Now select the Empty MainWindow.xib file we just created in previous step.

Change the Class of File’s Owner to UIApplication

Now drop a Object from Library to Objects in xib file.

Change the class of that object to the AppDelegate class

sd

Now add a window to objects pane.

Now we need to bind this window object to our code. To do this we have to add IBOutlet to window object in AppDelegate.h file. You code of AppDelegate.h should look like this –
</pre>
#import <UIKit/UIKit.h>

@interface AppDelegate : UIResponder <UIApplicationDelegate>

@property (strong, nonatomic) IBOutlet UIWindow *window;

@end

Note the IBOutlet just before UIWindow.

Now continue with editing MainWindow.xib file –

Control-Drag from the delegate outlet of the File Owner to the xAppDelegate object.

Control-Drag from the window outlet of the xAppDelegate to the Window.

Navigate to the project, and in the Summary tab, select MainWindow as the Main Interface.

We are almost done now..  But there is one more thing we need to fix. In AppDelegate.m, there was actually code that creates a window as well, so we have to delete this code.

self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

We are done now

Remove NSLog from whole xcode project

This is very good optimization if you remove all your NSLog statement from project. But its hard to find every NSLog and remove it if you have a big project.

This is very good optimization if you remove all your NSLog statement from project. But its hard to find every NSLog and remove it if you have a big project. Well here are two tips –

1) Use ifndef to replace NSLog with blank. Here is an example –

#ifndef __OPTIMIZE__
#define NSLog(...) NSLog(__VA_ARGS__)
#else
#define NSLog(...) {}
#endif

2) User regular expression in Find and replace to remove NSLogs

a) Press command + shift + f to open find and replace in whole project.
b) Search for

NSLog.*;

and replace it with blank

How to “add existing frameworks” in Xcode 4?

Are you not getting how to add existing frameworks in xcode 4?

Are you not getting how to add existing frameworks in xcode 4?
Well here is the right way of doing it –

1. In the project navigator, select your project
2. Select your target
3. Select the ‘Build Phases’ tab
4. Open ‘Link Binaries With Libraries’ expander
5. Click the ‘+’ button
6. Select your framework
7. (optional) Drag and drop the added framework to the ‘Frameworks’ group

How to find crash logs for iPhone applications on Mac and Windows

Application crash logs are transfered to your computer each time you do a sync with the device

Application crash logs are transfered to your computer each time you do a sync with the device, in the iTunes. Thus, first step is to sync with iTunes:

Mac OS X –

On the Mac, crash logs are kept at:

~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>

where ~ is your Home folder.

Windows Vista –

Files are located here:

C:/Users/<USERNAME>/AppData/Roaming/Apple computer/LogsCrashReporter/MobileDevice/<DEVICE_NAME>

AppData folder is hidden by default, , so you need to reveal it by typing the address in My Computer’s address bar.

Windows XP –

Location is here:

C:/Documents and Settings/<USERNAME>/Application Data/Apple computer/LogsCrashReporter/<DEVICE_NAME>

<USERNAME> is your login username. Application Data folder is usually hidden by default, so you need to reveal it in the same way as in Vista — by typing in and pressing Enter.

How to create .ipa file for your iPhone app : xcode build and archive

Build and Archive builds your application, code signs it, and stores the application folder along with its symbols file (which you need to decode crash logs generated by ad hoc or release builds).

In Xcode 3.2, Apple added a new feature to Xcode that makes ad hoc distribution more than a fair bit better. But, for the first few weeks of using Xcode 3.2, I didn’t even notice this item. This new item lives under the Build menu.

Build and Archive builds your application, code signs it, and stores the application folder along with its symbols file (which you need to decode crash logs generated by ad hoc or release builds). Xcode’s Organizer window gives you ready access to any previous build, and lets you e-mail an ad hoc build packaged up as an .ipa file with the mobile provisioning profile you compiled with embedded right into the application. This allows your clients or tester to simply drag the generated .ipa file into iTunes. The organizer will even generate an e-mail with the .iap embedded in it.


As part of Build and Archive, Xcode checks your application to make sure it’s code signed and provisioned properly. It may also (depending on your project settings) automatically run the new Validate feature that checks to make sure your application is valid for app store submission. This is the same check that the app review team will run on your app before actually looking at it. The details of what Validate checks are not documented, but in general terms, it will make sure everything is okay and that you haven’t used anything you shouldn’t have used. It’s not a guarantee that your app won’t get rejected because there’s still the manual review for content and HIG, but if your app passes validation, that’s one less possible obstacle between you and the app store. In other words, make sure you validate your apps before submitting them.

One thing to note, however, is that when you use Validate for ad hoc builds instead of building for submission to the app store (and I recommend that you do so that you find problems before testing rather than after), your app may fail one of the Validate checks. If you get this warning message when using either Build and Archive or Build and Validate with an ad hoc build:

warning: Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate. (-19011)

You might be fine (assuming you received no other warnings or errors). The difficult thing is that this warning can be generated by more than one specific problem, so there’s no way to know for sure whether this needs to be addressed other than to try and install the generated .ipa file on a non-development phone. You may (will?) get this warning with ad hoc builds even if the build is fine because you don’t use an “Apple submission certificate” for ad hoc builds.

One of the best things you can do is to have a second iPhone or iPod touch that’s not used for development (ever) that you can use to test ad hoc distributions. Even a second-hand, cheap iPod touch is sufficient since all you’re testing is that the install works If you do this, make sure you add the UDID of this unit to your ad hoc distribution profiles, but not to your development profile.

When you see this warning with Validate when building using an Ad Hoc Distribution configuration, don’t panic, but do try and install it on a machine that doesn’t have your development profile installed before sending it to a tester or client.