I have wasted the better part of a few days dealing with problems with 4.13 when it comes to deploying and packing for iOS. This is somewhat related to the issues of deploying to iOS (see the other thread on AnswerHub) because the visual editor “sees” the mobileprovision and certificate (developer) but the buildtool does not seem to recognize it. I am able to circumvent the problem with deploying to iOS via manually selected the mobileprovision file (instead of using the cached, imported mobileprovision files).
The error is as follows:
PackagingResults:Error: Error Provision not found. A provision is required for deploying your app to the device.
PackagingResults:Error: Error Signing key not found. The app could not be digitally signed, because the signing key is not configured.
The log output (from viewing the certificates in the project settings) to the File->Package->for iOS is attached and can be seen here. The editor shows the mobileprovision file that was imported (generated from the Apple Developer center) along with the iOS Distribution certificate generated for the company that will be publishing the app.
According to the log, it cannot match the bundle identifier looking for the provision. Note, it is seeking the prefixed (with organization identifier) bundle identifier during the packaging process. However, the package settings matches only on the specific bundle identifier that I’ve configured in the iOS section of project settings (the expected behavior).
I have used the production 4.13.1, source-4.13.1, and source-4.13.0 packagers to try to build the package with the same problems. I have successfully developed and deployed (to App Store and Google Play) using 4.12.5 with none of these issues for a different app.
According to the other thread, staff members have indicated that they are aware of this issue and are working on a fix; they’ve solicited the log output (which I’m including here). 4.14-pre1 is badly broken on Mac so I can’t test to see if any patches have been applied to that build.
I’ve verified that I am not going insane or somehow developed a failure-to-configure-for-packaging condition.
I created a 4.12.5 blank project, configured the app bundle name, selected the App Store provision, and then selected the organization certificate (as I always have). I was able to successfully package for iOS. I did witness a few interesting things that allow me to speculate as to what may be happening in 4.13+.
- I got the same error message about provision could not be located for deployment to the device:
PackagingResults:Error: Error Provision not found. A provision is required for deploying your app to the device.
PackagingResults:Error: Error Signing key not found. The app could not be digitally signed, because the signing key is not configured.
- However, directly AFTER, the cook proceeds as expected.
MainFrameActions: Packaging (iOS): Running AutomationTool…
MainFrameActions: Packaging (iOS): Setting up Mono
MainFrameActions: Packaging (iOS): Start UAT: mono AutomationTool.exe -ScriptsForProject=/Users//Documents/Unreal Projects/FourTwelvePackaging/FourTwelvePackaging.uproject BuildCookRun -nocompile -nocompileeditor -installed -nop4 -project=/Users//Documents/Unreal Projects/FourTwelvePackaging/FourTwelvePackaging.uproject -cook -stage -archive -archivedirectory=/Users//Documents/Unreal Projects/FourTwelvePackaging -package -clientconfig=Shipping -ue4exe=UE4Editor -pak -prereqs -nodebuginfo -targetplatform=IOS -CrashReporter -utf8output
The mobileprovision is designed for deployment to the App Store and not my development device - so I would expect that behavior. You can see afterward, it actually kicks off the automationtool process to build the package. 4.12 seems to understand this and continues with the build even when the device deployment eligibility check fails.
Even though I think this should be a fairly easy patch to make available to all of us experiencing this problem, I suppose the only thing I can do now is hack the packaging environment to see if I can’t force it to continue even after encountering the “problem” with not being able find the appropriate certificates or provisions.
Hello ,
The provisions are still required to be able to deploy, as the message says. The provisions are designed for your deployment device as well, as you would need to have your device included in your provisions to be able to deploy to that device when you do use them.
As far as being able to successfully cook without having provisions, I spoke with one of our platform team about this and one mentioned that the fact that it was able to continue packaging after those errors was the actual bug. He fixed this without ever entering a bug for it after discovering it was the case and it was fixed somewhere between 4.12.5 and 4.13. Our intention is that provisions and certs are required to package a project for iOS.
As mentioned on the other post, we’re still looking into that issue. If you do have any further information about that issue, it would be best to post it there so that we don’t split our information.
While I can appreciate “the fix” - I can happily report that it does not continue to package on 4.13.0 or 4.13.1 (either Launcher or from-source versions). It aborts as soon as it complains about the lack of provision profiles.
I am not attempting to use a provision to deploy to a device. I am using the App Store provision along with the organization certificate (as with 4.12.5 or older). Your intentions are met and your explanation is cryptic considering that you’re writing this off as a non-issue (having been fixed prior to 4.13.0). What else must I do to explain that it is affecting 4.13.0 and .1?
Okay, perhaps you misread my original posting (and replies, etc.)
I do have my provisions setup. I have my certificate selected. I verified that the plist generated has the same app bundle ID. It still reports as not being able to find a provision to deploy to device. I am not attempting to deploy to device. I am attempting to package to get the IPA to submit for the App Store.
I filed this separate issue because it is, indeed, a separate issue. If your contention:
is that you are having errors with the engine recognizing your provisions correctly. This would result in the packaging failing due to not having the provisions be recognized as valid, even if you do have them set up correctly. This would likely resolve itself as soon as the other issue is resolved.
I would have accepted THAT as the actual answer for this one, acknowledging that the UI (project settings) can indeed find the mobileprovision and corresponding certificate but the build tools do not.
Now that I understand that you were spilling my comments from the other issue (cannot deploy to mobile device) with the fact that I was able to bypass the other problem and have met the need to deploy to the App Store - but CAN’T, I await hearing back the progress of the issue. Understandably, companies that utilize the “stable” build of UE4 need it to behave as expected when attempting to distribute their apps on the App Store, agree?
Is there a Jira reference that I can subscribe to for this issue?
I don’t believe you read my post correctly. The fact that it was continuing to package after giving you the error about the provision not being found was the bug. We do not intend for you to be able to package for iOS without having your provisions set up.
The issue you’re experiencing is a symptom of the other issue you’re having which is referenced in the other post. Unless I’m misunderstanding, the issue you were originally having and linked to in your original post, where you posted the following:
“I, too, am experiencing this problem with 4.13.1.”
is that you are having errors with the engine recognizing your provisions correctly. This would result in the packaging failing due to not having the provisions be recognized as valid, even if you do have them set up correctly. This would likely resolve itself as soon as the other issue is resolved.
It doesn’t matter if you are attempting to deploy to a device or attempting to deploy to anything at all. If you are trying to package for iOS, despite what you intended to do with it after, unless the engine recognizes that your provisions and certs are in order, it will fail to package. This is the intended workflow. The other issue will need to be fixed before you are able to package for iOS as it is making the engine see your provisions as invalid.
It would be best to ask in the other thread for that, as that is where the issue is being discussed. I don’t believe there is one currently as we usually don’t enter a bug report until we have a reproduction case for the issue.
I am experiencing the same problem when building from source 4.13.1 Have you found a proper hack or fix to this problem?
No, and based upon the roadmap for 4.13, I don’t even know if this is on the radar for a fix. Frustrating.
I was able to hack the iPhonePackager to just force looking for distribution provisions which got my distribution build to work.
In iPhonePackager.cs after the ParseCommandLine, I just hardcoded:
Config.bForDistribution = true;
The problem I see is that the program is not getting the proper command line arguments to tell that it is a distribution or shipping build. I don’t have the time to fix it properly, but if Epic is really going to ignore this then maybe I’ll go and fix it properly if I can find the time.
Edit:
I have a slightly better fix as the previous one would disable the ability to build in non-distribution, obviously. I see the IPhonePackager being invoked from several different places throughout the codebase- this won’t fix all the cases. But this change will fix the start of the packaging process that blocks the process from running for distribution.
This should replace the block inside the function FIOSTargetPlatform::CheckRequirements as of 4.13.1
bool bForDistribtion = false;
GConfig->GetBool(TEXT("/Script/UnrealEd.ProjectPackagingSettings"), TEXT("ForDistribution"), bForDistribtion, GGameIni);
FString BundleIdentifier;
GConfig->GetString(TEXT("/Script/IOSRuntimeSettings.IOSRuntimeSettings"), TEXT("BundleIdentifier"), BundleIdentifier, GEngineIni);
BundleIdentifier = BundleIdentifier.Replace(TEXT("[PROJECT_NAME]"), FApp::GetGameName());
#if PLATFORM_MAC
FString CmdExe = TEXT("/bin/sh");
FString ScriptPath = FPaths::ConvertRelativePathToFull(FPaths::EngineDir() / TEXT("Build/BatchFiles/Mac/RunMono.sh"));
FString IPPPath = FPaths::ConvertRelativePathToFull(FPaths::EngineDir() / TEXT("Binaries/DotNet/IOS/IPhonePackager.exe"));
FString CommandLine = FString::Printf(TEXT("\"%s\" \"%s\" Validate Engine -project \"%s\" -bundlename \"%s\" %s"), *ScriptPath, *IPPPath, *ProjectPath, *(BundleIdentifier), (bForDistribtion ? TEXT("-distribution") : TEXT("")) );
#else
FString CmdExe = FPaths::ConvertRelativePathToFull(FPaths::EngineDir() / TEXT("Binaries/DotNet/IOS/IPhonePackager.exe"));
FString CommandLine = FString::Printf(TEXT("Validate Engine -project \"%s\" -bundlename \"%s\""), *ProjectPath, *(BundleIdentifier), (bForDistribtion ? TEXT("-distribution") : TEXT("")) );
FString RemoteServerName;
GConfig->GetString(TEXT("/Script/IOSRuntimeSettings.IOSRuntimeSettings"), TEXT("RemoteServerName"), RemoteServerName, GEngineIni);
if (RemoteServerName.Len() == 0)
{
bReadyToBuild |= ETargetPlatformReadyStatus::RemoveServerNameEmpty;
}
#endif
You should also make sure that the correct certificate and provision you wish to use is defined in the DefaultEngine.ini. Though this all makes me wonder that if I had a development provision on my builder- if the initial step would have passed and it would have used the distribution provision I explicitly defined in the .ini? Oh well, I’ve already wasted too much time on this. Good luck, all!
I am building from source and the binaries.
I’m going to try out your patch - if it works, you’re a godsend! I’ll update this thread if your mod works.
- you should have posted your comment as an answer. While I accept the “official” answer of - it may be fixed related to another bug, NeoRob’s suggestion of patching the iPhonePackager source code is a definite workaround.
I can confirm that it works.
I can also confirm that the command line parsing seems to be broken in 4.12 as well since forcing “for distribution” suppresses the error message about not being able to find a mobileprovision file for deployment. As I’ve repeatedly pointed out, when packaging a Shipping build for distribution on the App Store - it should not care about a developer certificate. Indeed, with NeoRob’s workaround, the packager proceeds as expected and does not complain about not finding a mobileprovision file for deploying to the device.
NeoRob, on behalf of other members of the UE community experiencing this problem and the company I work for, my hat is off to you.
Cheers, . I just posted an alternate solution, less hacky solution.
I am just wondering though, did you have a development provision and matching cert on the machine you were packaging on? It seems the build process will use any provision/cert you explicitly define in the DefaultEngine.ini regardless of what it tries to choose at the beginning of the process. So, if it thinks it found a provision & cert that works, it’ll continue and then the final signing it might choose the correct one?
When I started down the rabbit hole with struggling to get the packager to work, I purged all provisions/certificates from ~/Library/MobileDevice/Provisioning Profiles and multiple purges of the Intermediate and Saved folders within the project. The only certificates that were loaded (via direct import) were the distribution provision and matching certificate.
I agree with the theory regarding DefaultEngine.ini being the ultimate decider of which pair to use (witnessing 4.12.5 behavior of a complete end-to-end cook). Hopefully, your diligence will help the UE4 engine developers get closer to the real answer for what I believe has been a bug since pre-4.13. I can’t believe that this didn’t get addressed in the 4.13.2 patch (as a blocking bug) since Epic realizes that companies do actually develop for the App Store (including Epic Games).
I have a question.
I only have the basic development account (the free one that doesn’t let you distribute) purely for testing purposes. Because of this I can only access a provision for development.
Could I use this same method for my situation by changing some of the code so it only uses a development provision?
I’ve tried quite a few situations already, deleting old provisions, importing back in, trying the iphonepackager.exe posted. But I’m still getting the “Provision not found” “Signing Key not found” when I try to deploy to my iPhone.
Anybody else in the same situation that has managed to make it work?
Hello sonic172,
Due to how old this post is and the different nature of your question, could you please make your own answerhub post for your issue?
Where to find the iPhonePackager.cs file? I can only find the IPhonePackager.Automation.cs script.