My Question is about private framworks in IphoneOS3.1SDK dirctory
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/System/Library/PrivateFrameworks/
What are they ? and when i added one of them to my project, they didn't have any headers?
How can i use them in my project?
Private frameworks are frameworks which you are not allowed to use. They are not expected to be used outside of Apple, hence "Private". They are often lower-level libraries which may "break" the system if not used correctly. (But the frameworks have to exist because Apple's apps and public frameworks do use the private frameworks.)
Since the private frameworks are not for public use, Apple doesn't need to give any headers or documentations away.
If you're writing for AppStore, you should not use private frameworks (unless you're from Apple). The system will immediately reject your app even before the review process begins.
(On the other hand, for jailbroken platforms you're free to use any frameworks. Even so, the APIs of private frameworks is unstable, that you should avoid them if possible.
There is an ongoing effort to document these private frameworks and API in http://iphonedevwiki.net/index.php/Main_Page.)
Avoid using private frameworks if you would like to submit your App to Apple. Otherwise, you may call any of the available private methods with your own code. Erica Sadun has some info regarding private frameworks on her site.
While the other answers are generally true, there is one small exception that deserves to be mentioned.
There are some cases where certain contents of private frameworks (besides code libraries there are often databases and similar binary, non-executable files inside them) can be used (bundled) in App Store apps. One such example is the RMPhoneFormat class from #rmaddy, which uses "a copy of an Apple provided private framework file named Default.phoneformat". The author (no doubt other developers as well) has used this binary file in App Store apps without problems.
(I don't know whether this is due to the fact that Apple tolerates this practice, or that they just don't check for this type of usage in their approval process.)
Related
I've read several articles about this, and I just want to see if I understand this correctly:
Apple will reject your app if you use a Private API...
What is the main difference between a "Private API" and a "Non-private API?"
Are the "Non-private" APIs only the APIs provided and verified by Apple?
Isn't an API just a way of interacting with a Framework, and a Framework is just a set of encapsulated classes/headers that people can use for trivial purposes?
Wouldn't this mean that I cannot reuse anyone's code (other than Apple's) at all in my app?
If this is true, whenever a programmer makes his or her own custom classes and methods, isn't he technically designing a mini Framework just for his specific purpose? So wouldn't this mean that he is using his own private API?
What would even be the difference between using someone else's classes/methods alongside my classes/methods, how could they even tell the difference, and why would this be a problem?
My understanding of this sounds absurd, and don't believe I am understanding what a "Private API" is correctly. I did read that it was to protect against any changes in the API that could render your App dysfunctional. Does this mean APIs are linked during run time (as opposed to compile time) and can be updated automatically without you knowing or something? (See, I was originally thinking of APIs/frameworks as being set in stone whenever you compile, maybe this is where I am wrong)
Can someone please help me out? I'm really confused about this policy. Thank you!
Q. What is the main difference between a "Private API" and a "Non-private API?"
Private is one that isn't publicly defined (there isn't much to it)
Q. Are the "Non-private" APIs only the APIs provided and verified by Apple?
Private and Public APIs are both 'provided' by Apple but only public APIs are provided for you to use.
The private APIs are for use by Apple only
Q. Isn't an API just a way of interacting with a Framework, and a Framework is just a set of encapsulated classes/headers that people can use for trivial purposes?
Yes
Q. Wouldn't this mean that I cannot reuse anyone's code (other than Apple's) at all in my app?
No
Q. If this is true, whenever a programmer makes his or her own custom classes and methods, isn't he technically designing a mini Framework just for his specific purpose? So wouldn't this mean that he is using his own private API?
No (a framework is different to an app)
Q. What would even be the difference between using someone else's classes/methods alongside my classes/methods, how could they even tell the difference, and why would this be a problem?
It usually wouldn't
The point you need to get is that when referring to private APIs you should only be thinking about private Apple supplied APIs.
Other APIs from 3rd parties are different (and Apple doesn't care so long as that 3rd party code doesn't use Apple private APIs).
I want know about how to create dynamic library frameworks for iphone..
Any ideas about this..please guide me...
Dynamic linking is forbidden if you want to deliver to the App Store (apart of the Apple provided libraries and frameworks, of course). Only static linking of external libraries is allowed by Apple.
Edit: (quoting myself from a comment to a different question) The reason is security: since a dynamic library can be loaded and unloaded at runtime you could download additional executable code and load it (think plug-in). This could get compromised by a hacker and then having malicious code executing on your phone is a very bad thing. It would also make it possible to add unapproved features to an approved app. In short: in this environment, Apple considers dynamic linking to be a Pandoras box that must be strictly controlled, otherwise it could compromise security and I agree that it does make sense on the phone.
This simply isn't supported for various reasons.
Use static libraries instead, or compile the source directly into your project.
Is the built-in dictionary in iBooks etc available to developers? If so how would I go about using it?
It's not available to developers. You could use an open source dictionary like this one from Project Gutenberg, but it might take substantial munging to make it presentable.
Unfortunately, I believe the system dictionary is only available through a private API.
Personal conjecture: It's one of the many "features" locked away by Apple to separate the iBooks app from 3rd party e-book reader competition. However, at the rate Apple is going, I would expect the API to become public at some point in the next few years.
I think that it might be a copyright issue. I had the same problem about a year ago and not much has changed since then.
My solution was to embed an offline dictionary inside my app and I later turned it into a static library that others can use (for a small fee). If you're looking for a full-blown dictionary you can check it out at www.lexicontext.com
If you just need a spell checker, you can also use UITextChecker
I haven't found a comprehensive list of the steps that are required to use a private API from the iPhone Library.
In particular, I would like to know how to get header files, if they are even required, how to get it to compile (when I simply add the header, it complains that the functions aren't defined), and what resources one can use to learn about private APIs (e.g. from other user's experiences, such as http://iphonedevwiki.net/ which has a few).
I've read in other places that people recommend using class-dump to get the headers. Are there any alternative methods? I've noticed that there are some repositories of iPhone Private SDKs, what are the most up to date resources you would recommend?
Most of the previous questions about documentation of private APIs, have all linked to Erica Sadun's website, which doesn't seem to have documentation anymore (all the links on the left are crossed out).
Please save the comments about not using private API's... I know of the biggest risks:
App will get rejected by Apple.
App will break in future updates to the OS.
I'm talking about legitimate uses, such as:
Private application use (e.g. for unit testing, or messing around to see what's possible)
Objective-C has enough information in the compiled binary to almost completely reconstruct the headers. The only things missing are argument names, which can often be approximated from the type or method prototype, and some structure and enum definitions. That is why programs like class-dump are the best way to get the headers. They are comprehensive, including every method whether it was in the real header or not, up to date and do not need to be distributed. The other way to get headers is to look in the public version of the same framework, for example WebKit is only private on the iPhone and is otherwise well documented.
If you are interested in things besides Objective-C you pretty much have to do it the old fashioned way, slogging through disassembly to guess function arguments. Once you get a few symbols, search for them and maybe you will find a header someone else has posted. otool is a good place to start.
If you include the headers, be it for Objective-C or C, you must also include the frameworks or libraries the headers declare methods for, just like any other headers. Most of the Objective-C stuff is in a PrivateFrameworks folder right next to the regular Frameworks folder. You can look in the usr/lib folder to find libraries.
Be aware that there are lots of differences between the simulator and the device, so make sure you build headers from the real device. There are also some of methods that you will not have permission to run as a sandboxed app.
I received the following mail form Apple, considering my application:
Thank you for submitting your update to Νομοθεσία to the App Store. During our review of your application we found it is using private APIs, which is in violation of the iPhone Developer Program License Agreement section 3.3.1; "3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs." While your application has not been rejected, it would be appropriate to resolve this issue in your next update.
The following non-public APIs are included in your application:
u_isspace
ubrk_close
ubrk_current
ubrk_first
ubrk_next
ubrk_open
If you have defined methods in your source code with the same names as the above mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged with future submissions.
Please resolve this issue in your next update to Νομοθεσία.
Sincerely,
iPhone App Review Team
The functions mentioned in this mail are used in the ICU library (International Components for Unicode).
Although my app is not rejected at this point, I don't feel very secure for the future of my app, because it relies heavily on the Unicode protocol and on this components in particular.
Another thing is that I do not call these functions directly, but they are called by a custom 'sqlite' build (with FTS3 extensions enabled).
Am I missing something here?
Any suggestions?
I would recommend not publicly venting about the issue (that will only hurt you in the long run), but responding politely to the application review email address you were given, explaining that you are using a custom SQLite build which references the ICU framework. Given that this is a standard third-party framework, I would argue that these are not Apple's private APIs that you are using. It may be that they were simply overzealous in the inclusion of symbols in their scanning software.
If you are unable to convince them otherwise, you might contemplate switching from SQLite with FTS3 to something like Aaron Hillegass' BNRPersistence, which just added fast full-text searching.
If they have trouble with linking to the system ICU, why not simply import the ICU source code into your project?
Hmmm...it is possible that Apple also uses ICU components. The best response would be to politely explain what's going on, and hopefully things should sort out okay.