Wordpress-ios: CodeSign error when building the app

[JMDidon]

Hello all, I did some research here and on the web but I couldn't find any answer for my problem.

I tried to install the app on a device but I keep having an error (and a warning) :

Code Sign warning: CODE_SIGN_ENTITLEMENTS specified without specifying CODE_SIGN_IDENTITY. It is not possible to add entitlements to a binary without signing it.
CodeSign error: code signing is required for product type 'App Extension' in SDK 'iOS 8.1'

I had also another warning concerning provisioning files, but I have resolved it. Do you also had those errors ?

(PS : when I launch the app on simulator, it works as expected)

[lewiguez]

I'm an outside developer and I've had the same problem. Out of curiosity, how did you resolve the provisioning profile problem? In my case, I created a new provisioning profile through my developer account that was a different bundle identifier (because I obviously couldn't register org.wordpress).

This caused my .entitlements files to get out of whack because they specify org.wordpress. To resolve that, I originally changed the access group values in the .entitlements files originally. Now, I go into Build Settings for each target and remove the value for Code Signing Entitlements. I'm POSITIVE there is an easier way, but I haven't bothered to look for it yet. Additionally, I'm pretty sure this would affect communication between the widget and the application because there isn't a keychain group specified now by doing that.

I think your problem might be that you didn't specify an explicit Code Signing Identity in the Code Signing section in Build Settings of the WordPressTodayWidget target (check WordPress target too?)

But I am curious what you did to resolve the other issues.

It would be nice if this were fixed somehow to make it easier for outside developers. Because now if I want to add files to the project, it's hard to submit the project without wiping out the normal Automattic code signing settings. Not sure how easy it would be to do that...

[jstart]

@JMDidon @lewiguez Unfortunately there is no way to let external developers test features that require the 'group' entitlement needed for the Today Extension. Doing testing on device requires a provisioning profile. If you are working on a feature that requires device testing, do your testing and keep any added files copied externally. Then reset the xcodeproj back to upstream/develop and then add the files in. I can't think of any easy way to make it so that external developers can easily build for device. Maybe the project could not specify a specific provisioning profile or identity and then the internal team could just change that for releases.

[JMDidon]

@lewiguez

Out of curiosity, how did you resolve the provisioning profile problem?

I opened the .xcodeproj file and deleted all references to "PROVISIONING_PROFILE" (as explained here : http://stackoverflow.com/questions/1760518/codesign-error-provisioning-profile-cannot-be-found-after-deleting-expired-prof). I think it's pretty brutal even if it worked ...

I tried removing the code entitlements for each target, but I'm having the same issue even so =/

[astralbodies]

This is one of the reasons we started to pull things out of the main app and make them CocoaPods, like stats and the new editor. Extension development requires code signing entitlements if you want to launch them on your own device. Code signing in general isn't very convenient for open source projects.

I think a separate target that disables the extensions (currently one right now) or something along those lines should be done for ease of contribution.

[lewiguez]

OK, @JMDidon, Here is everything I did to get the project building correctly on my device. Not saying this is what you SHOULD do, but it worked for me. Code signing often feels like black magic to me at times though, so take everything I say with a grain of salt because I'm definitely not an expert ;)

I started with a fresh project. If you made changes to one that you just don't want to lose, either stash them or just clone another copy somewhere.

Here are the things I did:

1. Created a provisioning profile. I have an individual account, so Xcode didn't create a wildcard team provisioning profile for me. I just created a WordPress specific one.
2. Change the bundle ID. You'll have to do this for both targets, I think.
3. Edit the Entitlements files for both targets to reflect your new bundle ID.
4. In the project settings, change the development team to you/your team (same place you change the bundle ID in Xcode)
5. For each target's Build Settings, I set CodeSign Entitlments to be empty, but if you're changing your bundle ID in the entitlements file you shouldn't have to do that. I might've been overcautious with this one...
6. Change the CodeSign Identity in each target's Build Settings. I did this for every scheme, but Debug should probably suffice (once again, being overcautious, I suppose). I changed this to iPhone Developer (_My Name_)
7. Change the provisioning profile use. You have to do this for each target, I think. And at the project setting level. There is an automatic setting in build settings, but I like to explicitly set what I'm doing. Too many times I've thought _"Go home, Xcode. You're drunk."_ to trust it for anything automatic...

Your mileage may vary. Would be interested in how much of this is necessary versus how much of it doesn't matter. Or, if there is a simpler way. I haven't invested the time to fine-tune this approach. It's been good enough for me for now.

Remember what I said about a fresh install? Here's why: I took these changes and stashed them in git. That way if I go to a blank state again, or just want to pull upstream changes, I can just apply the stash afterwards and I'll still be able to build on my device fairly easily. Eventually, this will lead to problems if the project changes significantly, but for now it works :)

@astralbodies I think having a separate target would definitely be helpful. That's a great suggestion.

[kwonye]

With iOS 10/Xcode 8 and their auto-signing feature, let's see how this pans out.