In Xcode there are many frameworks (like mkmapkit.framework).
This framework contains only .h (header) files. Where can I find the corresponding .m (implementation) files.
The implementation files are not distributed with Xcode. Apple keeps them proprietary.
The framework classes are available as binary library files (.dylib, .a etc. for example). So .m which are implementation source files are not available. Header .h must be available as without header files compiling is not possible.
The only way to see the implementation is to decompile the frameworks static library with tools like those described in this question:
Decompiling Objective-C libraries
Since the frameworks you are probably interested in will generally have symbols stripped, it will be a bit of a task understanding what is going on but you can glean some things from tools like these.
You can find them inside Apple's internal source code repositories. If you work at Apple on an appropriate team, you can check them out. If you don't, then you're out of luck.
Related
I have a C++ library that is full of warts and weird features, and I want to make it much easier to use (and reuse) in a Swift project. So I intend to wrap this C++ library in some Swift code, then make it available as a Cocoa Touch framework.
I've added both my (fat) .a file and the required .h files to my project, then added the .a to the "Link Binary with Libraries" section of Build Phases, and added the main .h file to the Project section of the Headers build phase. But the build fails with:
Library not found for -lMyLib
I'm obviously missing something here - I'm guessing maybe I need to adjust the Framework Search Path and/or Header Search Path? Or am I missing something more fundamental? My desired end result is a .framework another developer can pull into their Swift project without having to do any other build setting tweaks.
You're probably looking for "Library Search Paths" (LIBRARY_SEARCH_PATHS). You may need to add to "Header Search Paths (HEADER_SEARCH_PATHS) as well, depending on your setup. In this case, you shouldn't have to add anything to the Framework search paths, since you are not dealing with a Framework.
(As an aside, you are likely going to find that you have to wrap your C++ library in Objective-C++ code to expose the functionality to Swift.)
I have RestClientLibrary and UserFunctionsLibrary
UserFunctionsLibrary needs RestClientLibrary in order to function.
When I compile these down to libRestClientLibrary.a and libUserFunctionsLibrary.a how will they be able to interact with each other?
In Xcode currently I have set the User header search paths to find the .h files and I have linked the UserFunctionsLibrary with the RestClientLibrary binary. However, when distributed other users of these libraries may have different set ups and such. I can't see that it will work.
Thanks for any insight you can give me.
Those .a files are just library files. They will need to be linked together to actually be used. The linker will handle resolving all the symbols from RestClientLibrary into UserFunctionsLibrary.
As far as other users, they will have to configure their system in a way such that both libraries are passed to the linker.
I m going through framework files that comes with iOS, like Twitter.framework. What i can see is that it all contains the .h files, where as i want to see the implementation files, is there any way to view them?
You can't, and in the vast majority of cases you should have no need to beyond your own curiosity.
The .h files are provided so that your code can link to the Apple provided API's. You don't have a technical need to see the implementation and Apple doesn't provide them presumably because they don't want you to see their implementation. There are valid reasons for this such as protecting their intellectual property and maintaining a certain level of security by obscurity within the OS components.
No, Apple does not supply any implementation files for their frameworks.
we cant see the m file of any frameworks.
all we can get is only .h files.
if the implementation's source files are not provided and a binary is provided for you to link to, then that is by intent. some libraries provide their implementations, and some do not.
I've been writing iOS apps for some time now and for this particular project, I decided that I needed a static library for code sharing purposes.
I've followed some tutorials in creating static libraries and everything works perfectly.
Now I wonder, is there any way of versioning the static library?
I couldn't find any files regarding version number in the static library project, nor any good search results (both Google and here) regarding this particular issue.
I think I could create some kind of "fake" Info.plist and store the version info there.
Is that the way of doing it? Any other approaches to the problem?
Edit:
I think I may have not been clear on my purpose:
I have a workspace that has both my library project and related projects using the library, which is imported using the .xcodeproj file, then configured the dependencies so it builds whenever needed.
I just need some way of versioning the library, so that I can include that in some sort of about box, just in case.
I think you should stay away from bundling binary builds of your own code. Unless you're building a really, really, really massive library, you're better off just importing the code in any of your projects, and rebuilding it each time. You can put it in a separate target though, so Xcode doesn't rebuild it all the time.
You might want to write a tool that takes version info in a .plist and writes it out as literal strings defined in a .h file, which you can then include in your own code.
To make it foolproof (avoid mismatch between the header and the library), define a class method like [YourLibraryClass versionString] that returns a NSString with the version number or signature.
I have some utility functions like:
void myVibratePhone()
{
AudioServicesPlaySystemSound (kSystemSoundID_Vibrate) ;
}
that I'd like to use across all my projects.
In C, I'd give each project the header file, and link in the .OBJ file (or perhaps create a library).
What is the Apple-approved recommended way to share code (cocoa and C primarily) among my apps? Would I need a framework for this? How would I go about creating one?
Also, since I'm using subversion for version control, if I use a framework, do I place the version of the framework that the app is using in the subversion repository for the project so that anyone who checks it out can build it straight away or make it a requirement that people check out a project + check out the utility functions also for a successful build of any project?
I don't plan on putting anything on the App Store at this time, but I don't want to do anything that will cause apple to not accept an app in any case.
I found this writeup about xcode 3.0 (I'm using Xcode 3.2.1):
How do I create a bundle of reusable code in Xcode?
I followed it, but am having one issue:
1) trouble finding my library .h file in the main project: I've tried both hardcoding it in the main projects .h file
#import "file://localhost/Users/piesia/Documents/My Utilities/MyUtilities.h"
as well as:
#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"
and
#import "~/Documents/My Utilities/MyUtilities.h"
I've also tried updating Header search paths in the Project Build settings:
"/Users/piesia/Documents/My Utilities/**"
when using #import
After a lot of trying (and replacing %20 with space), I was only able to get the variants
#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"
and
#import "../../My Utilities/MyUtilities.h"
but I'd prefer not to hard code the path if I can figure out a better way.
So, in closing, 1) is the writeup that I'm following the recommended way to do shared code in Xcode 2) is it recommended that I keep the shared files in a separate subversion repository from the main program and link and include it in as I'm doing now and 3) do you know what I'm doing wrong in my attempts at loading the shared header file? Would anything that I'm doing or not doing with shared code hurt my chances of getting approval if I ever decided to submit it to the App Store?
I agree with creating a static library to share the code.
To add the headers to the project you need to set the "User Header Search Paths" to the location of the .h files.
You then import the headers using something similar to:
#import "YourHeader.h"
You shouldn't need any additional path information in the import if the header search path is set correctly.
Oh this one is a bugger! - I think unfortunately the easiest way is to hardcode.
My team has dozens of reusable components in our products, many of them shared between Mac and iPhone. My experience in this is that most of the time it's much easier to just include the source code rather than to create a separate static library. The separate project for the library adds a lot of complexity and seldom provides much value. Here is how I usually approach it:
In subversion we have a directory tree like this:
/common
/Component1
/Component2
/Project1
/Project2
...
In Project1.xcodeproj, we just drag in "Existing files" from common into the tree (don't copy). Doing it this way avoids lots of overhead in managing another project. This does mean that changes to the common tree can break any of the projects. That means you need to recompile everything before committing (we use a top-level build script to check that you didn't break anything). The advantage of the static library is that you can stage this by upgrading the library for each project when it's ready. On the other hand, it means that you have to rev the library often and manage syncing it around. We've found that just sharing the code directly typically is much more effective.