Xcode archive not creating DSYM file - ios

For most of my projects, I setup an "archive" scheme to archive my project, creating an IPA and DSYM that I can upload to TestFlight.
However, I'm working on a more complicated project that has several targets within the project workspace, quite a few static linked libraries. I have gone through each target and set the following for all configurations:
Deployment Postprocessing -> NO
Strip Linked Product... -> No
Strip Debug... -> No
Generate Debug Symbols -> Yes
Debug Information... -> DWARF with DSYM
I am using Xcode 4.5.2. I have done this for multitudes of projects with no issues. This is the first where something seems to be preventing the DSYM file from being created.
No matter what I try, my archive build will not generate a .DSYM file

Identifying the problem
As #belsokar suggested, check the Report Navigator.
In my case, the dSYM file has not been generated, and there hasn't been a corresponding line that goes like "Generate Appname.dSYM ...in {path}"
But there's been Fabric installed, and it logged the fact of the dSYM file's absence:
Just filer the Report Navigator by "dSYM".
Fixing
In my case I've just had to do what I'm asked of:
DEBUG_INFORMATION_FORMAT should be set to dwarf-with-dsym for ALL
configurations.
Also, it may turn out that dSYM file is being generated in an unexpected place. Check environment variables, especially DWARF_DSYM_FOLDER_PATH and DWARF_DSYM_FILE_NAME.
To embed the dSYM within the app bundle, just set DWARF_DSYM_FOLDER_PATH to $(CONFIGURATION_BUILD_DIR)/$(EXECUTABLE_FOLDER_PATH) and DWARF_DSYM_FILE_NAME to $(EXECUTABLE_NAME).dSYM
Checking
Now the build should create dSYM for your target

xcode - > product -> Archive
you see Archives window
1 Select any Archives of your app Right click on it Then select show in finder
2 you see aapname.xcarchive file Right click on it and select show package contents
3 you see dSYMs folder open it and get .dSYM file
:)

Try using: Deployment Postprocessing -> YES
check this out: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html

A few tips for researching.
Check the Log Navigator. I went into this view (one I rarely use so I tend to forget it exists), and I realized the .DSym file was in fact being created.
Check build directory configs to see if they are default or custom...in my case, they were custom, so they weren't being put in the typical default location.

As mentioned in the main answer, the value of DWARF_DSYM_FOLDER_PATH determines where the dSYMs will go. The default value is $(CONFIGURATION_BUILD_DIR), so if you have a custom CONFIGURATION_BUILD_DIR setting, it can change DWARF_DSYM_FOLDER_PATH such that the dSYMs do not get copied into the .xcarchive. I have also found that a custom SYMROOT setting can also change the path, and possibly some other setting overrides as well.
Normally during an archive build, the CONFIGURATION_BUILD_DIR and DWARF_DSYM_FOLDER_PATH values will be somewhere under an "ArchiveIntermediates" folder, the contents of which presumably get copied to the eventual .xcarchive.
If you can avoid overriding those settings, that would likely be preferable, otherwise DWARF_DSYM_FOLDER_PATH may also have to be overridden to point to the correct location, or a post-build step would be needed to copy the .dSYM folders from wherever they ended up to the XXX.xcarchive/dSYMS folder.

DWARF_DSYM_FILE_SHOULD_ACCOMPANY_PRODUCT=YES copied the .dsym files to the archive in my project.
Also, I did not change the default DWARF_DSYM_FOLDER_PATH or DWARF_DSYM_FILE_NAME values.

This is work around helped me:
Log into iTunes Connect and go to My
Apps.
Click on the app that you're trying to download the dSYM for
Go to 'Activity' tab.
Click on the version you want to expand it and
show all the uploaded builds.
Click the build you want.
You'll be shown details about that build, and the option to download dSYM in the bottom right corner under 'Includes Symbols' header.

Related

Entitlements file was modified during the build, which is not supported

I'm getting following error during release build:
error: Entitlements file "projectname.entitlements" was modified during the build, which is not supported. You can disable this error by setting 'CODE_SIGN_ALLOW_ENTITLEMENTS_MODIFICATION' to 'YES', however this may cause the built product's code signature or provisioning profile to contain incorrect entitlements.
I can't find CODE_SIGN_ALLOW_ENTITLEMENTS_MODIFICATION on Google or Apple documentation, any ideas where should I use it?
I fixed this with Product > Clean Build Folder.
Ran into the same issue. You can set CODE_SIGN_ALLOW_ENTITLEMENTS_MODIFICATION as a User-Defined setting in Build Setting.
In Xcode click on your project target and click Build Settings.
Click the "+" underneath Build Settings and then "Add User-Defined Setting"
Set CODE_SIGN_ALLOW_ENTITLEMENTS_MODIFICATION to YES for debug and release (or whatever schemes you like)
Before you start modifying the build settings you can also try deleting the Derived data in your install or build directory.
If the project cache is found in the standard location below you can do an Xcode clean and it will get rid of this data.
/Users/your_user_name/Library/Developer/Xcode/DerivedData/Path_To_Project/
If you defined your own install or build paths then go to that specific directory and delete that cache. Xcode should provide you the path if that error happens.
If Clean Build Folder doesn't help, make sure you don't have the same workspace/project opened in multiple Windows or Window Tabs!
(Xcode allows to open multiple tabs via File -> New -> Window Tab)
I've actually run into this EXACT same Compile-time error when I did the following in GitHub Client:
**Discarded changes in my Git Repo for an entitlement file.**
It's imperative like suggested above, "Clean Build Folder" or add USER defined key CODE_SIGN_ALLOW_ENTITLEMENTS_MODIFICATION to YES.
I know it's been answered above but I wanted to document the reproduction steps that led to the aforementioned error.
Like others have posted, this is resolved by cleaning the build folder or setting CODE_SIGN_ALLOW_ENTITLEMENTS_MODIFICATION to YES.
However, after cleaning the build folder, one build will succeed but any subsequent ones will fail with the same entitlements error until you clean the build folder again. Obviously this isn't optimal since it adds ~2-3 minutes per build even for one line changes.
The second solution involving CODE_SIGN_ALLOW_ENTITLEMENTS_MODIFICATION does away with the entitlements error entirely but install on physical devices fails every other build until build folder is cleaned. Same outcome really.
Does anyone actually know why this is happening in the first place? I inspected my entitlements file before and after build.. Nothing is changing. Is this just an xcode bug that costs us all hours of our lives?

Choose where to place .app file for xcode build

Is there anyway to choose where to place the XCode build (.app and dSYM files).
I want to place the .app and the dSYM file in a folder together with the XCode project.
Is there any way to do this other than manually moving the files?
May be you can check this link
it may be useful
Also
Xcode 4 - build output directory
In Xcode, try Preferences->Locations->Derived Data
Click on the Derived Data pull down and pick Custom

$(AppIdentifierPrefix) is not resolved during build time

$(AppIdentifierPrefix) in .entitlements file is not getting replaced with the actual AppIdentifierPrefix. Can someone please shine some light onto this issue?
So here is my understanding of the YourApp.entitlements file that gets added to your project when you add capabilities like iCloud or Game Centre to your application.
(I'd love to see some pointers to official documentation ... if any exists.)
What are these entitlements files used for?
So first of all, the .entitlements is only in your project for the build process. It should not end up in the final .app product. If it does, select the .entitlements file and in the File Inspector, clear it's Target Membership. (This is how Xcode generated these files actually, without any target membership)
So what is the .entitlements file used for then? It is part of the build process where it is taken and processed and put in your final application bundle in two forms:
First: the contents of the .entitlements file is embedded in the embedded.mobileprovision file. This is a signed property list with a binary signature on top but if you open it up in a text editor you can see there is a <key>Entitlements</key> section that should have the processed entitlements in there.
Second: there is also a copy of the .entitlements file called archived-expanded-entitlements.xcent. This is essentially the same file as the original .entitlements file except that it has been processed.
What preprocessor values can be used in the .entitlements file
I don't think the processing of the .entitlements file is documented anywhere. There most certainly is a pre-processor running over it, so that things like $(AppIdentifierPrefix) are replaced with the actual value. However, this seems to be not the same as the one that is used for the Info.plist file.
The $(AppIdentifierPrefix) is the same as the Team Identifier that you may have configured in your Xcode project. You can find the configured Team under your target's General settings in the Identity section. If team is set to None then there is a good change that $(AppIdentifierPrefix) won't be set.
So to finally answer your question: if you look at those two files that I mentioned above, and you still see the $(AppIdentifierPrefix) is not correctly substituted, make sure your project has a Team Identifier configured.
How does Xcode know what entitlements file to use for your target?
In your build settings you can look at the Code Signing Entitlements settings to find out what file Xcode uses for each build configuration. Usually Debug and Release use the same entitlements file but you can change that.
(For example, for Firefox for iOS we have build configurations for Nightly, Aurora, Beta and Release builds. These all have different entitlements files. The reason we have different entitlements files is because we could not make the .entitlements pre-processor recognize settings like $(PRODUCT_NAME:rfc1034identifier) - i'd love to hear if there is a way to do that because that will make our build simpler.)
What tool processes the .entitlements files?
Not entirely sure. But if you look in the build logs, you will see some reference to a builtin-productPackagingUtility tool. This seems to be an internal Xcode command, not something actually present as a command line tool. So that is not very useful.
Now you know pretty much everything that I know about .entitlements files :-)
(I'd love comments and turn this answer into the definitive guide to entitlements files - i think there is a lot of confusion around them)

Xcode archive validate button greyed out [duplicate]

I have a problem generating a iOS App archive from an application. The application compiles just fine and even works in the simulator. Now I wanted to make som ad hoc testing and cannot generate the iOS App Archive. When I click on the Product -> Archive it generates a generic xcode archive. Can anyone help me. I should mention, that I have already generated an iOS App Archive of this application. It has just stopped to generate iOS Archive for some reason. Thanks a lot.
Check Build Settings:
Skip install is NO for the main project target
Skip install is YES for framework (sub-projects) targets
In Build Phases for sub-projects, Copy Headers needs to be in Project, not Public (does not apply if building static library)
Installation Directory under Deployment is valid (/Applications for example)
This can happen if you've added a framework/library ... you need to edit the Target->Build Settings of that library and set the 'Skip Install' setting to 'Yes'. When you re-archive, XCode should start producing a 'iOS App Archive' again rather than a 'generic xcode archive'.
In addition of Skip Install to Yes and in case you opened another lib/framwork project within your app project you have to move headers (if any) from public to project in the Build Phase / Copy Headers.
I did the following to make it work for me:
I had a three20 static library, I used cocoapods to include the files within the main project
followed the skip install for all other sub projects/static libraries and switched the copy headers from public to project as stated above
most importantly: in each library your project uses go to build phases -> Copy Files and ensured that destination is changed from Absolute path to products directory. Note: see the hint below to narrow your search to find the library causing this error.
and that was it!
hint: to get an idea of the offending files that's causing your archive to create an archive file rather than an ipa do this:
Select the archive and click the Distribute button.
Select the 'Save Built Products' option.
Hit Next and Save.
Browse the created directory in Finder.
The 'libraries' subdirectory will identify the libraries that you need to set the Skip Install to Yes.
in some cases usr/local/include will identify the culprit header files you need to move from Public to Project or the files that you have to change from absolute path to products directory (or even the files you forgot to set the skip install to yes flag). but that directory (ie usr/local/include) varies depending on your sublibrary directory structure. In many cases.. you will see all the files listed under Copy Files in step 3 above listed here. If you find them here, then you have a definite answer for the cause of your problem.
update to hint: to make life even more simpler.. whatever files appears under step 4 in hint above.. simply search for it in the global search of xcode.. and you should get immediate results for what you want.. for example, this was the content of my folder (following the steps in hint above):
So I could tell it has something to do with the crypto and ssl libraries.. searching for them:
made me realize that i forgot to set skip install to yes.
If you export the archive, open it and see /urs/local/include in Products try this suggestion:
In each pod, under Packaging, Private Headers Folder Path and Public Headers Folder Path is set to /usr/local/include. If I clear them then I get a valid archive.
Worked for me after upgrading my React Native app to 0.11.0, Xcode 7 and CocoaPods 0.39.0.beta.4.
If you're using CocoaPods as well as WatchKit or a Today Extension, there is an open issue on the CocoaPods repo explaining what your problem might be.
The solution for me was to remove the Copy Pod Resources phase from the WatchKit Extension and Today Extension targets under Build Phases. The project compiled and archived as expected once I did this.
Hope this helps someone, this had me stumped for an entire day!
If any of the above answers don't work, your issue is probably with cocoaPods. The latest update 0.38.1 messed things up for me, but then i downgraded to 0.37.1 and things returned to normal. Using Xcode 6.3.1
Later edit: updating to 0.38.2 will also fix this. More info about what caused this issue here: Cocoapods 0.38.1 failed to create valid Archive
Although I'm using Xcode5 and what sorted it for me was editing the Build Scheme - trying all of the above suggestions that were applicable didn't help in my case.
I had two targets, say, "App" and "App FREE". My problems with the generic archive happened when I was trying to Archive the FREE version, which I added after the 'normal' version of the app. In my case, when I selected its Scheme in the toolbar and chose Edit Scheme ... I saw that Build section had two targets, namely App and App FREE.
I unchecked all columns for App, leaving only App FREE's columns checked, and clicked OK. Next time I chose Product > Archive I got my App FREE instead of a Generic Archive. :)
If you have only single project, maybe this solution would be useful.
This problem had occurred, when I duplicated the target. As a result I had two targets parallel built. This was causing the issue. Generic IOS archive was built.
To turn the parallel built off go to
Manage schemes,
Edit scheme,
Build,
Remove the other target.
I had this problem after updating to iOS 9 and Xcode 7. Josh H's solution worked for me:
In each pod, under Packaging, Private Headers Folder Path and Public
Headers Folder Path is set to /usr/local/include. If I clear them then
I get a valid archive.
I also made a post install script for my Podfile to do this automatically!
post_install do |installer_representation|
installer_representation.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['PUBLIC_HEADERS_FOLDER_PATH'] = [""];
config.build_settings['PRIVATE_HEADERS_FOLDER_PATH'] = [""];
end
end
end
Just add it to the bottom of your Podfile and run pod install
I had this issue. In my case, it was caused by keeping a Mac app target as a dependency of the iOS app.
The reason it was setup like this was that the Mac app was a tool used to generate some data for the iOS app, which was then included in the bundle.
I had to remove that dependency and build the tool separately before making a build of the iOS app itself.
In my scenario I was getting the erroneous "Generic Archive" only after I began including Swift code in my predominantly Objective-C project. After lots of troubleshooting and examination of the archive file that Xcode was spitting out, I noticed that the SwiftSupport folder (with the required dylibs for the Swift runtime) was in a different place in my archive than from a vanilla brand-new Swift project app archive.
I found the Installation Directory build setting and noticed it was set to a custom path in my project. I simply deleted it (setting it to its generic value of /Applications) and the next Build -> Archive I did worked as expected and gave me a proper iOS App Archive.
TL; DR: Make sure your Installation Directory build setting is set to its default value of /Applications when including Swift code in your app, especially if you are starting with an older project file that may have some unexpected legacy build settings.
I have multiple project in my workspace, (GTL, Pods and my main project) and this is what worked for me:
Select the Project, there will be 2 types there, there's the Project and there's the Targets.
For projects that is not your main like GTL or PODS:
Projects:
Skip Install = NO
Installation Directory = /Applications
// For pods
Private Headers Folder Path = ""
Public Headers Folder Path = ""
Targets:
Skip Install = YES
Installation Directory = /Applications
// For pods
Private Headers Folder Path = ""
Public Headers Folder Path = ""
For the main project (which is usually named the same as your product name):
Projects:
Skip Install = NO
Installation Directory = /Applications
Targets:
Skip Install = NO
Installation Directory = /Applications
Check the ios deployment target on each projects and targets to make sure they are all the same.
Leaving this here to save others from the same journey.
I found I needed to remove the same Copy Pod Resources build phase from a static library target in my workspace too.
Addition to Alex L 's answer.
Point 3. Change 'Build Settings' -> 'Public Header Folder Path' to 'include/xxx' also works.
If none of the above helped you...after a lot of time.......
I deleted the value in the Info.plist for Bundle Version because I was happy enough with just Bundle Version Short 1.0. Bad. Don't do this.
*Note I actually did this by editing it in the UI on the right not realizing it would put an empty key in the Info.plist file. I think that makes it invalid. My bundle showed up as other items while archiving and had no icon, and I couldn't upload to anywhere.
This boils down to invalid values in the Info.plist. If it's not a valid archive, try unzipping an old archive and dropping in / overwriting your current one and see if it fixes it when rebuilding the archive.
Go to Build Settings and add
yourAppName/Resources/dist.plist to the Code Signing Entitlements
Press cmd + B with iOS Device or a Real Device selected as Build Target
When done -> scroll to "Products" folder and right-click on yourAppName.app
Choose "Show in Finder"
Create a folder with Name Payload (capital "P")
Copy yourAppName into your Payload Folder
Create a zip from your Payload Folder
Rename the zip to yourAppName.ipa
DONE
After trying just about everything:
Clean, Archive
delete DerivedData, Archive
restart Xcode (I was using XCode7), Archive
combinations of above...
I then noticed my boot partition was 'low on free disk space'... about 1GB or so.
I rebooted, then got about 18GB free.
Then opened Xcode and project, performed Archive... and surprisingly (after an hour of trying to build an Archive) I finally got a non Generic Archive.
No idea if its a free disk issue which fixed it or a reboot of the macOS that fixed it, but it worked for me.
If you have any .xcodeproj files in Project>Targets>Build Phases>target dependencies remove it from there and then build your ipa. It works for me. Cheers
You can get answer here : xcode is creating generic xcode archive instead of iOS App Archive
In my case, i had to move both FMDB and BlocksKit to static libraries. Previously they were built as subprojects. Remember you can use lipo to create universal libraries. When building the final products, the simulator code will be stripped automagically.
Another possible reason for this is to have references in "Target Dependencies" to projects for a different platform. In my particular case, I was working on a project that shares code for OSX and iOS. In one of the iOS targets, I had accidentally added an OSX target as dependency.
In order to be thorough, I am posting my solution.
I experienced the exact same problem trying to build an Archive of an iOS project in Xcode 5.1.1 (5B1008). None of the above suggestions fixed the problem, and most of them were irrelevant (I had not added any Frameworks, and did not have any Public entries in the Copy Headers section of my Build Phases).
In my case, fixing the problem consisted of simply closing my project, deleting any archives that I had previously made, going to Preferences > Accounts, removing my developer account, quitting Xcode, relaunching, re-adding my developer account, starting the Archive process again. This fixed my problem immediately.
One more solution, since all the above didn't work for me...
Changed the User Header Search Paths (I suppose Header Search Paths would work just as elegantly) to "$(BUILT_PRODUCTS_DIR)/BlocksKit".
Background:
In BlockKit, the developers have structured the headers in the main project differently than the structure on deployment. So, you can't reference the headers in the project, and must reference the headers copied into the build directory.
The way this worked for me in (Xcode 5) I had 2 targets and when I edited the scheme, on the left pane of the scheme editor, you will see the [BUILD, RUN, TEST, PROFILE XXX.APP, ANALYZE, ARCHIVE] from the BUILD pane, you will see your project targets listed in a list. At the far right end you will see the ARCHIVE selections, make sure only one target is selected for archiving.
I had 2 of my targets selected in my project, I checked only the target I wanted in the product, and it worked!
I solved this error by opening solely the app project in XCode, ie. not opening a workspace comprising the application and other projects/libraries/frameworks.
Having 2 separate project, a framework or shared library and an iOS application, I had to open 2 different XCode windows, each by directly opening the .xcodeproj file instead of the common .xcworkspace, in order to preperly build each.
As a nice side effect, XCode no longer rebuilds every target of every project after I do a Clean, resulting in shorted build times.
Background: I am creating an open source SDK, and a demo iOS application. I had both opened in a single workspace.
Setting Skip install to YES on the SDK targets would prevent anyone from creating an archive, as it would be empty, so this was not an option. Using Project instead of Public headers would lead to an archive missing the header files that should be distributed, so this was not an option either.
For it was because i was working in a workspace.
The project did archived but would ne be displayed in the organizer window.
I closed the workspace and open the project on its own.
The archived has been opened in the organizer ... hope it's help.
In my case, I had a custom script that was copying some temporary files into:
${TARGET_BUILD_DIR}/myTempDir
That meant that, after investigating the archive to inspect its contents, I found right next to the .app file a myTempDir folder. Once I modified the script to save elsewhere things were sorted.
Try setting $(PROJECT_NAME)Headers in Framework projet's Public Headers Folder Path. You have to go to build settings of the Library Target then edit the Public Headers Folder path as $(PROJECT_NAME)Headers.
If using Xcode 7 with cocoapods v.0.38.2. Try removing copy pod resources from your today extension target.
I encountered this problem after adding a OS X command line tool to my iOS app's project, and Skip Install was set to NO by default for the command line tool's target. Since you obviously can't install an OS X binary to an iOS device, archiving defaulted to a generic Xcode archive. Setting Skip Install to YES for this target fixed the problem.

Xcode has started making archives, not apps. How do I change it back?

Im' writing an phone app in Xcode 4.2. At some point in the last few days, I changed something - I don't know what, and there's nothing obvious in the git history - and although I can still run it on my device and in the simulator, when I archive the build it makes an archive instead of an app. I can't share these archives as IPA files; if I try I get told "No packager exists for this type of archive".
What did I do? How do I change it back so I can produce IPAs again?
I did the following to make it work for me:
for the three20 static library, I used cocoapods to include the files within the main project.. it just got rid of all the trouble three20 was giving me (and they are lots..) btw i tried replacing three20 with Nimbus.. but Nimbus was lacking on some of the features that my project was using three20 for.. so Nimbus wasn't helpful.
set skip install to yes under build settings for all other sub projects/static libraries and switched the copy headers from public to project under build phases
most importantly: under the sub libraries.. under build phases i ensured that copy files destination was changed from Absolute path to products directory.
and that was it!
hint: to get an idea of the offending files that's causing your archive to create an archive file rather than an ipa do this:
Select the archive and click the Distribute button.
Select the 'Save Built Products' option.
Hit Next and Save.
Browse the created directory in Finder.
The 'libraries' subdirectory will identify the libraries that you need to set the Skip Install to Yes.
in some cases usr/local/include will identify the culprit header files you need to move from Public to Project or the files that you have to change from absolute path to products directory. but that directory (ie usr/local/include) varies depending on your sublibrary directory structure
Make sure for any intermediate targets you select "Skip Install" for its build settings.
Click ont the build dropdown in the top-right of your Xcode window and select "edit scheme" and see if anything is wrong there.
If you can't see anything, try selecting "manage schemes" then delete your old schemes and press "autocreate schemes now" to make a new one.
You only want one scheme, for your app build (or one for each target if there are multiple targets). If there are other schemes (e.g. for embedded sub projects used to create static libraries used by your project) delete them.
Also, as jrtc27 says, if you have got any sub-projects that produce static libs, you need to mark them as "skip install" in the build settings. There's another question here that relates specifically to that issue and has a more detailed explanation of how to fix it:

Resources