Xcode build settings - Remove code from plist on production build

Question

In our project we have turned off HTTPS requests and send them as HTTP for internal testing against an API on my local machine. To do this I added this code to the info.plist

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

This allows the app to run with HTTP requests. Obviously this is bad for a live environment as well as unlikely to get app store approval; so I would like to set up code in our production build target to remove this offending code automatically lest we accidentally leave it in. I've done some searching around but can't seem to find any advice online.

score 2 · Answer 1 · edited May 23 '17 at 11:58

2

Add a user defined build settings like ALLOWS_ARBITARARY_LOADS then change its value to Yes or No for your configurations. Then change the info plist entry

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <string>$(ALLOWS_ARBITARARY_LOADS)</string>
</dict>

Note: Here NSAllowsArbitraryLoads is added as a string since we cannot add boolean or number value rom build settings to plist. Even though it is a string its bool value will be boolean Yes or No in runtime since info plist is taking as a dictionary.Reference

edited May 23 '17 at 11:58

Community

1
1

answered Sep 24 '15 at 05:33

Johnykutty

12,091
13
59
100

6

Assigning NSAllowsArbitraryLoads a string value of YES fails so it seems it has to be a BOOL thus a User-Defined value doesn't seem to work. Have you gotten it to work using a string? – Steve Sep 30 '15 at 00:02
[SE notifications sucks] – Iulian Onofrei Feb 01 '16 at 14:50
Not sure it works to use a String for NSAllowsArbitraryLoads. It work for user-defined keys only... :( – Hugues BR Jul 06 '16 at 14:52

score 1 · Answer 2 · answered Sep 24 '15 at 06:58

The best way of doing this is to create a copy of your current app target and name it like 'MyApp PROD' and name your existing target like 'MyApp DEV'. Now both the targets have their own .plist files. In 'MyApp DEV' plist file you put desired values required for development and in 'MyApp PROD' plist file you don't keep those values which are not required in production app.

Using separate targets for each environment (like DEV, UAT and PROD) gives you other advantages like:

1.You can have different build settings for different targets like Code Signing Certs and Provisioning Profiles specific for that target so that you don't have to change them again and again.

2.You can associate desired resource and implementation files required for a particular target.

and many more.

It seem a bit a burden to manage different target (at least just for this), you may want to try to use script in build phase to change settings based on configuration, check this: http://stackoverflow.com/questions/32390228/is-it-possible-to-disable-ats-in-ios-9-just-for-debug-environment — Hugues BR, Jul 06 '16 at 15:00

Xcode build settings - Remove code from plist on production build

2 Answers2

Linked