Over the last few months I've come across various chatter of external/private libraries not being allowed in iPhone apps.[Just to be clear, this is not something thats going to come, its something I was wrongly under the impression that already exists.]
I was looking at the WunderRadio source: http://www.wunderradio.com/code.html
and I noticed they have 3+ .a files in there project.
libcCommon.a liblibmms.a and libffmpegLib.a are the ones I'm looking at.
Have I been misinformed about the use of this kinda of libraries in iPhone projects? Will Apple accept and approve projects that are using them? If so what is it thats not allowed? Is it just use of Apples own private and undocumented libraries, but you are allowed to include your own?
Many Thanks,
-Code
Static libraries have always been allowed for iOS development and there is no sign that position is going to change at any point (why would it?). Dynamic libraries are not allowed and will result in the rejection of your app.
I think they'd be crazy to do that.
There are so many 3rd party libraries out there that it would pretty much kill the developer crowd they've got now. Imagine if you had to write every library over, from scratch? That's nuts...
Of course, I have no proof one way or another. I just think they'd be insane to try and do that.
.a files are called static libraries. When you build your code, they essentially get compiled in at build time. These are definitely allowed by Apple. In fact, XCode provides a template for a "Cocoa Touch Static Library" when creating a new project.
.dylib files on the other hand are dynamic libraries and are not allowed by Apple. They are separate code files that can be shared by multiple applications as their code gets brought in to your app at run time.
Saurik (the guy who created Cydia) solved this issue by creating Mobile Substrate for jailbroken iPhones. It allows devs to create dynamic libraries in order to alter the functionality of existing Apple classes.
Hope this clears the issue up.
Related
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
This question comes from this other one I asked earlier: Calling custom Objective-C from a pyobjc application?
I want to re-use a small part of the app logic from my iPhone app in its server-side component, which runs on OSX. Based on what I was told in the other question, it looks like I need to compile a "framework" for both iOS and OSX from this little piece of app logic.
If we assume that I am able to isolate all the code that is to be in this framework into a single .h/.m pair of files that has no other non-Cocoa dependencies, what would be the easiest way in XCode to build this framework for each architecture and avoid double-coding all this logic on the server?
I tried adding a new OSX framework build target to my iPhone project, but this doesn't get very far and XCode bails out pretty quickly with:
target specifies product type 'com.apple.product-type.framework', but there's no such product type for the 'iphonesimulator' platform
Any help much appreciated, as I am currently dupe-implementing to keep things moving forward, but this is pretty obviously becoming a huge waste of time and source of errors when the implementations become slightly out-of-sync.
Depends on what you used in your custom class. If you did not use anything from UIKit / AppKit then the class is probably going to live well on either platform, otherwise, you’d have to use target conditionals and include separate code specially written for both platforms.
You can have multiple targets in one Xcode project, their Base SDK set separately for the Mac / iDevices.
Adam's comment to my original question answers this question. Although still interested to see if there is a way to do it all from a single XCode project, the solution I have now is plenty good enough for what I wanted to achieve.
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.
Is it possible to create an own obj-C Cocoa Touch framework which can be used by other developers? And furthermore can you protect this framework?
I've created templates for Xcode 4 that allow you to build universal iOS frameworks (which work in both device and simulator).
Once the templates are installed, you simply select "Static iOS Framework" when creating a new project and it does the rest. It also works with unit tests.
https://github.com/kstenerud/iOS-Universal-Framework
You can create a static library. There is an option in the XCode project chooser to do this. You'll have to distribute the compiled static library file and the header files to users of your library. Your actual implementation files (.m) do not need to be distributed.
GHUnit does a good job of this - packaging up the libraries for both simulator and device - so I recommend looking at this project. (I also recommend using this library for unit testing :-)
The frameworks in Objective C are typically just C / ObjC code and a bunch of classes, nothing amazingly special. As such, you can create your own if you'd like, and then just include that in your project when you build it. The iPhone doesn't care about the difference, it just knows to put all that code into your app, along with everything else.
Have a look at the Framework Programming Guide on Apple's website. It will get you started. Essentially what you'll do is create a Framework project in XCode and then go from there.
As for "protecting" your framework, I assume you mean making your code unreadable. I'm not sure if and how you can do this, but perhaps Apple's guide will say something about it.
Yes you can create frameworks for use with Cocoa Touch.
However there are these caveats:
has to be a statically linked libary, no dynamic loading (dyld) for us
should be a combined (lipo) library for i386 (simulator), arm6 and arm7
you need to hack a bundle project into a framework
you should embed (small and few) images into the library so that the developer does not have to mess around with resources but just drags/drops it into his project
... or if you have large and many images build a bundle with these
I have guides for these things on my site.
1+2 = http://www.drobnik.com/touch/2010/04/universal-static-libraries/
The other links you have to google because this site does not let me post more than one URL.
You could make a static library available as binary (i.e. rudimentary "protection") to third parties, but not a dynamic one, as Apple's App Store policy prevents dynamic linking.
Take a look at a worked example for static libraries given at
this site
If you're going to do it, in my opinion JSON.framework is a great example to follow. To hide/obfuscate the source code is a different story, and a different question entirely,
When creating a new project, navigate to iOS > Framework & Library > Cocoa Touch Framework, it's as simple as that. When you are successfully compile, .framework will be created under Products folder in XCode. Right click to show in Finder, and you can find the output.
It's unlikely this will work the way you want it to because the other developers won't be able to use your framework. This StackOverflow Question explains why.
Are there any tutorials describing how to create a library or is it framework for the iPhone? I have a number of methods that are shared between applications. These will be better maintained as a library.
Put your code in a static library (as Roger indicated via his link). However, consider using an Xcode cross-project reference to "import" that static library into all the other projects that need it. I've whipped up a tutorial explaining how to do this (and why I think it's better than creating a "fat" Universal Binary): http://www.clintharris.net/2009/iphone-app-shared-libraries/
There is a lot of information on the web that can help with this for example this.
A much more recent (and more powerful) way to do the "single library file that covers both simulator and devices":
Build fat static library (device + simulator) using Xcode and SDK 4+
(I wrote one of the posts referred to in the accepted answer; that was valid for Xcode3 at the time, but Apple deliberately broke it with later versions, and offered no alternative. So, we ended up with the SO question / answer above)