I cannot run my app on simulators anymore. Online suggested that I edit my project.pbxproj, but that does not appear to work. How do I reclaim the ability to run my project on my simulator (and remain able to do so on a device)? I am working on another project that uses many of the same frameworks, but it runs on a simulator. What would cause a similar framework to work in one project but not in another?
Xcode 12.3
In my case I solved this problem by simply setting Validate Workspace to Yes in the Build Settings tab
No doubt that the fix in case of Xcode 12.3 is to setup the Validate Workspace property in the target's build setting. However if you check the diff after this change, the reason of the build error is the missing parameter (VALIDATE_WORKSPACE) from the project file, not the value of the parameter.
So you don't need the value to be YES. You need to add the value to the project settings and you can leave it on the default value (NO). At the first time, it shows up in the Build Settings with NO, but only because that is the default value of the missing parameter.
TLDR;
Without changing your project setup, go to your target's build settings, find "Validate Workspace", set it to YES, then set back to NO.
It happened to me when I added my custom framework into the project and after I updated my Xcode, I encountered the same issue.
Solution : under build settings in project search for Validate workspace Just
change to yes which is by default set to no
Use a .xcframework rather than a "fat" .framework containing an iOS and iOS simulator slice.
This also obviates the need to use a build phase to strip the iOS simulator slice when building for the App Store.
"Fat" frameworks, which are typically created using lipo as they cannot be built directly by Xcode, are not supported (source: Developer Technical Support Apple Developer forum). .xcframework is the only supported mechanism to ship a single framework supporting both iOS and the iOS simulator.
Also .xframework's is the only supported way to ship a binary Swift framework (source: Developer Technical Support on Apple Developer forum).
In Xcode 12.3, the fact that "fat" frameworks are non supported is enforced, as Xcode verifies the frameworks during build, which is why a lot of projects suddenly started to see build errors.
Most answers here are for consumers of universal binaries to work around the new restrictions. But, as in noted elsewhere, it's time to migrate to Apple's XCFramework format for framework authors.
If you were running a custom build script to create universal binary before with an aggregate target and lipo, it's straightforward to migrate to producing .xcframework files
First, in build settings make sure "Build Libraries for Distribution" (BUILD_LIBRARY_FOR_DISTRIBUTION) is set to YES
Then, replace your existing aggregate target build script that used lipo with something like the following which is simple for showing how to make "release" frameworks only:
# Universal Script
set -e
FRAMEWORK_NAME="your_framework_name"
IOS_SCHEME_NAME="your_scheme_name"
if [ -d "${SRCROOT}/build" ]; then
rm -rf "${SRCROOT}/build"
fi
SIMULATOR_ARCHIVE_PATH="${SRCROOT}/build/${FRAMEWORK_NAME}-iphonesimulator.xcarchive"
DEVICE_ARCHIVE_PATH="${SRCROOT}/build/${FRAMEWORK_NAME}-iphoneos.xcarchive"
OUTPUT_DIR="${SRCROOT}/framework_out_universal/"
# Simulator xcarchieve
xcodebuild archive \
-scheme ${IOS_SCHEME_NAME} \
-archivePath ${SIMULATOR_ARCHIVE_PATH} \
-configuration Release \
-sdk iphonesimulator \
SKIP_INSTALL=NO
# Device xcarchieve
xcodebuild archive \
-scheme ${IOS_SCHEME_NAME} \
-archivePath ${DEVICE_ARCHIVE_PATH} \
-sdk iphoneos \
-configuration Release \
SKIP_INSTALL=NO
# Clean up old output directory
rm -rf "${OUTPUT_DIR}"
# Create xcframwork combine of all frameworks
xcodebuild -create-xcframework \
-framework ${SIMULATOR_ARCHIVE_PATH}/Products/Library/Frameworks/${FRAMEWORK_NAME}.framework \
-framework ${DEVICE_ARCHIVE_PATH}/Products/Library/Frameworks/${FRAMEWORK_NAME}.framework \
-output ${OUTPUT_DIR}/${FRAMEWORK_NAME}.xcframework
# Delete the most recent build.
if [ -d "${SRCROOT}/build" ]; then
rm -rf "${SRCROOT}/build"
fi
You can tweak the above to have different output dirs, different deletion behavior, support multiple configurations (Release vs Debug) but this works for me.
Finally, as a one time step, delete the your_framework_name.framework universal binary that caused you the error as mention in this project. Copy the newly built your_framework_name.xcframework and add it to the project and the error should go away.
possible reason would be
framework which you are using may not be built for simulator architecture(x86_64), you can check the compatibility by going to framework folder (framework_name.framework --> modules --->framework_name.swiiftModule-->) in this path you should see arm/i386/x86_64 support files
if you have updated to new Xcode, the frameworks you are using are not compatible to the newer compiler version, so vendor needs to share the recent compatible one, in this case you will not be able to run on both device and simulator
To be honest, the only approach that you guys should follow is to convert .framework to .xcframework, as this is what Apple enforces from XCode version 12.3 and above. Validating workspace and other quick fixes may be temporary and cause problems in the future - like archiving the app for appstore release or testflight.
To convert .framework to .xcframework follow the steps described in the article, starting from paragraph Commands:
https://medium.com/strava-engineering/convert-a-universal-fat-framework-to-an-xcframework-39e33b7bd861
I ran in this error on Xcode v12.3 and Universal(fat) Framework(.framework)
Building for iOS Simulator, but the linked and embedded framework was built for iOS + iOS Simulator.
Solution 1: is Toggle/Toggle Validate Workspace(not default)
Solution 2: use XCFramework[About]
If you are using Carthage, make sure you use the copy-frameworks script rather than using Embed & Sign as embedded content. I was getting this same error because I forgot about that.
I suppose the framework you are linking was built only for arm architecture. You won't be able to run it in a simulator. You will need an author of the framework to build a "universal framework".
If you are new to Xcode and using Xcode just to launch emulator to run appium tool the above steps might be complex. Just use xcode version less than 11 for beginners.
This link helps to download xcode 10.3
Xcode10.3
If you try to download from AppStore we need to have free storage up to 40 GB the above `xip file will won't cause storage errors.
You can Thank me later if this works!!
I am using xcodebuild to generate an archive from a workspace. I use the following command:
xcodebuild -workspace MyProject.xcworkspace -scheme "MyProject"
-destination generic/platform=iOS archive
-archivePath "../PathToArchive/MyProject.xcarchive
(I've spaced it out over multiple lines for readability)
This command generates a MyProject.xcarchive. However it generates a generic "Xcode Archive" rather than an "iOS App Archive." This cannot be submitted to the App Store.
If I archive the exact same workspace and scheme using Xcode.app version 7.0.1 (7A1001) instead of xcodebuild then I get an "iOS App Archive" which can be submitted to the App Store.
Inspecting the contents of these two xcarchives shows the main difference is the bundled Info.plist file. The one generated by Xcode.app contains an additional ApplicationProperties dict with versioning and signing details. The one generated by xcodebuild lacks these details in its Info.plist.
Copying the Xcode.app generated Info.plist into the xcarchive generated by xcodebuild "fixes" the archive, and it can be submitted to the App Store. This is not a solution however, as it means I cannot build on the command line.
Note that doing xcodebuild -version prints:
Xcode 7.0.1
Build version 7A1001
Edit: sometimes xcodebuild appears to generate a correct iOS App Archive instead of a Generic Archive. I'm not exactly sure why this happens. It's not consistent.
Are you using Cocoapods? If so try using the pre release version gem install cocoapods --pre . I had the issue because of a copy pods phase being somewhere it should not have been, please go through https://github.com/CocoaPods/CocoaPods/issues/4021 you should find a solution that fits you.
After a lot of frustration I have discovered the cause of xcodebuild producing incorrect xcarchive packages.
I had to disable the "Parallelize Build" option for the scheme I was building.
After un-ticking this option, the builds take a lot longer, but xcodebuild is consistently producing an "iOS App Archive" rather than a "Generic Archive." With "Parallelize Build" enabled xcodebuild would generate a "Generic Archive" 90% of the time, occasionally generating a correct archive.
Because I wanted my build times within Xcode to remain unaffected, I left the "Parallelize Build" option enabled for my schemes. I duplicated the schemes to be built with xcodebuild and un-ticked the option only for the deployment schemes.
I noticed a different when creating an .ipa file manually using xcrun than exporting it from xcode. The xcrun version doesn't have any symbols included with the .ipa.
I was wondering what's the best way to create an .ipa with symbols (no reason not to send them) manually from the command line, I'm using TeamCity CI to generate our production .ipa files.
I use the following command line to generate the IPA -
/usr/bin/xcrun -sdk iphoneos PackageApplication -v "DerivedData/MyApp/Build/Products/Release-iphoneos/MyApp.app" -o "~/MyApp.ipa" --sign "<HIDDEN>" --embed "<HIDDEN>"
I run it after invoking xcodebuild so the Release-iphoneos folder got the latest release version of my app.
I'll answer myself -
In Xcode 7 Apple added the ability to specify export options plist file to better control the .ipa file creation.
One of the options there is <key>uploadSymbols</key> that does exactly what I need.
http://www.matrixprojects.net/p/xcodebuild-export-options-plist
I want to build my ios-apps Appstore-ready directly from the command line with the mdtool from MonoTouch (Xamarin) so that Jenkins can kick in and produce the uploadable package right away.
I use the following command:
'/Applications/Xamarin Studio.app/Contents/MacOS/mdtool' -v build '--configuration:AppStore|iPhone' MyAppProject.csproj
Now, the build runs, uses my AppStore Provisioning Profile and creates the files in my bin/iPhone/AppStore - folder.
Now, according to the documentation of Xamarin, I should zip the created app-file in the bin/iPhone/AppStore and select it in xCode Application Loader like shown in the screenshot:
But the Application Loader shows every file grayed out, so there is no chance to continue.
What if you rename the .zip extension to .ipa?
I think you should not choose "Open package" but "Deliver Your App".
You can also use the xcrun ("XCode Run") command line tool to with the "PackageApplication" argument to package an ".app" into an ".ipa" and optionally specify a signing identity and provisioning profile at the same time.
Something like:
/usr/bin/xcrun -sdk iphoneos PackageApplication -v "Ios.app" -o "Ios.ipa" --sign "[DEVELOPER_NAME]" --embed "[PROVISONING_PROFILE]”
More info on xcrun here:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/xcrun.1.html
So im trying to automate the build and archive process through a script. In my script, I run the xcodebuild script and that builds fine. Then I try to run the xcrun
/usr/bin/xcrun -sdk iphoneos PackageApplication "path_to_.app" -o "output_path" --sign "devname" --embed "provnprofile"
However I get this error:
error: Failed to read entitlements from '/var/folders/U5/U5q0xqZRG6SrO8AMQkMjeE+++TM/-Tmp-/fIcrdMUa76/Payload/MyApp.app'
Anyone have any ideas why?
Thanks in advance
I just encountered the same issue. It was actually related to my .app folder generated with xcodebuild which wasn't successfully built.
Try to use xcodebuild with the verbose (-verbose) enabled and check the stack trace.
I hope it will help.
double check the package you are building in Xcode. Very often, a project has multiple packages and targets to build. You might have selected a distribution package or not the one you intent to build.