Cannot generate iOS App archive in xcode

Question

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.

Even though the question is about generating archive from xcode, I faced this issue using `xcodebuild`. The solution is to specify destination: `xcodebuild -destination generic/platform=iOS ` — db42, Jan 07 '15 at 09:26
can you elaborate on the resolution-where do you make the change? — jlo-gmail, Feb 04 '16 at 20:38
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 — Kalpesh Panchasara, Nov 28 '16 at 14:35

Alex L · Accepted Answer · 2014-10-09T02:06:24.737

324

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)

edited Oct 09 '14 at 02:06

answered Nov 29 '12 at 07:15

Alex L

8,419
6
43
51

2

This is the most complete answer which incorporates the above partial answers. Thanks Alex L! I think this should be the chosen answer for this question. – Brandon Feb 20 '13 at 20:42
4

As a meta question, how did you figure this out? Seems like I rely on Stackoverflow for all my build-related questions. – philipkd Apr 16 '13 at 19:45
@Philosophistry Same here. I encountered this error several times. Usually it's the Skip Install issue. The last time it was #4 and I spent several hours reading Stackoverflow before figuring out the issue. – Alex L Apr 16 '13 at 20:03
1

NB: #3 is only an issue if you included sub-projects by drag/dropping them into Xcode. If you build them as a static lib, and just drag/drop the output lib + headers, everything works perfectly - you can leave your headers as "public" etc and all is fine. This is a pretty big advert for NOT using Apple's drag/drop project embedding :( – Adam Apr 30 '13 at 13:56
4

Beautiful! I thought this was a problem with provisioning profiles, but this worked great. Sub project was mapbox branch of route-me/MapView. the Copy Headers was key as the post below states, it can be found in the Build Phases of the sub project. – rcarver May 23 '13 at 02:57
1

this is definitely the correct answer, however if you've tried all the steps listed above and things still aren't working out.. check out the hint in my answer [below](http://stackoverflow.com/a/15120144/766570) – abbood Oct 04 '13 at 11:42
7

#3 fixed my problem but I also needed to move files from Private to Project before my archive was built as an iOS App Archive. – Thomas Hajcak Dec 25 '13 at 17:20
5

Technically, the problem isn't that the headers are Public under Copy Headers, it's that Build Settings > Public Headers Folder Path is set to the default of `/usr/local/include`. If you're building a static library the headers _must_ be Public, so it's more correct if #3 is to change Public Headers Folder Path to something more sensible like `include/$(TARGET_NAME)`. @CopperCash notes this in an answer below. – bcattle Apr 18 '14 at 06:14
Another item I found necessary, in order to produce an .ipa, was to Edit Scheme and under "Build" uncheck the box for "find implicit dependencies." – Fluffhead Sep 10 '14 at 19:53
Does the Installation directory step only apply for the main target? – Hyperbole Nov 05 '14 at 15:55
This saved me after several days of hair-pulling - many thanks. In particular, steps 2 and 3 - for some reason several of the header files of my sub-project were Public. (I haven't tried yet CopperCash and cbattle's recommendation to change the Public Headers Folder Path.) – RonH Mar 30 '16 at 12:12
1

This is the definitive solution. The trick was that for embedded frameworks I had some of them (just one can create the problem) had `YES` the `Skip Install`. – loretoparisi Jun 06 '16 at 14:12
Setting 'Skip Install = YES' on my watch app & extension did the trick. I see a lot of these posts tied to cocoapods 0.38/39. I'm on 1.0.0 and this solution worked for me. – VaporwareWolf Jul 16 '16 at 19:45
Thanks a lot! Saved my time =) Another developer added new sub-project and pushed to repository. – fir Nov 24 '16 at 16:15
I followed all the steps here and it worked for me. Some of the dependent projects In my Mac project also had, in addition to Skip Install set to 'NO', also had an 'Headers' build phase. https://developer.apple.com/library/content/technotes/tn2215/_index.html#//apple_ref/doc/uid/DTS40011221-CH1-PROJ – joshbodily Dec 06 '16 at 21:56
#2. Skip install is YES for framework (sub-projects) targets was the most important one. – Ratul Sharker Jan 03 '17 at 09:59
If none of these work, try a good ol' delete derived data and restart Xcode, that's the only thing that did it for me. – StaRbUck42 Oct 07 '17 at 00:34

score 76 · Answer 2 · answered May 23 '12 at 20:41

76

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'.

answered May 23 '12 at 20:41

delany

3,371
4
23
17

but "Skip Install" is not available in xcode 4.4.1, at least i am unable to find skip intall in my xcode – Mashhadi Sep 21 '12 at 12:57
2

The same applies to added bundles. – Mark Horgan Jan 16 '13 at 16:10

score 64 · Answer 3 · answered May 29 '12 at 02:31

64

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.

build phase of your lib/framwork target

answered May 29 '12 at 02:31

ebtokyo

2,369
4
23
33

3

I was just about to lose hope, as Skip Install to Yes did not work for me. Copying headers to Project did the trick for me. Thanks! – ksm Sep 07 '12 at 23:25
10

To help you localize the faulty Xcode subproject, you can show the Generic Xcode Archive in the Finder and explore the package. Inside the .xcarchive, you will see the faulty headers in Products/usr/local/include. – MonsieurDart Jan 03 '13 at 21:27
1

Why would putting a few files to copy headers to public screw this up? – mskw Mar 20 '13 at 16:43
mskw, I guess if the artifact built contains one or more public header it cannot became an "device deployable" archive (iOS App Archive from where you generate an IPA). It remain a Xcode project archive. Thanks – ebtokyo Apr 22 '13 at 21:40
For me, this wasn't enough. I *also* had to drag'n'drop all the Private headers into *Project* aswell. Only then did XCode create an app which was a Single Bundle app, and I could distribute it. – Mike Gledhill May 17 '13 at 11:59
1

damn, thanks, ths worked for me.. I wonder how the hell you manage to find these kind of solutions :) – Fabio Napodano Nov 12 '13 at 16:13
Yup, this worked for me aswell. I'd had to upgrade my MapBox iOS SDK to the latest 64-bit version (so I could deploy to the App Store) and strangely, it comes with most of the headers in Public by default. Sigh... – Mike Gledhill Jul 16 '15 at 14:45
This saved my night. ;-) – vivek bhoraniya Aug 05 '15 at 14:34
Thank you so much, I spent lot of time with this issue and your answer help me to solve it. – Amit Bhavsar Aug 05 '15 at 14:35
If you can't figure which header is causing the problem. You can export the saved products after archiving it. Open the saved folder and then open the products folder within it. In there you will see a "usr" folder, follow that folder path and it will point which header files are still marked as public. – Michael Wildermuth Oct 14 '15 at 17:28

abbood · Answer 4 · 2013-07-30T09:39:21.223

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):

enter image description here

So I could tell it has something to do with the crypto and ssl libraries.. searching for them:

enter image description here

made me realize that i forgot to set skip install to yes.

Great hint! I had changed some framework headers to 'Private'; for some reason, this was causing them to be copied out to `./usr/local/include`. — Ben Mosher, Jul 01 '13 at 13:56
Definitely the answer I was looking for -- saving build products pointed me to the exact cause of the problem. — Dennis L, Aug 07 '15 at 16:42
This extensive answer with "Save Built Products" is _so helpful_ - @abbood, huge thanks to you. Hope I can return the favour some day. — Scott Corscadden, Nov 02 '16 at 15:55

vhs · Answer 5 · 2015-09-21T12:49:23.650

21

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.

edited Sep 21 '15 at 12:49

answered Sep 19 '15 at 00:34

vhs

9,316
3
66
70

1

I can confirm that this works! As long as you remember to clear out both private and public header paths. It's also fairly easy, if you just select all pods, search for the header path, then clear them all out at the same time. – Dids Sep 20 '15 at 11:23
1

I can also confirm that this works, saved me lots of time, this happened when I upgraded my pods to the 0.39.0.beta version – Bryan P Sep 21 '15 at 06:00
Awesome. Worked for me :) I was struggling from 1 and half days. Thank you, Thank you, Thank you :) :) :) – Srikanth Sep 21 '15 at 18:49
I think this is the one that worked for me Xcode 7.0 iOS9. I don't have any cocoapods, but this fixed the problem none-the-less. Thanks man – Geoff H Sep 26 '15 at 08:40
In addition to this, I had to set SKIP_INSTALL to Yes on my WatchKit extension and app for this to work. – Snowman Oct 09 '15 at 22:20

score 12 · Answer 6 · answered Sep 16 '15 at 15:03

12

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!

answered Sep 16 '15 at 15:03

rebello95

8,486
5
44
65

1

@Lewis42 could always add a bounty ;) – rebello95 Sep 20 '15 at 22:17
Don't see an option to, an up vote on your comment will have to do ;) – lewis Sep 21 '15 at 03:20
@Lewis42 you'd have to add the bounty to the question and award it to an answer lol – rebello95 Sep 21 '15 at 06:49
@rebello95, you rock dude! – Matt Sep 25 '15 at 08:56

score 10 · Answer 7 · edited Jul 29 '16 at 12:04

10

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

edited Jul 29 '16 at 12:04

soumya

3,801
9
35
69

answered Jul 27 '15 at 05:07

Ehmad Zubair

215
3
10

3

I updated to `0.38.2` and still have issues. Are you on Xcode 7? – Porter Hoskins Aug 12 '15 at 20:02
@PorterHoskins I just wrote up this issue as [Xcode 7 will NOT build a valid Archive from the same project that builds a valid archive in Xcode 6](http://stackoverflow.com/questions/32002764/xcode-7-will-not-build-a-valid-archive-from-the-same-project-that-builds-a-valid). I am using Cocoa Pods 0.38.2, when using Xcode 6 all is well, but with Xcode 7 the archive is not created correctly. Have you checked your folder structure to see if you have a .appex file outside of your .app in the package? – Polar Bear Aug 14 '15 at 05:29
I have a framework at `/Library/Frameworks`. I think it may have something to do with Google's cocoa pods not being built as a dynamic framework. It sounds similar to https://github.com/CocoaPods/CocoaPods/issues/3889 – Porter Hoskins Aug 14 '15 at 16:16
3

I moved for every pod headers in Build Phases/Headers to the project section from public and it worked. So indeed the problem might be in CocoaPods. – Denis Kutlubaev Sep 03 '15 at 19:18

score 8 · Answer 8 · answered Dec 17 '13 at 12:20

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. :)

score 7 · Answer 9 · answered Nov 19 '15 at 15:37

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.

score 5 · Answer 10 · answered Oct 01 '15 at 14:57

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

score 4 · Answer 11 · answered May 30 '13 at 00:02

4

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.

answered May 30 '13 at 00:02

Tomas Andrle

13,132
15
75
92

Libraries such as lippd come with both ios and osx targets, I forgot to remove the osx target... doh – James Alvarez May 07 '15 at 16:44

score 4 · Answer 12 · answered Jun 18 '15 at 17:12

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.

score 4 · Answer 13 · answered Oct 29 '15 at 07:18

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.

Thanx for explaining it step by step. that really helped me solve my problem. — Arslan, Nov 07 '15 at 20:56

score 3 · Answer 14 · answered Sep 25 '15 at 11:35

3

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.

answered Sep 25 '15 at 11:35

Michael

1,213
6
9

after trying a lot of the stuff above, this worked for me (Xcode 7) – humphriesj Nov 19 '15 at 00:06

score 2 · Answer 15 · answered Jan 29 '14 at 13:33

2

Addition to Alex L 's answer.

Point 3. Change 'Build Settings' -> 'Public Header Folder Path' to 'include/xxx' also works.

answered Jan 29 '14 at 13:33

CopperCash

563
5
15

This is more correct than the #3 above. Your headers need to be public if you're building a static library – bcattle Apr 18 '14 at 06:17

score 2 · Answer 16 · answered Sep 12 '15 at 22:27

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.

score 1 · Answer 17 · answered Jun 12 '14 at 12:13

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

score 1 · Answer 18 · answered Oct 28 '16 at 15:27

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.

score 1 · Answer 19 · edited May 23 '17 at 12:26

1

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

edited May 23 '17 at 12:26

Community

1
1

answered Nov 28 '16 at 14:34

Kalpesh Panchasara

1,730
2
15
27

score 0 · Answer 20 · answered Jan 21 '13 at 09:47

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.

score 0 · Answer 21 · answered Mar 01 '14 at 17:28

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.

score 0 · Answer 22 · answered Jun 23 '14 at 11:14

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.

score 0 · Answer 23 · answered Jun 25 '14 at 04:33

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.

score 0 · Answer 24 · answered Jul 24 '14 at 23:16

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!

score 0 · Answer 25 · answered Nov 05 '14 at 18:35

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.

score 0 · Answer 26 · answered Nov 13 '14 at 17:18

0

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.

answered Nov 13 '14 at 17:18

GPY

3,832
1
16
11

score 0 · Answer 27 · answered Nov 18 '14 at 00:20

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.

score 0 · Answer 28 · answered Jun 06 '15 at 14:31

0

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.

answered Jun 06 '15 at 14:31

Inco Mob

594
2
7
20

score 0 · Answer 29 · answered Oct 13 '15 at 05:04

0

If using Xcode 7 with cocoapods v.0.38.2. Try removing copy pod resources from your today extension target.

answered Oct 13 '15 at 05:04

CoderPug

908
9
19

score 0 · Answer 30 · answered Jun 07 '16 at 21:50

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.

score 0 · Answer 31 · answered Aug 10 '16 at 06:49

0

In my case removing an underscore from the target name fixed it.

Not sure if it was the actual underscore or the namechanging itself that did the trick.

answered Aug 10 '16 at 06:49

Mathijs

1,258
1
10
27

score 0 · Answer 32 · answered Nov 29 '16 at 16:13

I ran into a similar problem, but in a WatchKit app with no pods. Skip Install was correctly set to NO for the iOS app, but was incorrectly set to NO for the WatchKit App.

Changing Skip Install to YES for the WatchKit App (but keeping it NO for the iOS app) fixed the problem, and Xcode correctly generated an iOS App Archive instead of a Generic Xcode Archive.

score 0 · Answer 33 · answered Jan 23 '17 at 22:30

In my case, none of the other 30+ answers were working. We had the location for Archives (Preferences -> Locations) set to a custom path pointing to our server (Windows Server 2008 if that makes any difference).

Once I set the location back to the default one in the local machine, it produced a regular iOS app Archive. I am not sure why this works, but I hope it helps someone else as well.

Now we store have to move the .xcarchive files to the server manually for storage, but at least get no issues with generic archives.

Pavel Kataykin · Answer 34 · 2017-02-15T19:55:58.347

In my case I had two targets (Target1 and Target2) and first of them could be archived to the "iOS App" but second to the "Other Items" only. So, for me the faster way to solve this problem was replacing my Target2 by a copy of Target1 by the following steps:
1. Rename Target2 to Target2_old
2. Make a copy of the Target1 and rename it to the Target2.
3. Change link to the proper .plist file (from older target) for new Target2 and check "Target Membership" in your classes.
4. Open "Manage Schemes..." and delete scheme for the Target2_old and then add new scheme for the new Target2
5. Select this new scheme and then Product -> Archive

score 0 · Answer 35 · answered Sep 15 '17 at 06:13

0

In my case, i had some files in the Copy Files. I just removed them and then everything was just working fine and i achieved the iOS App Archive. Go to Build Phases->Copy Files and delete the files. Hope this will solve your problem. :)

answered Sep 15 '17 at 06:13

S_J

35
1
9

score 0 · Answer 36 · answered Jul 31 '18 at 11:12

0

It happened to me on a app where the version was defined with a undefined variable $(APP_PRODUCT_VERSION)

I defined the version, and I could generate a iOS App.

answered Jul 31 '18 at 11:12

FredG

712
7
10

score 0 · Answer 37 · edited Dec 06 '18 at 11:40

0

This is for the poor souls like me for whom none of these solutions worked, where even a new single view application, builds without any error but fails to archive.

Go to Archive locations path (Available in Xcode -> Preferences -> Locations -> Archive Path) and delete folders of problematic days!

Damn you Apple!

edited Dec 06 '18 at 11:40

Eric Aya

69,473
35
181
253

answered Dec 06 '18 at 10:34

Dhilip

498
5
18

score 0 · Answer 38 · answered Mar 03 '20 at 19:41

0

None of these solutions worked for me. In my case, Targets->myApp->Signing & Capabilities->Signing Certificate was Apple Development instead of iOS Distribution.

answered Mar 03 '20 at 19:41

zeeawan

6,667
2
50
56

score -2 · Answer 39 · answered May 29 '12 at 12:47

-2

This is not the right solution, however, I was able to generate the App archive. I deleted the whole project and made a fresh checkout (I know, really stupid, but after couple hours of xcode refusing to generate the app archive I would have done anything). Once I set the correct code signing it worked. So probably, xcode had some mismatch in the configuration. If anyone knows, what (what possible configuration) could actually prevent xcode from generating an app archive I'll be glad to hear it. Thank you guys anyway.

answered May 29 '12 at 12:47

Filip Majernik

7,700
13
45
53

well in my case "Skip Install" is not available in xcode 4.4.1, at least i am unable to find skip intall in my xcode – Mashhadi Sep 21 '12 at 13:00
I suggest accepting Alex L's answer since you yourself say this is not the right solution. – Brandon Feb 20 '13 at 20:44

score -10 · Answer 40 · edited May 23 '12 at 08:06

-10

After creating an Archive, in Xcode's Organizer, Select your Archived project file and select Distribute.

This brings up another window that allows you to Save for Enterprise or Ad-Hoc Deployment.

This is the option you want, upon selecting Next you can choose the Distribution Profile to use, followed by the Location you want the .ipa to be saved to.

Make sure you select the Save for Enterprise or Ad-Hoc Deployment option and not the Export as Xcode Archive one :

enter image description here

edited May 23 '12 at 08:06

Mutix

4,196
1
27
39

answered May 23 '12 at 07:30

skram

5,314
1
22
26

No, it does not, because it generates an generic XCode archive, not the iOS App Archive. You can do that only with iOS App Archives. – Filip Majernik May 23 '12 at 07:38
1

+1 @skram, this is the correct answer. I've just edited your answer to include a screenshot – Mutix May 23 '12 at 08:07
6

This is certainly an answer - but it is not the correct answer to the question. You cannot Validate or Distribute a 'generic xcode archive', only an 'iOS App Archive' and the original question states that the poster is generating a 'generic xcode archive' not an 'iOS App Archive'. – delany May 23 '12 at 21:07

Cannot generate iOS App archive in xcode

40 Answers40

Linked

Related