I want to use the ffmpeg library (and maybe others) in my iPhone App.
But I have absolutly no idea how I can use the files that are in the downloaded zip, and get them to work in my XCode project.
I read something about .a files and frameworks. Maybe you can give me a description how to implement it?
1st, you're not allowed to do anything with open-source on apple market : basically, any open-source library tainting your code (thus GPL, but also LGPL as dynamic linking is forbidden) will have your application removed if spotted. The VLC case (removed from app store) proved that GPL is not compatible for app store license (look for app store and gpl and google and you'll find hundreds of links)
Second, you have to transform the code you received (say source code) into a static library (a .a file). To do that, you need to compile it, here you have basically 3 solutions:
put all the files into your xcode project and tweak until it works (thus not creating static library, directly merging the code with yours) : this seems the easiest, but will be a nightmare in terms of maintenance (each time you'll want to upgrade the statuc lib)
compile externally, by hacking the makefile to use the correct compiler (the one in for ios, in iphone platform folder)
add a subproject in your xcode project to compile the library
My advice goes for 2 (that's what I do with boost) but it's not a straight path
EDIT : don't forget that software video decoding will drain your battery and you might have poor performance
Related
The keyword here is possible. I know of a few resources that talk about this and how to create static frameworks - here: https://github.com/kstenerud/iOS-Universal-Framework and here: http://db-in.com/blog/2011/07/universal-framework-iphone-ios-2-0/
I'm interested to see if it's possible to create a dynamically linked framework in an app that will not be submitted to the app store. I know it's impossible to write to the application bundle on a device without jailbreaking it. Is it possible to say, download a compiled framework file, put it in the documents directory and then access it via the application (think plug-in architecture). I know that if it is, you would be turned away from the app store for submitting it, but let's say this was an enterprise app, or an ad-hoc distributed app where Apple would not have to approve.
In my initial research I haven't found anything supporting that it is possible, but I feel like this may be such a fringe case that no one has published anything about it. Looking for a guru to give me a definite "no" before I give up.
not sure if this is what you are after but according to Apple there dynamically linked libraries even usable in iOS - for example the system libraries... XCode contains copies of them and references them via symbolic links...
see near the end of this http://developer.apple.com/library/ios/#documentation/Miscellaneous/Conceptual/iPhoneOSTechOverview/iPhoneOSFrameworks/iPhoneOSFrameworks.html#//apple_ref/doc/uid/TP40007898-CH6-SW3
just an idea:
put the .dylib + include files you want to use into the respective folders where XCode expects the system libraries... use themn and then put symlinks into your bundle on deployment... let the symlinks point where ou copy the .dylib
I believe the answer is no. Apps on the iPhone are sandboxed. That is, aside from Apple supplied frameworks, an app cannot access anything outside of its own build.
This is possible now with IOS 8 Xcode 6.
I noticed that there are different requirements for each platform here. I was wondering if it's possible to build a single project but with multiple targets where each target is Mac OS X (something like a CD / install build), Apple Mac Store, and iOS device.
IfIi'm going about this the wrong way then I'd love to know! I mostly develop on the PC but with the state of the App Store I'd love to spread out as much as I can!
Keeping separate targets for the Mac app store and an independently-distributed Mac application is simple. You just need to ensure that your receipt validation code is conditionally included on the app store target and not in the other target; and your custom licensing scheme is included the other way round. Things get a bit more complicated if you target different operating systems in the two targets, but they're not insurmountable: you can test for the existence of classes or selectors at runtime to ensure you never call newer API on older systems.
By the way, it's also worth having separate Info.plist files for these targets. Partly because you don't need or want to include things like Sparkle properties in your app store target, but also because each target should have a unique bundle identifier. The app store does odd things when you have an app installed that it thinks came from the store but really didn't, and you don't want to risk your updater or Apple's trying to update the app deployed via the other mechanism. But that's not really about organising your Xcode project, it's a deployment issue.
For the most part, yes. All Mac/iOS apps can be written in Objective-C and the code is very similar. However, you must bear in mind that iOS devices have different screen sizes from the Mac and even from each other. That means that the input metaphor is different, and that the UI is different. While it is possible to do what you want, it's not advisable to just code once and compile thrice.
That said, I don't use Xcode 4 so I can't tell you about that. Of you are looking to do different builds for different devices, you will want to write your app logic and your input logic as separately as possible. Then, you create multiple targets, one for each build. You define compiler flags for each target. In your code you will use those flags to use the appropriate code for your build.
At least as of 3.2.5, this is absolutely not a problem. You won't necessarily be able to apply all of your build settings project-wide, but you can specify them on a per-target basis.
Just add the appropriate-type target (Cocoa Touch, Cocoa, etc.).
I have an Objective-C iPad app I want to build an opaque static library from so I can give it to testers using X-code to test without giving them the source code. How can I do this?
Use a "Static Library" target. Add your source to the target, and build. Since Objective-C is compiled to machine code, the resulting library is binary only. That said, Objective-C binaries are not as difficult to dig into as C++, for example. Since Objective-C uses runtime dispatching, many symbol names are retained. Using classdump at the command line, users will still be able to at least learn the classes and selectors in your binary. If this is unacceptable, you will have to consider writing the library in pure C (I discourage you from using C++ since it would require clients to use Objective-C++ just to use your library).
Objective-C is compiled, so just compile it and then distribute the binary.
If you want the recipients to be able to test on both a device and the simulator, build a fat library. I liked this article on fat binaries.
A static library is not very useful by itself. You will probably want to copy your entire project, remove all headers and sources except main.m and add your static library. That way all the resources, frameworks, and build rules will remain in tact. Then send along the library, project, and all resources.
Unless there is a specific reason why you would want testers to access your application through XCode, you can instead build a binary for ad-hoc distribution that can be installed on up to 100 devices. Check up "Ad Hoc Distribution" for the iPhone.
When I get a 3rd party static library, I can use it in my debug or release builds for both the simulator and device. However, when I build locally, it is targeted for debug simulator/device or the same for release. I then have to coordinate my host app to match the library build. How can I create a single static library build that works with all build versions of the host app like many 3rd party static libraries do?
I don't think there's a "magical" solution for the iPhone for this.
I once looked for the same thing didn't find any "easy to use" solution.
Best I could find :
http://www.clintharris.net/2009/iphone-app-shared-libraries/
Especially the part regarding "Fat libraries", that refers to http://latenitesoft.blogspot.com/2008/10/iphone-programming-tips-building-unix.html
But the MAKE configuration doesn't look easy (at least for me).
The way I do it :
I build the static libs separately for all configurations I need (simulator x86 debug, and device arm debug for instance). This gives me two different .a files.
I renamed them mylibrary_arm.a and mylibrary_x86.a
Then, for any project that wants to use those 2 libraries, I drag and drop THE TWO .a FILES into the client project that needs the .a library + the .h headers that will enable the use of those libraries.
Then, when I choose simulator or device in this client project, the compiler chooses the right .a AUTOMATICALLY to compile and run properly .
So in the end, the only boring phasis is the generation of the .a themselves, but the use of them is quite easy and XCode adjusts itself automatically.
I am trying to use the PLDatabase framework in my iPhone app. I've added the framework to my Xcode project. However, when I run my app, it crashes with the following error:
dyld: Library not loaded: #loader_path/../Frameworks/PlausibleDatabase.framework/Versions/A/PlausibleDatabase
Referenced from: /Users/todd/Library/Application Support/iPhone Simulator/User/Applications/BB3C66B2-A5BB-4329-B163-AB0072411AF1/Congress.app/Congress
Reason: image not found
I'm not sure exactly where the Framework needs to reside on disk to be found.
Thanks
iPhone does not support dynamic linking of embedded frameworks. While you might be able to finagle the simulator to work, it will not work on the device. If you want to use the code you must build the static library for the framework (libpldatabase.a), and then link them to the app.
The Xcode GUI does not provide a nice interface for static linking, you will need to add appropriate flags in your build prefs (-lpldatabase -L/whatever/dir/it/is/in).
It's not actually strictly true that the iPhone doesn't support dynamic linking. What is true is that applications installed by the App Store are unable to dynamically link.
The app store / ituned installs programs into the /private/var/mobile/... directory. Any program opened that lives in that subdirectory is chrooted and has certain rights stripped away when opened. The chrooted processes can't fork, they can't run in the background, they can't load dynamic libraries and they can't save files outside of their little protected areas of the disk (with the exception of photos to the photo directory).
That said, the iPhone runs a modern operating system that supports dynamic linking just fine. The act of 'jailbreaking' is actually installing a program outside the chroot jail that can then do things like fork and save files to other places on the disk and load dynamic code.
Apple (and the open iPhone community) has plenty of programs running on the phone (such as the MobilePhone, Mobile Safari and SpringBoard applications) that can run in the background and load libraries. They are placed in a different place on the disk (/private/var/stash/Applications often).
So... if you want to sell your app in the app store, you can't load a dynamic library. Which for most people means you can't load it at all. But if you want to distribute your app through cydia (a common jailbroken phone app installer), then you can get away with jailbreaking the phone and loading your dynaamic library. In fact, due to the itunes install process being the culprit, as you've learned, you cant even load a dylib from your own app that you write to you own phone... unless you jailbreak.
RE #mipadi: ZeroLink was removed in Xcode 3.1 and does not exist for the iPhone SDK. The correct answer is Louis'; the iPhone does not support dynamically-loaded frameworks in developer-created applications.
Xcode does have a good user interface for static libraries; just drag them into the project and they're added to the link phase. No need to fuss with linker flags. The problem comes when you need to use the headers supplied with those static libs (then you need to add the header search paths manually) or when a static lib conflicts with an available dylib (that's when you have to add the -l flag manually).