Will a self signed SSL certificated do? I read somewhere on stackoverflow that self signed certificates were unsafe. Are they really unsafe in my case, where I'm in control of both the server and the iOS client?

Is it ok to use a self signed certificate in this way, or will my app be rejected by Apple?

A self signed certificate renders a warning on the client side. Will that warning lead to troubles with NSURLSession?

Perhaps. If you embed your own copy of openssl, yes, you can tell it to use your own certificate. Then you have to use your own HTTPS code; you can't use the built-in library.

Another option is to install the root certificate you used to generate the signing certificate that you used to generate your own certificate into the root certificate store of the phone. This is not simple and puts up annoying warnings to the user.

Is it ok to use a self signed certificate in this way, or will my app be rejected by Apple?

If you go with option 1, then Apple won't reject it. If you do the second thing, I'm not so sure. Enterprises do this kind of thing to their employees phones, but that may be under the "enterprise" option of the app store, rather than the "general availability."

A self signed certificate renders a warning on the client side.

That warning is generated by the Safari browser, not by the OS. The browser may use the NSUrlSession class callbacks to implement this warning. See the documentation:

When a server requests authentication or provides credentials during TLS negotiation, the URL session calls methods on its delegate, allowing you to handle the authentication or certificate validation in a custom manner.

You can presumably do the right thing by handling enough of the following methods:

That seems like it defeats a bit of the purpose, though -- if you're not going to verify that the SSL connection is not tampered with, then what benefit is using SSL giving you?
Edited February 11, 2016 by hplus0603