Top xcode Questions

List of Tags
949
Ariel Malka

I can't find the good old "Add existing frameworks" option. How do I do this?

We're talking about Xcode 4 DP2 (in the context of iPhone development, as far as it matters...).

Answered By: Cyber ( 1365)

As per Apple's documentation:

  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

I am using ARC successfully in my project. However, I have encountered a few files (e.g., in unit tests and mock objects) where the rules of ARC are a little more fragile right now. I recall hearing that there was a way to disable ARC on a per-file basis, though I have been unable to find this option.

Is this possible? How do I disable ARC on a per-file basis?

Answered By: jaminguy ( 918)

It is possible to disable ARC for individual files by adding the -fno-objc-arc compiler flag for those files.

You add compiler flags in Targets -> Build Phases -> Compile Sources. You have to double click on the right column of the row under Compiler Flags. You can also add it to multiple files by holding the cmd button to select the files and then pressing enter to bring up the flag edit box.

I created a sample project that has an example: https://github.com/jaminguy/NoArc

xcode

See this answer for more info: Disable Automatic Reference Counting for Some Files

338
schwa

With a huge influx of newbies to Xcode, I'm sure there are lots of Xcode tips and tricks to be shared.

What are yours?

Answered By: epatel ( 343)

Switch to Header/Source File

  • Option ⌥ Command ⌘ Up Arrow ↑

  • View > Switch to Header/Source File

Switches between the .m and .h files.

  • In Xcode 4 this is ctrl Command ⌘ Up Arrow ↑

Which files should I include in .gitignore when using Git in conjunction with Xcode?

Answered By: Adam ( 129)

UPDATE 2013: the syntax for .gitignore is very hard to understand (badly implemented IMHO), and my last update didn't do as intended. I've updated it with something that APPEARS to do as intended

UPDATE: gist on github too, as requested: https://gist.github.com/3786883


I was previously using the top-voted answer, but it needs a bit of cleanup, so here it is re-done for Xcode 4, with some improvements.

I've also added some notes inline - I think it's risky to have files in a .gitignore if you don't explain why they're there :). Read the notes, if I've got anything wrong, please shout, and I'll re-research / modify / fix...

I've researched every file in this list, but several of them do not exist in Apple's official xcode docs (google couldn't find them, Developer.apple.com couldn't find them), so I had to go on mailing lists and heresay.

#########################
# .gitignore file for Xcode4 / OS X Source projects
#
# Version 2.0
# For latest version, see: http://stackoverflow.com/questions/49478/git-ignore-file-for-xcode-projects
#
# 2013 updates:
# - fixed the broken "save personal Schemes"
#
# NB: if you are storing "built" products, this WILL NOT WORK,
# and you should use a different .gitignore (or none at all)
# This file is for SOURCE projects, where there are many extra
# files that we want to exclude
#
#########################

#####
# OS X temporary files that should never be committed

.DS_Store
*.swp
*.lock
profile


####
# Xcode temporary files that should never be committed
# 
# NB: NIB/XIB files still exist even on Storyboard projects, so we want this...

*~.nib


####
# Xcode build files -
#
# NB: slash on the end, so we only remove the FOLDER, not any files that were badly named "DerivedData"

DerivedData/

# NB: slash on the end, so we only remove the FOLDER, not any files that were badly named "build"

build/


#####
# Xcode private settings (window sizes, bookmarks, breakpoints, custom executables, smart groups)
#
# This is complicated:
#
# SOMETIMES you need to put this file in version control.
# Apple designed it poorly - if you use "custom executables", they are
#  saved in this file.
# 99% of projects do NOT use those, so they do NOT want to version control this file.
#  ..but if you're in the 1%, comment out the line "*.pbxuser"

*.pbxuser
*.mode1v3
*.mode2v3
*.perspectivev3
#    NB: also, whitelist the default ones, some projects need to use these
!default.pbxuser
!default.mode1v3
!default.mode2v3
!default.perspectivev3


####
# Xcode 4 - semi-personal settings
#
#
# OPTION 1: ---------------------------------
#     throw away ALL personal settings (including custom schemes!
#     - unless they are "shared")
#
# NB: this is exclusive with OPTION 2 below
xcuserdata

# OPTION 2: ---------------------------------
#     get rid of ALL personal settings, but KEEP SOME OF THEM
#     - NB: you must manually uncomment the bits you want to keep
#
# NB: this is exclusive with OPTION 1 above
#
#xcuserdata/**/*

#     (requires option 2 above): Personal Schemes
#
#!xcuserdata/**/xcschemes/*

####
# XCode 4 workspaces - more detailed
#
# Workspaces are important! They are a core feature of Xcode - don't exclude them :)
#
# Workspace layout is quite spammy. For reference:
#
# /(root)/
#   /(project-name).xcodeproj/
#     project.pbxproj
#     /project.xcworkspace/
#       contents.xcworkspacedata
#       /xcuserdata/
#         /(your name)/xcuserdatad/
#           UserInterfaceState.xcuserstate
#     /xcsshareddata/
#       /xcschemes/
#         (shared scheme name).xcscheme
#     /xcuserdata/
#       /(your name)/xcuserdatad/
#         (private scheme).xcscheme
#         xcschememanagement.plist
#
#

####
# Xcode 4 - Deprecated classes
#
# Allegedly, if you manually "deprecate" your classes, they get moved here.
#
# We're using source-control, so this is a "feature" that we do not want!

*.moved-aside

####
# Cocoapods: cocoapods.org
# 
# Ignoring these files means that whoever uses the code will first have to run:
# pod install
# in the App.xcodeproj directory.
# This ensures the latest dependencies are used.
Pods/
Podfile.lock


####
# UNKNOWN: recommended by others, but I can't discover what these files are
#
# ...none. Everything is now explained.

How do I set up NSZombieEnabled and CFZombieLevel for my executable in Xcode 4?

Answered By: Jano ( 529)

In Xcode 4.x press

R

select the "Diagnostics" tab and click "Enable Zombie Objects":

Click "Enable Zombie Objects"

This turns released objects into NSZombie instances that print console warnings when used again. This is a debugging aid that increases memory use (no object is really released) but improves error reporting.

A typical case is when you over-release an object and you don't know which one:

  • With zombies: -[UITableView release]: message sent to deallocated instance
  • Without zombies: EXC_BAD_ACCESS

This Xcode setting is ignored when you archive the application for App Store submission. You don't need to touch anything before releasing your application.

Pressing ⌥⌘R is the same as selecting Product > Run while keeping the Alt key pressed.
Clicking the "Enable Zombie Objects" checkbox is the same as manually adding "NSZombieEnabled = YES" in the section "Environment Variables" of the tab Arguments.

270
quantumpotato

Tried to rebuild an app that was just working yesterday. Got a message that a profile had expired, so I removed it from the iPod and from Itunes. When I chose a new profile (one with an * in the identifier), I now get an error:

Code Sign Error: Provisioning Profile (long string) can't be found.

What am I missing? I looked through related questions and didn't see this scenario already. Thanks

Answered By: Brad Smith ( 564)

Sometimes your xcode project file gets messed up, especially if you have an old project and first created it with an older version of xcode/iphone sdk. What you need to do is open up the project file in a text editor, search for the 'long string' from your error and manually erase that line. In fact, you should just go ahead and erase any line that points to any provisioning profiles. Then reopen the project in xcode, go to the settings and reselect your new profile. This clears up issues like that most of the time. The lines that point to the provisioning profiles will look like this:

PROVISIONING_PROFILE = "487F3EAC-05FB-4A2A-9EA0-31F1F35760EB";
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "487F3EAC-05FB-4A2A-9EA0-31F1F35760EB";
257
Nick

It's been a while since I've had to adjust project build settings. After upgrading to a recent SDK I'm having trouble building my ad hoc distribution configuration.

Build generates this warning and error:

warning: iPhone apps should include an armv6 architecture (current ARCHS = "armv7")

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

However in my project I thought I had things set correctly:

  • Architectures is: Standard (armv6 armv7)
  • Base SDK: Latest iOS (currently set to iOS 4.2)
  • Valid Architectures: armv6 armv7

alt text

I have cleaned all targets.

Appreciate any tips. Thanks!

Answered By: Nick ( 383)

If using Xcode 4.2 or higher, try the following:

  1. Click your Project name (in the left column), followed by the Target:

    enter image description here

  2. Click the 'Build Settings' tab (in the right column):

    enter image description here

  3. Click the 'Release' or 'Distribution' row under 'Architectures', and choose 'Other...':

    enter image description here

  4. Double click the highlighted row named '$(ARCHS_STANDARD_32_BIT)' in the popover that appears, and replace it by typing 'armv6'. Then add a new row with the plus button in the bottom left of the popover, and type 'armv7', then click Done:

    enter image description here

Update: you should add armv7s to target the iPhone 5 as well. (And drop armv6 if building with Xcode 4.5 or higher, which no longer supports armv6.)

That's it. You should now be able to build/archive without generating errors.

If it still doesn't work, see this answer from justinxreese, which suggests adding entries for armv6 and armv7 under "Required Device Capabilities" in your info.plist file.

I'm doing a presentation on debugging in Xcode and would like to get more information on using NSLog efficiently.

In particular, I have two questions:

  • is there a way to easily NSLog the current method's name / line number?
  • is there a way to "disable" all NSLogs easily before compiling for release code?
Answered By: Diederik Hoogenboom ( 300)

Here are some useful macros around NSLog I use a lot:

#ifdef DEBUG
#   define DLog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__)
#else
#   define DLog(...)
#endif

// ALog always displays output regardless of the DEBUG setting
#define ALog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__)

The DLog macro is used to only output when the DEBUG variable is set (-DDEBUG in the projects's C flags for the debug confirguration).

ALog will always output text (like the regular NSLog).

The output (e.g. ALog(@"Hello world") ) will look like this:

-[LibraryController awakeFromNib] [Line 364] Hello world
237
Robert Gould

I began an iPhone project the other day with a silly development code name, and now I want to change the name of the project since its nearly finished.

But I'm not sure how to do this with Xcode, trying the obvious of changing the application's name in the pinfo, causes the signing process to go wrong (I think...) and my app won't launch giving me a Launcher error.

I guess I could make a new project and copy paste everything over, but it seems so primitive, that I'm hoping for a more civilized solution.

Thanks!

Answered By: Giao ( 303)
  1. Go to Targets in Xcode
  2. "Get Info" on your project's target (your current silly development name)
  3. Search for "Product Name" under "Packaging". Change the value of that what you want the new program name is going to be.

What frameworks exist to unit test Objective-C code? I would like a framework that integrates nicely with Xcode.

Answered By: Chris Hanson ( 220)

Xcode includes OCUnit, an Objective-C unit testing framework, and support for running unit tests (OCUnit or otherwise) as part of your project's build process. Xcode's unit testing support is described in the Xcode Unit Testing Guide.

I've written a series of weblog posts about how to perform some common tasks with Xcode unit testing:

Finally, I've written a few posts on how to write tests for Cocoa user interfaces; the way Cocoa is structured makes it relatively straightforward, because you don't have to spin an event loop or anything like that in most cases.

This makes it possible to do test-driven development for not just your model-level code but also your controller-level and even view-level code.