iPad Build Settings - ios

I am finding conflicting information about the armv of an iOS application. I am creating an iPad only application. The application should be able to run on all iPads (all three generations). The application has 5.1 as its deployment target.
I did not bother about all this until Xcode 4.5 showed up. I updated my Xcode (and hence the iOS simulator got updated as well to 6.0) when suddenly my application stopped working. I figured out setting the 'Build Active Architecture Only' to 'Yes' allowed me to continue programming. I cannot stand the fact however to change settings without exactly knowing what they do. That's why I am stuck with following questions:
Does armv7 cover all iPad generations?
How come my application throws 'file is universal (4 slices) but does not contain a(n) armv7s slice' when setting 'Build Active Architecture Only' to 'No'? (This is when testing on a iPad 1.) Because I thought setting it to 'No' means you are generating a fat binary.
Which settings do I need eventually to run on all iPads? Are there multiple configurations possible (I assume not), and so, which are preferred?
Current settings are:
Architectures: Standard (armv7, armv7s)
Base SDK: Latest iOS (iOS 6.0)
Build Active Architecture Only: Yes
Valid Architectures: armv7 armv7s
Thanks for reading if you made it till this point.

Related

Error creating LLDB target at path, Xcode 6 GM seed,the screen stuck [duplicate]

I'm getting this error whenever I build in XCode 6 beta 4. It seems to be making my app insanely slow.
Warning: Error creating LLDB target at path
'/***/***/***/***.app'- using an empty LLDB target which
can cause slow memory reads from remote devices.
What exactly does this mean and how do I fix it?
Thanks in advance!
Did you use Architectures=$(ARCHS_STANDARD_32_BIT) and run your app on a 64 bit device? (iPhone 5S or iPhone 5S simulator)
Apple seems to be stricter with apps which don't support 64bit. So if there is no specific reason, I think it's better to include arm64 in your build architecture
NOTE ABOUT 64-BIT ARCHITECTURE
An app extension target must include the arm64 architecture in its Architectures build settings or it will be rejected by the App Store. Xcode includes this architecture with its “Standard architectures” setting when you create a new app extension target.
If your containing app target links to an embedded framework, the app must also include the arm64 architecture or it will be rejected by the App Store.
For more information about 64-bit development, see 64-Bit Transition Guide for Cocoa Touch or 64-Bit Transition Guide for Cocoa, depending on your target platform.
Source: https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
This warning is solved by changing Build Settings :
Select Project -> Build Settings
Change 'Architectures' to 'Standard architectures (armv7, arm64) - $(ARCHS_STANDARD)'
This will prompt an alert stating iOS 5.1.1 and above are supported. Click 'Change Deployment Target to 5.1.1'
Repeat steps for Target (if not changed automatically)
Also, this is preferred build setting since Apple is forcing developers to build apps on 64 but architecture. Apple document Link
Double Check Build Settings => Valid Architectures for both Project and Target.
Mine used to say: arm64 armv7 i386 (The one causing the error was i386)
I replaced it to : arm64 armv7
I hope that helps.
In Xcode 6.4 , Swift 1.2. I had to edit both the Project and Target to the correct arm verisons (arm64, armv7 and armv7s). Take a look:
My "Architectures" included arm64 but I had to add arm64 to "Valid Architectures" in the target.
In my case I had to change Build Active Architecture Only to YES for the Debug configuration.

Error creating LLDB target at path, Xcode 6 GM seed

I'm getting this error whenever I build in Xcode 6 GM Seed. It seems to be making my app insanely slow. What exactly does this mean and how do I fix it?
I had the following error:
Warning: Error creating LLDB target at path '.....'- using an empty
LLDB target which can cause slow memory reads from remote devices.
PS: im not able to run my app, its stuck on the splash screen
There is a thread in the Apple Developer Forum, https://devforums.apple.com/message/1010068#1010068 that describes how to diagnose this issue. I had his issue for Xcode 6 GM Seed, specifically - Version 6.0.1 (6A317). This isn't necessarily a solution, but it may help some people get a better diagnosis
Useful steps are as follows -
1) Create or modify your ~/.lldbinit and add log enable -f /tmp/lldb-api.txt lldb api to it.
2) Rerun your debugger session (no need to restart Xcode or anything)
3) Inspect the file at /tmp/lldb-api.txt. Look for a line beginning with SBDebugger::CreateTarget(...). Mine looked something like this
SBDebugger(0x7f83671fd600)::CreateTarget
(filename="/Users/xxxxxxx/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app",
triple=x86_64, platform_name=(null), add_dependent_modules=1,
error=the specified architecture 'x86_64' is not compatible with
'i386-apple-ios' in
'/Users/xxxxxxx/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app/Dino')
=> SBTarget(0x0)
4) Inspect the target file from the above log output, in my case -
file
"/Users/xxxxxxx/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app/Dino"
/Users/apanagar/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app/Dino:
Mach-O executable i386
5) So, In my case my problem was the architectures I was building for. The target architecture for your project should match the one on the SBDebugger::CreateTarget() line in the log output.
Xcode doc's point out the following. I had to go through my nested frameworks and change some outdated architecture targets -
NOTE ABOUT 64-BIT ARCHITECTURE
An app extension target must include the arm64 architecture in its
Architectures build settings or it will be rejected by the App Store.
Xcode includes this architecture with its “Standard architectures”
setting when you create a new app extension target.
If your containing app target links to an embedded framework, the app
must also include the arm64 architecture or it will be rejected by the
App Store.
For more information about 64-bit development, see 64-Bit Transition
Guide for Cocoa Touch or 64-Bit Transition Guide for Cocoa, depending
on your target platform.
https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
I am not sure if this will help in your case. But I tried this solution and it worked pretty neatly for me.
Pull up the terminal and type - rm -rf ~/Library/Developer/Xcode/DerivedData
This is supposed to remove the huge stack of DerivedData folder and make the app execute faster.
Did you use Architectures=$(ARCHS_STANDARD_32_BIT) and run your app on a 64 bit device? (iPhone 5S or iPhone 5S simulator)
Apple seems to be stricter with apps which don't support 64bit. So if there is no specific reason, I think it's better to include arm64 in your build architecture
NOTE ABOUT 64-BIT ARCHITECTURE
An app extension target must include the arm64 architecture in its
Architectures build settings or it will be rejected by the App Store.
Xcode includes this architecture with its “Standard architectures”
setting when you create a new app extension target.
If your containing app target links to an embedded framework, the app
must also include the arm64 architecture or it will be rejected by the
App Store.
For more information about 64-bit development, see 64-Bit Transition
Guide for Cocoa Touch or 64-Bit Transition Guide for Cocoa, depending
on your target platform.
Source:
https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
This warning is solved by changing Build Settings :
Select Project -> Build Settings
Change 'Architectures' to 'Standard architectures (armv7, arm64) - $(ARCHS_STANDARD)'
This will prompt an alert stating iOS 5.1.1 and above are supported. Click 'Change Deployment Target to 5.1.1'
Repeat steps for Target (if not changed automatically)
Also, this is preferred build setting since Apple is forcing developers to build apps on 64 but architecture. Apple document Link

Disable 64 bit in Cocos2d v3 - how to do it with debug builds

So here I am using Cocos2d v3, with a game 90% done. It seems that for business reasons I might have to include an external framework which does not support arm64 and there's not much I can do about it, except maybe go back to Cocos2d v2.1 (I'm not doing that). Or is there?
I tried removing arm64 from valid architectures, and am able to build and run even on iPhone 5s. Somehow I don't get it to compile in debug yet - what option could be preventing this?
I get lots of errors like: /Build/Products/Debug-iphoneos/libcocos2d.a, file was built for archive which is not the architecture being linked (armv7):
Update: I found out what was wrong. With an iPhone 5s plugged in and "Build active architecture only", Xcode only wanted to build arm64. This worked as long as I disconnected the iPhone 5s. And I needed to disable Build active architecture for the linked targets of cocos2d and chipmunk respectively, too.
So the changes I did was:
Remove arm64 from valid architectures in my game target
Disable build active architecture for all three targets: my game, cocos2d, chipmunk
Still remains to be seen if there are any other pitfalls doing this.

Possible Xcode Validate Settings Bug

I wrote an app originally for iOS 6, and I have since updated it to work on iOS 7. Now I want to build it to support the 64 bit iPhone 5s as well. In my project I switched the Architectures Build Setting to Standard architectures (including 64-bit) (armv7, armv7s, arm64). Upon build Xcode prompted me to validate my settings, and told me to let it automatically choose the architecture. I let it do this, however it switched it back to the default, Standard architectures (armv7, armv7s).
I looked for an answer on google but found no clear explanation.
I decided to ignore Xcode's warning, and fixed my app to support 64-bit and it built successfully (leaving the setting on Standard architectures (including 64-bit))
However I hated the feeling of going against Xcode's advice, so I created a new project as a test. I found that the default architecture build setting of a new project was Standard architectures (including 64-bit). I then clicked validate settings and found that even in this brand new project with nothing else changed, Xcode still wanted to change the architectures back to regular Standard architectures.
Is there a reason why Xcode is changing the architectures back, or is this a bug in the validate settings?

Running iOS SDK built in arm7 on arm7s

I have an SDK to achieve some special stream of video but I've got only the binary of this, I think this was built for arm7.
I have an app built with this library and it runs great on iPhone 4, 4s and iPad 2 but when building for iPad 4th generation with an arm7s xcode shows lots of errors about files being ignored.
I'm pretty sure it's the architecture cause changing the build architecture the errors appear and disappear.
Is there any way to make this work? I mean build for new architectures having only binaries files of the old one?
Unfortunately not. To build your app for armv7s all the code – which includes said library – has to be built for it. There is a hack to add armv7s support to static libraries but I would strongly recommend against using it.
That being said, for now it's not a big deal if you're building your app for armv7 only. It will still work fine on the iPhone 5.
Just go into the build settings of your Target and set "armv7" as the only architecture your app should be built for.
At one point in the future Apple will probably require that all new apps / app updates will be built for armv7s, like the did with armv7 a few years ago, but for now it's not a problem. By then the developer of the static library will hopefully have provided an update.

Resources