This issue is preventing me from creating a Shipping build packaged for the App Store. Specifically, if I bypass the quirkiness by manually importing the mobileprovision (from my comments before) for the App Store version of the mobileprovision, it does not match up with the iPhone Distribution certificate. Instead, if I manually select the developer certificate, the build tool continues but fails later in the process when it tries to generate the binaries.
I wish it was easy selecting the 4.13.0 version (I believe you stated that the build tool was changed for 4.13.1 for iOS) so that I could get the product out. Even better, forcing 4.12.5 to open the very detailed and complex level for the environment I am attempting to package so I have a reliable method of packaging. Can you think of any workarounds? Hours and hours fighting with 4.13.1 in the last week trying to get a package only to keep hitting roadblocks.
We are currently working on this issue. However it would be helpful if you would post your entire output log from your latest packaging fail as a text file to ensure that the same problem is occurring exactly the same for both users.
I’d been having this issue for weeks. The solution I found was to completely make a blank project - name this [testproject] (can rename later) - make a new app in the apple dev page called testproject (or something similar) - then make a new provision named [InsertUE4Projectnamehere].profile e.g testproject.profile for your new app
Open up the new blank project - add the new provisioning profile and then test it. If it works - copy over your content folder from your other project into the blank one and then copy and paste everything.
We’ve used your log and accompanying screenshot to enter a bug report for this issue: UE-38006. You can follow the status of the issue in the following link: Unreal Engine Issues
In the meantime, however, has posted a 4 step solution to this issue on the following forum thread:
FYI, the workaround in that forum post does not work for me. The only workaround that works for me in 4.13.1 is to use a wildcard for the application id in the provisioning profile. I don’t know if wildcards are even allowed in publishing profiles (as opposed to the development profile I am using right now).
Thank you! I really appreciate the issue being fixed!
An Observation: Epic is very big on pushing the bleeding edge. I’ve noticed there is never a patch on a previous version once a new version is released (at least since I came along in 4.6). This seems quite at odds to the advice I have received several times to the effect of “don’t ever upgrade a production project to a new version of the engine”. Very interesting.
An Opinion: 98% of what I look for in new releases is bug fixes. I’d be ecstatic if one of the releases (or every other release!) was just fixes and polish without any whizbang new features. I’ve encountered more bugs in UE4 than I can count! I mean, UE4 is impressive technology, but before UE4 the last time I dealt with daily crashes of a tool I used every day was back in the late 90’s (when any decently-large piece of software crashed every day on Win95 and Macs).
Regarding your previous response. Every time there is a new iteration of the Engine (4.12, 4.13 etc.) it is our goal to identify and fix every bug before moving on to the next version. Sometimes these are introduced as hotfixes, 14.3.1 but other times they are pushed to the next version (4.14 in this case.) depending on complications etc. Moreover, sometimes bugs are not even detected until the next iteration. Hence, this is a virtually impossible task.
What this amounts to is, if you start a project in UE4.10 you should remain in UE4.10 unless there is a new feature that is critical to your project or if a fix did not get implemented in UE4.10. -In which case, if you are using GitHub it would be best to only merge that specific fix vs an entire commit.
A lot of users and Employees have expressed a desire for a release that only fixes bugs and does not introduce new features, however, in essence that is what is striven for each time and, as I mentioned before, is almost an impossible task. Meanwhile we have another wave of users requesting added functionality to the engine so, as it stands, the approach is to fix as much as possible while at the same time introducing new, requested features.
In short, your concerns have been heard and have been discussed at the highest level. However, I cannot guarantee an “all fix” build will ever happen, but being as it has been discussed, I cannot say that this beyond the realm of possibility in the future.
Thank you for your response! It is very nice to be able to have this level of conversation without standard boilerplate answers and information barriers I get from vendors of other software I deal with. I chose UE4 over Unity because I prefer release early & often and good communication over the alternative.
I will grab that commit and make a custom build and let you know how it goes for me. I didn’t realize the issues linked to the commit of the fix, so the possibility of finding the right commit and applying it to my own build didn’t even occur to me! Guess there’s no longer a rush for me to move to 4.14 after all…
, I cherry-picked that commit onto the 4.13.2-release branch and made a custom build. It did not fix the problem. It failed with:
env: Provisioning profile "AgilePerception_tvOSCowboySmashProvision" has app ID "com.agileperception.cowboysmash", which does not match the bundle ID "com.YourCompany.CowboySmash".
env: Provisioning profile "AgilePerception_tvOSCowboySmashProvision" doesn't include the application-identifier entitlement.
env: Code signing is required for product type 'Application' in SDK 'tvOS 10.0'
I should probably mention that there were quite a few merge conflicts in Engine/Build/Commit.gitdeps.xml between 4.13.2-release and commit 3a23a3. I resolved them all in favor of the changes made in 3a23a3.
I also made sure to clean, run Setup.command and GenerateProjectFiles.command before rebuilding.
I guess, technically, this actually fixed the original error – I’m just still not able to accomplish the task because of the next error. I mean, it found the provision initially and did most of the build, and now it fails at the code signing step. Which is very related, but not actually the same. Has that been fixed in some other commit?
As it may have gotten lost in this long thread, be advised that if you are using XCode 8, code signing is not exactly the same as in XCode7, see: Migrating Code Signing Configurations to Xcode 8
Please let me know if this link does not address and resolve the code signing issue you are currently experiencing. If it does not, please start a new post as this one is becoming long and hard to follow (Be sure to restate the issue, provide repro steps and associated logs.)