iOS arm64 issue on 4.17.1

Development Platform & Builds Mobile
, , , , , ,
1

In the project settings window, under Platforms, iOS… There used to be a place to select which version you wanted for distribution and shipping. You could either choose to use armv7, armv7s, arm64, a mix, or all of the above for each heading. Now in 4.17 that build section is very much simplified. I am going to say because of everything needing to be arm64 on iOS.

Here’s the rub…

If that is the case and we are only packaging the arm64 slice, Application Loader won’t send it to the App Store or TestFlight unless the info.plist has the following…

<key>UIRequiredDeviceCapabilities</key>
<array>
  <string>arm64</string>
  <string>metal</string>
</array>

Not a problem… I can add that in the ‘Additional plist Data’ section. That will indeed add that info to the end of the info.plist file when it gets autogenerated. But why? Why isn’t it just generating that by default now that we don’t even have the option of selecting arm7 or arm7s. See, it keeps the default…

<key>UIRequiredDeviceCapabilities</key>
<array>
  <string>armv7</string>
  <string>metal</string>
</array>

Like I said, it will add the arm64 code that I put in the Additional plist Data section, but it does not overwrite the default, it just appends to the end. Seems like it should just make that the default.

I am assuming that my workaround is working, as I did just upload to TestFlight and got a notification that the current build is ready to test.

Is this a bug? Should that be defaulting to autogenerate an info.plist with the arm64 in there? Please, correct me if I am missing something.

As a side note, those of you that are getting the -

ERROR ITMS-90502: “Invalid Bundle. Apps that only contain the arm64 slice must also have ‘arm64’ in the list of UIRequiredDeviceCapabilities in Info.plist.”

  • you will need to add the above arm64 section to the Additional plist Data section of the project settings… Under Platforms, iOS…
2

Hello Onildera,

I attempted reproducing this by simply creating a 4.17 project, packaging for iOS with the default settings, unzipping the IPA and checking the .plist info and it is automatically set to arm64. It seems that the only time this occurs is with converted projects. Can you confirm that this is the same as what you are experiencing?

3

Yes. This is a converted project. Is there a quick fix that I can apply?

I don’t know if this is related, but I also get this when I package…

IPP WARNING: Distribution builds should be made in the Shipping configuration!

It is set to shipping… When I check the distribution box, it auto sets to shipping.

4

That took care of it! Thanks for the quick reply!

Will there be a fix for migrated projects or should we just do this for all of them? I only moved one to test things for now.

5

In the Config folder for your project, try opening up DefaultEngine.ini and finding this section:

[/Script/IOSRuntimeSettings.IOSRuntimeSettings]
MinimumiOSVersion=IOS_8
bDevForArmV7S=True
bShipForArmV7S=True

Changing those ArmV7S settings to false should fix the problem for you. Please let me know if it helps.

I’m not sure about the warning, but it shouldn’t prevent anything from completing successfully.

6

I thought I had already responded to this, my apologies. I spoke with the team responsible for this and they mentioned no intention to make a change that would automatically change the config file, unfortunately this will need to be a manual change. You can also change the settings prior to conversion.

7

Thanks for the update! This shouldn’t be a huge problem for those that know to make the change.

However, if the Arm7s functionality has been removed in 4.17 and later, why not make it part of the conversion process? It isn’t like the original project is touched. Why would these lines stay in the config file if it knows that it is upgrading to an engine version that will not be using it? Not really a complaint, since the fix is fairly easy. I was just curious as to why there isn’t at least a warning that we would need to make the change. Thanks!

8

Got it! Thanks! I was just curious. I wanted to make sure that I wasn’t missing something.

9

There are still people who would like to leave the setting enabled. I’m not sure of the reason and it could be related to custom builds of the editor but we do have users that are still using the functionality. That’s not something go into detail about here however, as this post was for reporting the bug.