Ios – Xcode iOS project only shows “My Mac 64-bit” but not simulator or device

If using Xcode 4.2 or higher, try the following:

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

   

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

   

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

   

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:

   

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 not really disagreeing with DarkDust's answer, but if I may channel my inner Bill Clinton, it depends on what the meaning of supported is :)

Apple doesn't want you doing this for App Store apps, but the operating system certainly allows it. Jailbreak apps use this technique all the time. You basically use a standard UNIX technique to dynamically open a framework/library, and then use stuff in it. The dlopen function allows you to open the library by passing in the path to that framework, or dylib. From some docs for building jailbreak apps, here's an example of calling an init() function implemented inside your own, separate dylib:

#include <dlfcn.h>

initWrapper() {
    char *dylibPath = "/Applications/myapp.app/mydylib2.dylib";

    void *libHandle = dlopen(dylibPath, RTLD_NOW);
    if (libHandle != NULL) {
        // This assumes your dylib’s init function is called init, 
        //    if not change the name in "".
        void (*init)() = dlsym(libHandle, "init");
        if (init != NULL)  {
            init();
        }
        dlclose(libHandle);
    }
}

Furthermore, the default restriction against allowing you to build a dynamic library project for iOS is something in Xcode that you have the ability to override by editing some XCode xml files:

Build and use dylib on iOS

Once you do this, you can build a normal iOS .dylib library, and use it per the sample code above. (yes, you probably will have to unlock this capability again whenever you install a new XCode version).

So, it's not a technical limitation, but an App Store policy limitation. If you're not limited to the App Store, then you can do it. Note that this technique does not require jailbreaking, although if the app is sandboxed, it may limit where dylibs can be loaded from.

Edit: in order to make sure this information isn't lost to future link rot, here is the content of the link I provided on how to enable iOS dylibs in Xcode. (Note: this process still works on Xcode 4, but see comment(s) below for updates to paths, etc.) Source is the iOS Place blog:

Xcode does not allow you to build dylib for iOS. App will be rejected if it’s not single binary. But I have an application that has plug-in architecture to load optional modules. I just want a quick prototype to prove concept before fully port it to iOS. It’s faster to do if dylib could simply work. So, this post shows how to build and use dylib but be aware it won’t be approved to App Store. (Tested with Xcode 3.2.4 on 10.6.4)

1. Open these files in the Property List Editor: /Developer/Platforms/MacOSX.platform/Developer/Library/Xcode/Specifications/MacOSX Product Types.xcspec and /Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Xcode/Specifications/iPhone Simulator ProductTypes.xcspec

2. Locate the item in the “MacOSX Product Types.xcspec” that has the product type com.apple.product-type.library.dynamic and drag it to the “iPhone Simulator ProductTypes.xcspec”.

3. Open “MacOSX Package Types.xcspec” and “iPhone Simulator PackageTypes.xcspec” found at the same places.

4. Locate the item in the “MacOSX Product Types.xcspec” that has the package type com.apple.package-type.mach-o-dylib and drag it to the “iPhone Simulator PackageTypes.xcspec”.

5. Repeat the steps for the “iPhoneOS.platform” and relaunch Xcode if it was running.

Now, lets build a dylib. Start out with the “Cocoa Touch Static Library” Template. That should included the Foundation.framework in the project. Here are the changes I made on top of the template to build dylib.

1. Open the file project.pbxproj (found inside the Xcode project file bundle) in a Text Editor. Search for string “producttype”, change it’s value to com.apple.product-type.library.dynamic;

Now, open the project with Xcode, go to Project->Edit Project Settings

2. “Installation Directory” set to @executable_path/ because I plan to put the dylib in the same directory as the app’s executable.

3. “Mach-O Type” set to Dynamic Library

4. “Executable Extension” set to dylib

5. “Executable Prefix” set to empty

6. Add one or two simple methods to the library and build it.

Now, create an app to test it. This time, I choose the View-based Application. Hook up a UIButton and a UILabel to call the lib and showing return message. You can download the complete project TestApp and play with it.