2

I am getting following error on build:

The application does not have a valid signature

After playing with it a little while I have found following:

  • error appears only after building app with no changes - that is, if I encounter crash during development and try to build again it will show error
  • in order to build again I need to add space or new line and after that it will work
  • it will work after full clean -> build. This is not really acceptable since project is huge (over 300 files) and build time is around 20 mins with cocoapods and what not.
  • Happens on all kind of iOS, but only on device. On simulator it is working correctly. Tried from 8.0 to 10.2 iOS versions.
  • Clean build will fix for only one time, after that if I try to build the same code again, same error occurs.

Other relevant information:

  • Xcode 8.2 ( happened on 8.0 and 8.1 as well)
  • Language is Swift 3
  • MacOS is Sierra (10.12.1)
  • Certificates used for signing are enterprise

Already tried all proposed solutions online including SO (e.g. App installation failed) but no luck.

My question is: How can I resolve this issue so I am able to build without changing code each time I want to build? I assume that this has something to do with Build settings...

Community
  • 1
  • 1
Miknash
  • 7,888
  • 3
  • 34
  • 46
  • 1
    I have the same issue, but found out that after a full clean ( go to Product and press cmd - you will see "clean build folder"), it's still happens, but much less frequently – Witterquick Dec 19 '16 at 14:39
  • 1
    hey Roee84, Yeah, that is what I meant clean build : Derived data, clean build folder, clean build - derived data is a little harder to find but I took care of it as well. No luck. At first I thought it was something related to Xcode release and that was actually a bug, but this behaviour kept showing :( – Miknash Dec 19 '16 at 14:41

1 Answers1

1

It seems that this is a known issue with Xcode. I haven't experienced it with our project, so it may be related to CocoaPods, or something else that is specific to your project. I remembered seeing this problem on Apple's forums here.

Though more of a workaround than a solution, you can force the app to rebuild each time by adding a BuildDate.plist file, adding a build phase to throw the current date / time into the plist file. This change is enough to trigger enough of a rebuild so that the code signing bug doesn't affect you. And it should cause a recompile of anything time consuming.

This should save you and your team from having to make a simple change to the code when this happens.

wottle
  • 13,095
  • 4
  • 27
  • 68
  • Hey @wottle, thanks for your answer - What I don't really understand from your answer is: Does this trigger recompile on each build ? Because it will cause 20 mins of "no work" per build :( – Miknash Dec 19 '16 at 16:47
  • It should only "rebuild" that one file, which has no other dependencies in the code. Shouldn't take 20 minutes for a change that small, especially since plists aren't compiled, they are simply copied resources. To test, you could simply change a plist in your project and see if it fixes that problem / doesn't take too long for the subsequent build. If it doesn't take too long, I would then make the build phase scripts to automatically update the plist during each build (will execute even if nothing in the project has changed). – wottle Dec 19 '16 at 16:50
  • Yeah sure, adding .sh script wouldn't prolong build time too much - and rebuild info.plist is okay as well. I am concerned about rebuilding source files. I will try this approach tomorrow morning, I hope it will fix an issue :) Thanks – Miknash Dec 19 '16 at 16:52
  • This link you provided helped me a LOT. Just a few corrections - I hope you will update your answer for other guys with same issue but too lazy for comments: 1) BuildDate.plist will not resolve this issue - you have to find your own script that actually updates something in info.plist. 2) you actually use that changed value in the code (e.g. showing build version). I have about 4 scripts - 3 for pods. the last one was for build version and caused issue. After removing it I can build flawlessly. – Miknash Dec 21 '16 at 12:41
  • There are two ways to fix this: either run this script for prod only ( don't need build versions for your local build) or create separate plist file and update that one. – Miknash Dec 21 '16 at 12:42
  • So I'm a bit confused. why would you only run the script for the prod version. The prod version is likely a one-time build, and you are only experiencing this signing error when you build after making no changes (e.g. after a crash, etc.). It seems like you would only need the script that updates the plist to be run on the development builds to a physical device. You also mention 4 scripts. Is the last one you mention the new one you created to update the plist. – wottle Dec 21 '16 at 15:06
  • Maybe you should answer the question with the exact fix you used. I can update my answer, but I'm not sure exactly what changes are needed to my answer. – wottle Dec 21 '16 at 15:06
  • No, there were 4 scripts and one of them is the problem. Since 3 of 4 script are related to Pods, this is actually the only one that we wrote. Also my fault, I changed the script to execute only on bamboo - where build number should be changed. So it's not only production but every development build that will be distributed to testers. – Miknash Dec 21 '16 at 15:09
  • So an existing build phase script was causing this problem? That's interesting - have you isolated what in your script was causing the code signing to no longer work? – wottle Dec 21 '16 at 15:19
  • Yes, existing .sh script. Well, from what I could find is that script changed a key in info.plist file which caused installation to fail. More then that - no – Miknash Dec 21 '16 at 15:21