I have a standard Xojo Mac desktop application that makes a call (via declare) into a 3rd party .dylib and has been working well for about a year. The 3rd party dylib recently started failing on a connection it makes to an insecure web service (“http://”) while running on Sierra. My first thought was to simply add the NSAppTransportSecurity key to my plist:
No luck there, so I created a simple test app in Xcode, linking to the same dylib, with the above plist, and it works fine.
I thought any 3rd party dylibs I call from Xojo would inherit the NSAppTransportSecurity settings from the calling process? Hopefully, I’m missing something simple.
The call fails just like it does in Xcode when that info.plist entry is removed. I could use https, but I shouldn’t be forced to use it. And yes, I’m in contact with the author of the 3rd party Dylib.
I’m more curious about why these plist entries work in Xcode, and not Xojo.
The call fails just like it does in Xcode when that info.plist entry is removed. I could use https, but I shouldn’t be forced to use it. And yes, I’m in contact with the author of the 3rd party Dylib.
I’m more curious about why these plist entries work in Xcode, and not Xojo.
-Jim[/quote]
How are you adding those entries to the plist? PlistBuddy?
First of all, Apple is moving away from allowing insecure connections, so in the long run it would probably be better to solve it on the server end. You can however add the plist keys, but you must do this before the app is signed. I suggest adding a post-build Build script with the following code, just to make sure it is getting in the exact right place:
dylibs called from Xojo via declare don’t seem to inherit the plist entries from the main application. Ill post an example application tomorrow to illustrate this, Or, I’m completely wrong and I’ll eat my hat,