What i am trying to do:
Trying to develop an Enterprise level IOS application with FFMPEG for video Processing.
What i have done so far:
Created a Linux based sample program with FFMPEG and made it work. Learnt how to use FFMPEG. I have already found the build instructions to build the FFMPEG packages
for IOS.
What help i need:
Does apple allow to place the FFMPEG based application in IOS Application Store?
As there is no official support from ffmpeg community for IOS, how reliable the "FFMPEG-IOS" is, as i don't want to get into any problems in future especially when apple releases a new version of os or the problem of ffmpeg only with IOS?
I believe several users here have apps in the App Store that are compiled and linked with ffmpeg. I personally am going to submit my app within the next month. I anticipate that it will be accepted.
For iOS, you cannot dynamically link. You must statically link. Therefore, the ffmpeg libraries will be part of your app. It would be highly unlikely that a future iOS update would break the code. Your app is more likely to break for some other reason unrelated to ffmpeg, e.g. a UI change, that Apple makes.
The requirement for static linking means that you must understand the ffmpeg licensing situation carefully. I am not a lawyer, and this is not legal advice. You should consult a lawyer for real legal advice. Some people interpret the LGPL to mean that static linking is OK as long as you do not modify the ffmpeg source code and you distribute the ffmpeg source code (e.g., provide it for download on your server) as well as the static library (.a) files used in building your app. You must also credit the ffmpeg project for your use of their code. More information: http://ffmpeg.org/legal.html
Related
My iOS app is developed in swift. It contains some cocoa pods and other trusted third party frameworks. Build is stable and in running mode. Now when security official has done a security assessment on the app they have come up with above mentioned issue. The app was shared in installable forms and somehow they have used some tools to analyze the app(though ipa was not shared directly tool raised this issue in app ipa, tool is unknown here).
Now when I search for above mentioned API's as keywords in the whole project , I don't find its usage. Can anyone help on this , on how to trace if our code / other libraries are using these API's or not, if using , how one can rectify its usage?
It is very likely that some or one of the 3rd Party lib/s used in the project are possibly using those API's. Please do insure that the app is using the latest release of the lib/s and it may be worth while to contact the lib developers so see if they have addressed such issues in any release. To get a better perspective please go through the secure coding guidelines from Apple with respect to Buffer Overflow / Underflow
I tried to get answer to my question searching among other questions already answered but I did not.
Actual, my question is very simple:
I am trying to integrate third party frameworks to support Ads in my iOS app (AdMob by Google e MoPub). What I can see is that these framework are really huge (>10MB each one). So, I guess the final app size will be very large, also for a trivial app. How can I handle this. I think this is a common situation. Am I missing something in integrating third party frameworks? How do you handle Ads integration in your apps? If you want to have AdMob and you download the latest GoogleMobileAdsSdkiOS-6.12.2, it weighs 13.4MB!
I hope my question is clear enough.
Wait for answers, thank you very much.
Have you tried to make a Release build (e.g., by using the Archive command) of an app that links those frameworks and check the final size?
When the app is built for release, all debug information and other symbols that are required for linking are stripped out, so the binary size will shrink a lot, usually.
Be assured that a release build will be much smaller than a debug build and that the debug build will be smaller than the sum of the individual binaries that you are linking together. You could go, in specific cases I am thinking of, from 200MB pre-link to 2MB after linking in release mode. Generally speaking, unless you have many images or other kind of media bundled with a library, the size will not be a great concern (compiled code shrinks a whole lot) -- but there is no other way than linking the library and see what the linker comes out with to know the real size...
I was trying to get the header files from the ToneKit framework on iOS7.1, but I found that I cannot use class-dump because there are no executable files inside the framework. From what I have found after some research, it seems as if the actual executable file is inside the dyld_shared_cache on the device. After reading this article, it seems as if there are some tools to decrypt the cache, but since iOS 3, Apple has implemented ASLR which has made the decryption tools not work. How can I extract the Frameworks from inside the dyld_shared_cache on iOS7.1?
I am very new to jailbroken ios development so please bear with me.
If you're interested in how they got those headers then the answer is very simple - iOS SDK. SDK contains ARM binaries of public and private frameworks because they are required to compile iOS applications. Class-dump them and you will get headers you need. ToneKit.framework binary is also in there.
Usually you don't need dyld_shared_cache, almost everything you need is either in iOS SDK or on a device itself like SpringBoard, other system applications etc.
Of course there are rare cases when dyld_shared_cache is the only place you can find certain binaries as they are missing from both iOS SDK and device. In that case I use IDA. It has free demo version that can open dyld_shared_cache files - you can even open individual binaries inside it rather than dump everything. You just need to copy dyld_shared_cache on your PC.
I think Elias Limneos's classdump-dyld can help you. If not, check out RuntimeBrowser. Failing that, even, weak-classdump has proven to be a very useful runtime tool for me.
The library can be found here:
http://lpsolve.sourceforge.net/
The demo code on the site shows them doing a #include "lp_lib.h" and then making API calls to the library.
My question is: how do I get the various .so files that the site provides in the download of the library into a format and into xcode in a way that lets me include the .lib and make API calls to it?
Compiling lp_solve for the armv7 architecture is incredibly difficult and has gotten the better of many talented people. I say this because the above answer makes it seem like if you follow the instructions closely enough you will be able to compile, then drag and drop.
I would use GLPK which I got to work on iOS. https://github.com/wisaruthk/MyGLPK.
The gentleman that compiled this package for iOS initially attempted to do it for lp_solve, but could not get it to work. This package will allow you to do a proof of concept, but infects your app with the GPL license. If you want to put your app on iTunes, you'll have to figure out how to get your hands on a commercially friendly package.
AlgLib is the cheapest commercially available library, but it does not have mixed integer programming. Other solutions Gurobi, Frontline Solver, NAG, Rogue Wave charge in excess of $5,000 for a developer license and will cut you a deal at scale to only charge your users $350 for a run time license.
In iOS, you cannot use dynamic linking, i.e., you will have to link lp_solve statically. The docs have instructions on how to build the static library here.
When you're done compiling the static library, simply drag'n'drop the resulting .a file into the project and add it to the linking step of your target. That should be it. However, since lp_solve is LGPL-licensed, pay attention to licensing issues, see here.
So on iOS Apple won't let you release an application that has a dynamic library (dylib). (Xcode won't compile it although there are workarounds, and the app store won't approve it.)
We have an SDK that we are currently moving from Windows to iOS. On Windows, we statically link all of our dependencies into one dll, so we only have to provide 1 file to anyone using the dll, so we don't have to publicly release all of the libraries that we are using and to keep the size of that file small, since any parts of those libraries that we aren't using get compiled out.
On iOS, since it's not possible to release an application that loads a dynamic library, we would be forced to ship a framework or something like that, which includes all of the libraries that we link against. The developer consuming our sdk would then compile our lib with all of its dependencies into their application.
This would let anyone using our SDK know what libraries we're using and would increase the size of our deliverable, since it would have to include full version of all the libraries we're linking against. (At least with a framework we would still only be providing 1 "file".)
Is there any way that Apple allows to avoid letting everyone know what libraries we're using?