Are there any legal problems using external crypto libs in my iPhone application? I know that Apple has to comply to US cryptography export rules but do I as a developer have any responsibility? How does it work?
If you use encryption in your app for anything other than authentication, then you'll need to declare it to Apple and you'll need to explain exactly what is encrypted, why, and how.
I think that's pretty much the most of it. It's then down to the export masters (I have no idea who actually manages this stuff) to decide if they will allow your app to be sold/distributed outside the US.
Related
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.
Is it possible to incorporate one iPhone app into another in order to redistribute it?
We're going to publish few apps owned by other developers and need to create some pre-rolls with our branding and some other similar features. The original developer could build the app for us, but won't provide us with a source code.
Sorry if the question sounds stupid, we haven't very big experience in the field, just need to clarify some things
Thank you!
No you can't. You are only allowed to execute your own app, you can't embed an other app in your bundle.
It is not possible to embed an app into another app, or better, you could do that, but Apple would reject it and anyway you would not be able to launch it on a non jailbroken device.
More to the point of your specific case, if you have only the binaries you could try and modify the resource files (i.e., .nib and .strings files) to modify the UI to some extent. Of course, you would then need to regenerate the signature for the app (and hope that everything works ok).
It's just a thought, but maybe you could include the other developers apps as static libraries. The advantages would be that the other devs wouldn't have to surrender their sources, you wouldn't face any code signing and bundle id related issues and including static libraries is perfectly safe.
The only disadvantage would be that the devs would still need to deliver the content seperately and they need to learn how to build a static library. An entry point for each app / each library to call it would also be needed, maybe even a small interface to allow the container app to learn about the individual apps status, to cancel them etc.
As I said, this is just an idea, there may be issues with that approach that I do fail to see right now. But maybe others can comment on this...
You might want to check out this link to learn a bit about building static objective c libraries.
Check apples Custom URL scheme, it might find useful for you. Just help=> http://iosdevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html
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).
Apple doesn't want anyone to create iPhone apps outside of the Xcode/Objective-C environment. How can they actually enforce this?
If the non Xcode IDE, for example Unity, compiles to an iPhone executable, how will Apple know which dev environment you used to create the app? Can they have Xcode compile some sort of signature into the executable that no one knows about?
For tools such as unity, corona, flash, and other platforms used to 'generate' iphone apps, Apple may be able to 'decompile' and examine your app (look at patterns of generated functions, etc). From this, they might be able to guess that your app was generated with such a tool.
In the limit, this is impossible. Consider the following: I write some script code to generate a bunch of objective-c code. Then I manually import the objective-c files into xcode and build the app. How would apple be able to distinguish the script-generated code from human-written code? Maybe I just tend to write code that happens to look machine-generated. There's no way for apple to determine whether the code was "originally written in objective-c, c, c++ or javascript" or not, yet this would still, technically, violate the agreement. That's why the 3.3.1 part of the agreement is nonsense.
Most automated systems do things a particular way, which isn't hard to detect. If you've ever looked at the PHP or JavaScript code Adobe Dreamweaver generates, for example, you know how easy it is to find stuff like this.
Apple is doing this to prevent people from using Adobe's Flash development framework. It should also be noted that Apple's decision to limit Application Frameworks like this is causing the DOJ/FTC or some government agency to start an informal inquiry into monopolistic practices.
From this article:
"According to the Post's Hollywood source, Apple's ban of Adobe's Flash technology on the iPhone and iPad is what prompted the government to poke around. "
They really don't have an issue up until now with other frameworks because Adobe didn't have one based with the Flash environment. Now that there is one, Apple is going to restrict anything that talks/looks/smells/acts like an Adobe Flash app on the iPhone. In my opinion, they won't do anything to other frameworks, but they'll enforce the rule just for Adobe. Which brings up the whole monopolistic practices thing.
I believe that many of these translator tools have some kind of common runtime function library which take care of the portions that could not be translated 1:1. Those function could then be pretty constant regardless of your application. That way there would be no real need to decompile the app. but instead just look for usage of those function signatures.
FWIW I find the whole idea of limiting user's choice of tools is a bad move.
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.