We were supporting iOS 6 & 7 previously for our universal iOS application (which means we support both iPhone and iPad). Now, with the release of iOS 8, we have to support iOS 6, iOS 7 & iOS 8. Also, we have to extend our targeted device list to support iPhone 6 and iPhone 6 Plus.
Also, we are planning to upgrade to Xcode 6 shortly. Because Apple may anytime mandate the use of Xcode 6 to be able to submit apps to app store.
Keeping all the above points in mind, I am confused what should be my Architecture settings in Xcode build settings. Mainly There are 3 important items under Xcode Architectures settings. Please see the below screenshot.
I have highlighted the 3 important parameters. I want to know what values I should assign to these parameters in order to support all the above. Any help will be greatly appreciated. I am confused a bit with this.
Also, I would like to know if i need to change anything else in order to migrate to Xcode 6 and iOS 8.
In Architectures, you'll be fine with armv7, armv7s, arm64, i386, where i386 is for the Simulator. The rest can be left default values.
UPDATE: It is not required to mention desktop architectures (i386, x86_64) in order to support the build for iOS Simulator. Given Simulator is supported just by including respective ARM architecture. Hence, Architectures are fine if populated just with armv7 armv7s arm64. By observing, since Xcode 6.3 it might even cause build to fail if the setting contains any of the desktop architectures.
Valid architectures can be set individually for each target, Xcode will make intersection of the global Architectures setting with this. If you are not interested, leave it untouched, Xcode will cope with that on its own without problems.
In case your code is not 64bit ready, remove arm64 from Architectures. App will still run on iOS 8 and all the recent 64bit devices.
As for the Build Active Architecture Only, I recommend setting it to No. This property affects what Xcode decides to build e.g. based on currently connected device. But it may happen problems arise: you may end-up with some targets are built for different architecture, resulting in linking errors. Nevertheless, if you would like to use the pros of the feature, set it to Yes just for Debug or some sort of configuration used only for testing, not the final release. Xcode will build all binaries only for one of all the architectures you have set in Architectures x Valid then.
If you're not an expert on your target architectures, remove all architectures and add armv7 and armv7s. Also, if you're building only for iOS, check your targets so that Xcode isn't building other OSes (that may require other architectures).
Related
I upgraded Xcode version and when using external static libraries, I get this message:
ld: file is universal (3 slices) but does not contain a(n) armv7s slice: /file/location for architecture armv7s
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Is there any way to bypass this and add support to the library if the developer of the library hasn't updated their library yet?
If you want to remove the support for any architecture, for example, ARMv7-s in your case, use menu Project -> Build Settings -> remove the architecture from "valid architectures".
You can use this as a temporary solution until the library has been updated. You have to remove the architecture from your main project, not from the library.
Alternatively, you can set the flag for your debug configuration's "Build Active Architecture Only" to Yes. Leave the release configuration's "Build Active Architecture Only" to No, just so you'll get a reminder before releasing that you ought to upgrade any third-party libraries you're using.
I've simply toggled "Build Active Architecture Only" to "Yes" in the target's build settings, and it's OK now!
Try to remove armv7s from project's "Valid architecture" to release from this issue for iOS 5.1 phone
I just posted a fix here that would also apply in this case - basically, you do a hex find-and-replace in your external library to make it think that it's ARMv7s code. You should be able to use lipo to break it into 3 static libraries, duplicate / modify the ARMv7 one, then use lipo again to assemble a new library for all 4 architectures.
Flurry Support for iPhone 5 (ARMv7s)
As I mentioned in yesterday’s post, Flurry started working on a version of the iOS SDK to support the ARMv7s processor in the new iPhone 5 immediately after the announcement on Wednesday.
I am happy to tell you that the work is done and the SDK is now available on the site.
use menu Project -> Build Settings ->
then remove armv7s from the"valid architectures".
If standard has been chosen then delete that and then add armv7.
In case this happens to someone. I built my own library to use with a third party code. While I was building it to deliver, I accidentally left my iPhone 4S plugged in, and so Xcode built my library only for the plugged architecture instead of following the project settings. Remove any plugged in devices and rebuilt the library, link it, and you should be all right.
Hope it helps.
In my case, I was linking to a third-party library that was a bit old (developed for iOS 6, on XCode 5 / iOS 7). Therefore, I had to update the third-party library, do a Clean and Build, and it now builds successfully.
I have developed an application using xcode 4.3.2 with ARC enabled ,my app users having ios3.2, ios4.0,ios5.0 devices how can I give support to lower version ios device uses .Should I need to do anything in code side . or Is there any way set ARC dynamically like.
Any have any idea regarding this plz share with me.
Thanks
ARC is not device- or OS-dependent (see note below). It is a LLVM compiler feature (which can be disabled using the -fno-objc-arc compiler flag). The compiler manages the memory instead of the programmer. The final executables will not be very different from one another and will work on the minimum OS specified for your project (if you are not using ARC-specific keywords, etc.).
Note:
According to Apple's Transitioning to ARC Release Notes from Apple, ARC-compiled executables will only run on iOS 4 and above. In addition, weak references are only supported on iOS 5.
Just set the target deployment to the lowest iOS version your users might be on.. AutoMatic Reference Counts only while compiling the app in Xcode. The memory of app enabled ARC is managed by compiler (Xcode). So you need not to worry about the target iOS version of the device. Just set the Target Deployment to 3.2 or 4 etc.
I think at least it is not guaranteed to work correctly on iOS 3.x. See Transitioning to ARC Release Notes from Apple:
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.
I am about to upload my very first app and I changed the deployment target 30 ios 3.0 and I am getting a warning that I have no idea what to with. If anyone could help me out, it would be much appreciated since I am basically done! (I hope). Its talking about some arv6 architectures and I don't know what that means.
Thanks!
[BWARN]warning: iPhone apps with a deployment target lower than 4.3
should include an armv6 architecture (current
IPHONEOS_DEPLOYMENT_TARGET = "3.0", ARCHS = "armv7").
warning: iPhone/iPod Touch: application executable is missing a
required architecture. At least one of the following architecture(s)
must be present: armv6 (-19033)
In your project -> build settings -> architectures, try adding an arm6 architecture
See this answer, it has a step by step process of how to add an architecture
"Warning: iPhone apps should include an armv6 architecture" even with build config set
Better question - why do you feel you need to support iOS3.x?
At this point you should switch to ARC and support only 4.x devices or greater, unless there is an absolutely compelling need. Remember that percentage wise only a tiny number of devices at this point are restricted to iOS3.
I recently did some research on making a cocos2d app for iPhone/iPad AND Mac. I have done the iPhone/iPad route but have never done it with a Mac target. It appears that some people have added it as a target but mentioned that it is finicky and others have suggested making a separate Cocos2d Mac project that uses the same files. Any wisdom to impart here?
I believe it is absolutely crucial to have both iOS and Mac targets in the same project. Otherwise you'll spend too much time keeping one platform in synch with the other, until eventually you either manage to create a good (but still time-consuming) workflow - or end up neglecting one of the two platforms.
Ideally the code base should make as little use as possible of compiler macros. You'll want to compile both iOS and Mac code even if it's not being used for one platform. So having some classes or methods that are #ifdef'ed to Mac, others to iOS, will more often than not lead to compile errors when you switch targets. That means wrapper classes, so that you can write the same code regardless of the platform, are essential.
Right now, Cocos2D doesn't offer you to create iOS & Mac targets in the same Xcode project. The way to get there isn't immediately obvious either, because each target requires its own build settings for: Base SDK, SDK Root, Deployment Target, Architectures and possibly Compiler version. It gets worse if you also want to use 3rd party libraries (Box2D, Chipmunk, etc) because in some cases you'll be forced to create iOS and Mac specific targets for those libraries as well - if only to ensure that the library is built with the same compiler as the project's target, otherwise you can run into the strangest build or runtime issues.
I've had issues getting these platform specific targets to work within a single Xcode project without Xcode complaining or otherwise misbehaving. I haven't tried it with Xcode 4.1 and 4.2. By that time I had created .xcconfig files to host the build settings. The .xcconfig files may or may not be necessary with the more recent Xcode versions but they definitely make managing multiple platform-specific targets easier.
Long story short, the best and easiest way to do cross-platform development with cocos2d-iphone is by using Kobold2D.
Most of the 15 template projects have an iOS and Mac target in each project, you just need to select the corresponding scheme, then hit build & run. The most commonly needed platform-specific code (processing user input) is wrapped in a platform-agnostic, simple to use wrapper class KKInput.
Disclaimer: I'm the developer of Kobold2D. There's a slim chance that I may be biased. You should try Kobold2D anyway. :)
i have installed the latest iphone sdk 3.0 beta 5, and trying to submit the first application build from this sdk,but when i upload to itunes connect, it give me the message "The binary you uploaded was invalid. The value provided for the key MinimumOSVersion is not acceptable." and cannot be uploaded. therefore i edit my info.plist file in the project and set this key to 2.2.1,like
<key>MinimumOSVersion</key>
<string>2.2.1</string>
and upload again but it still return the same message,have anybody met the same issues and how to get rid of this?
You SHOULD NOT specify MinimumOSVersion in your Info.plist. From the Information Property List Key reference:
MinimumOSVersion (String - iPhone OS, Mac OS X). When you build an iPhone application, Xcode notes the target OS (as determined by the Base SDK selection) as the MinimumOSVersion property. Do not specify this property yourself in the Info.plist file; it is a system-written property. When you publish your application to the App Store, the store indicates the iPhone OS release on which your application can run based on this property. It is equivalent to the LSMinimumSystemVersion property on Mac OS X.
What you need to do is change the Deployment Target setting in your project. The Deployment Target specifies the minimum OS you would like your application to run on. This is regardless of the SDK you build against, which should always be the most recent SDK so you can ensure your application runs correctly on the most recent OS version available. So, in short:
Set the Base SDK to be the latest OS available
Set the Deployment Target to be the earliest OS you'd like your app to run on.
Manually editing the Info.plist file is really just fooling the App Store into thinking your app can run on an OS it isn't built to run on, which could yield unpredictable results.
Please read the notice in the iPhone developer centre. You CANNOT use the iPhone 3.0 SDK to build apps for the App Store at the moment, not even if you compile them for the 2.x OS. You have to compile an app using the 2.x SDK to submit it to the App Store.
You can install both sets of developer tools side by side. When you get to the screen where you select which parts of the package you want to install, you can select an alternative destination for the install.
I had the same problem. Heres how to fix it!
My project was called SuperTennis, so I clicked the project in xcode, and clicked Get Info. Under the General tab, change "Base SDK for all iPhone configurations" to iPhone OS 2.0, then go into the build tab, and change "Base SDK" to "iPhone OS 2.0", then build it for your device. Reveal the app in finder, and then continue on, to upload it. Email me at ryan2925 at gmail.com if you want some more help. I hope this works for you, and anyone else reading.
I got this error when I finally upgraded things from 2.2.1 to the 4.0 SDK, and tried to use an existing project.
I had to:
Click on the project in XCode, then click on Info.
Click 'Build'
Pay attention to what 'Configuration' you are setting. Are you accidentally setting distribution when you are trying to debug?
Set 'Base SDK' to the highest possible.
Change 'Target Device Family' to whatever it is you are doing.
Set 'iPhone OS Deployment Target' to your device's OS (you can check by going to Window > Organizer).
My main time sink was setting my distribution settings when trying to debug and not realizing it.
Try this:
ARMV6: before iPhone 3GS
ARMV7: including and after iPhone 3GS
"Proj." and "Target(s)" right-click, Get Info. Select:-
Base SDK: iPhone 4.0 (latest s greatest)
Standard: ARMV6, ARMV7
Uncheck build for Active Architecture
Deployment Target: 4.0 (not older ones 3.1.3; you don't have the SDK if you upgrade to 4.0)
Compiler section: Ensure that both ARMV6 and ARMV7 checkboxes are ticked under Generate Code, Thumb section.
The binary output is slightly bigger as it is generic code that supports both architectures.
If you want to support ARMV7 only, don't check ARMV6 in compiler section, selection code optimised for ARMV7, check active architecture only. In info.plist, add armv7 in UIRequiredDeviceCapabilities items. This field already exists in info.plist and probably has other system requirements auto-specified.
Right click on your project and go to your build tab. Near the top of the list you can specify your Base SDK. This is the minimum you will compile against. After this your build settings drop down will have the older versions. When you go to make your distribution make sure you aren't using 3.0 cause that will cause your binary to get rejected (as you found out).