[Guvante]

Were you using the built in web capabilities or embedding a library to handle the encryption? In theory Apple's methods for accessing HTTPS should be safe while embedding OpenSSL would not be (unless you linked to a shared object they deployed).

[metafunctor]

I don't think it matters where the encryption capability comes from.

The iTunes Connect FAQ says: “If your app uses, accesses, implements or incorporates industry standard encryption algorithms other than those listed as exemptions under question 2, you need to submit for an ERN authorization. Examples of standard encryption are: AES, SSL, https.”

There are a lot of exemptions, but only using Apple's HTTPS is not one.

[Guvante]

Sounds like Apple is the cause here, since export restrictions don't apply to things that are never exported. If you aren't embedding the algorithm then your code is not exporting the algorithm.

[eps]

> industry standard

What about custom crypto then?

[noblethrasher]

The line between encoding and encryption is blurry, so it would be difficult to enforce without being seeming arbitrary or capricious.

On the other hand, custom crypto will almost certainly be defective, so why bother prohibiting it it?

[quasse]

Yeah, I'd like to see this answered too. If OP was just using the built in WebKit browser this seems to have all been a big misinterpretation of the rules. If they did indeed roll their own browser with HTTPS, why?

The post is a very good guide to navigating that bureaucratic process either way though.