I'm using NSURLRequest in my current app which is in the App Store. I need to change to Https in the next version.
Do I need to declare "Encryption" in the Apple "upload binary" section when submitting the application?
I saw 2 related threads, but I'm not convinced with the answers there. If someone with real experience or knowledge could answer this one, it could be great..
Thanks.
This only concerns encryption within the application. If you're not doing any of that then you're OK.
https://itunesconnect.apple.com/docs/iTunesConnect_DeveloperGuide.pdf
No, they only want to know if you are implementing an encryption algorithm inside the app itself because there are various laws involved in what can be exported to where with regard to types of encryption.
I'd recommend asking Apple, but I suspect the answer is no.
Refer to Apple's Export Compliance FAQ (needs developer access).
Related
I am using sharekit in my app and now I am ready to upload my app to iTunes Connect. My question is:
In "Export Compliance", I am asked if my app uses encryption, and since I am using sharekit and it deals with Twitter and Facebook passwords, should I check that I am using encryption or not? If yes, what kind is it?
No, ShareKit shouldn't require answering yes to that question.
Yes, you are using encryption! You are using HTTPS, HMAC and various other technologies through ShareKit. See this question for discussion of these requirements. There are a series of questions after that one which determine whether you need further paperwork.
Does anyone know if I use the Twitter Framework will my app contain encryption?
Frameworks are not included in your app. They are in the device's firmware and are not copied into your app. So even if an iOS framework had encryption in it, it is not included in your app, you just make function or method calls to it, and are not distributing encryption software.
I think no one really answered your question directly; they were merely inferring your intent. The Twitter framework docs only mention HTTP for API requests. The Twitter docs on this say that SSL is optional though encouraged. So I'd imagine that iOS is handling user authentication via SSL in the background, but that all API requests by developers are done over HTTP using oauth. This is only speculation -- to verify you'd want to run a packet sniffer on your local network and check out the transactions when you call the framework methods.
Regarding the export controls mentioned in other comments here, I'd advise you to look at the iTunes Connect FAQ dealing with export controls within the Dev Center. Apple makes it very clear in that document that using encryption integrated into the iOS frameworks still requires you to apply for an ERN with the US Dept. of Commerce. (I won't quote it due to NDA) The other comments currently on this page are simply wishful thinking. I'm sure some developers were confused (and it is confusing), or perhaps have outright lied and have apps in the store which are violating US law. IANAL; I'll leave that choice up to you.
Having said that, there have been some exemptions added to these requirements, as outlined here.
This just saves time.
Since I already have a web applciation.
I can just stick it inside a webview.
The question is: Does it turn off many users? How many users will be disgusted that the entire iPhone app is written in WebView?
I think it's pretty safe to say that most iPhone users are expecting apps to use the power of the iPhone, not just be a portal to a mobile website.
Think about facebook mobile compared to iPhone facebook app. If you're an iPhone user, I'm assuming you'd much rather use the app than a mobile version of the site (or mobile version of the site contained in a WebView in a an app).
That being said, depending on your app, if the mobile version of your app is highly usable, it could be okay...
Just my thoughts...
John Gruber on Daring Fireball just wrote about this today.
From a usability perspective, native apps usually feel better. They may also be more responsive and handle large amounts of data more gracefully. I have a few so-called "apps" on my devices which are just glorified Web apps, and they don't necessarily scream quality.
If you've already done your app, then just ship it. But keep your mind open to feedback from your users.
The answer is almost certainly "no". People care far more about the usability and experience of interacting with your application than what API-supplied widget you use to render it.
I read Apple has begun removing apps that are like this. Well technically, they remove apps they think could be easily implemented as a webapp instead. Yours obviously qualifies ;)
Source: http://techcrunch.com/2010/03/07/apple-cookie-cutter-apps/
EDIT: Apple seems to not mind, according to the Human Interface Guidelines:
If you have a webpage or web application, you might choose to use a web view to implement a simple iPhone application that provides a wrapper for it.
Of course, Apple has a tendency to contradict themselves. ;)
Apple human interface guidelines says this isn't even allowed. I forget where it comes from, but somewhere in the guideline it says apps that are only web views are not allowed. I'm about 95% sure I've seen this. Can anyone confirm?
I would like to use libCurl in an app for communicating with web services, and unfortunately it is not included int he iPhone SDK. Now I've figured out how to include Curl as a static library in my app, however, I'm wondering if this will get my app rejected with Apple. Has anyone included Curl in an app and had it approved by Apple?
Thankyou.
EDIT:
Guess I should have been more clear, I was wondering if anyone had actually done this, because I am unsure whether the Curl SDK contains undocumented functionality.
It would appear from the curl license (http://curl.haxx.se/docs/copyright.html) that using it within an iPhone application is completely permissible because there are basically no restrictions specified in the license.
There is some debate about whether Apple's distribution restrictions preclude use of GPL software in your app, but curl is not GPL licensed.
I am not a lawyer, you should probably checked with one just to be sure. Isn't software development fun!
I use the NSURLConnection and the related classes to talk to web services in my application. I have read (but have no first hand experience) that code that uses standard sockets interfaces can have problems with the sockets going away when the phone goes to sleep, and not coming back on wakeup. It might be easier to skip using Curl altogether.
As libcurl is MIT licensed I don't foresee any license issues when linking it statically.
Edit: If your application is GPL licensed, some configurations of libcurl can't be linked and distributed legally.
I think you can.
If you need to cross-compile libcurl, go visit my tutorial:
http://sites.google.com/site/olipion/cross-compilation/libcurl
I show how to cross-compile it with libssh2 support.
Regards,
Olipion.
I don't believe Apple cares about what libraries you use within your application so long as they are statically linked. I mean why would they care if you were violating a license agreement (which I don't think you are) on someone else's IP?
I think its more an issue of what you do with it, since curl can be used to do a lot of things that may "toe the line" as far as legality (such as bots) some things done with curl are best not put into applications that are distributed / sold to 3rd parties, but if you're just doing stuff thats plainly allowed, such as connecting to an API, I don't see why it would be an issue, and I don't think Apple would get involved either way other than disapproving your app if they thought you stepped over the lines, but they wouldn't be directly affected by it so its unlikely they would do anything more than that.
Recently I've heard that Apple is using tools to search for references to undocumented APIs and are rejecting iPhone apps from the App Store because of it.
The popular Three20 framework is causing people to get rejected.
I also just saw that the KissXML library has also caused rejection.
I'm looking for an Objective C DOM-based XML parser and am now considering TouchXML.
Can anyone confirm that TouchXML does not reference any undocumented APIs? I don't want to risk an app rejection based on this.
I can confirm that I've included no private frameworks in several projects that use TouchXML that have all become apps in the App Store. I would ask the question at the google code site to make sure, but John Wight who wrote the library writes very clean and tight code. It would surprise me if he used any undocumented APIs.
Also, I wouldn't worry about it too much. Build your app and submit it and if it gets rejected, fix it then. Apple will even tell you what API you're referencing that you're not supposed to if that is the case. If you have to go through their bureaucracy anyhow, you might as well benefit from it by making them tell you what's wrong. Also, keep in mind that probably everyone gets rejected at least once--especially if it's your first app. ;-)
Tidy does. My app was just rejected from the app store on that basis.
"3.3.1 Applications may only use Documented APIs in the manner prescribed
by Apple and must not use or call any private APIs."
The following non-public APIs are included in your application:
tidyBufAlloc
tidyBufFree
tidyBufInit
tidyCleanAndRepair
tidyCreate
tidyOptSetBool
tidyParseBuffer
tidyParseString
tidyRelease
tidySaveBuffer
tidySaveString
tidySetCharEncoding
tidySetErrorBuffer
tidySetOutCharEncoding"
I know that there is at least one app on appstore which uses TouchXML. But during development process I found some bugs there, so I try to find some alternative now.
Consider using libxml2. It has a steeper learning curve, but the speed and flexibility are worth it.
I've just had an app rejected precisely because it uses touchXML