Is it possible to build a static library using MonoTouch that can be used by Xcode developers? What about the headers?
I come from a C# background and I have a large library to port over to iOS.
It'd save me oodles of time if I could keep it in C# and adjust as needed.
AFAIK it is not possible. See here:
MonoTouch: talking from Obj-C to MonoTouch
Which links to a project that tries to do what you want:
http://www.guidebee.biz/forum/redirect.php?fid=16&tid=176&goto=nextoldset
Related
Recently, I decide to make a framework for login module. I add the image resources to the framework, but I could not get it by code. I change the build the setting. mach-o type static library into dynamic library. I can get the image.
It is easier to make a moudle with dynamic framework than static framework.
but I google and find the dynamic framework made by developer is different with the Apple's dynamic framework. the app contain custom dynamic framework can not upload to Appstore ? Is it true?
who can answer my question? Thank you so much!!!
Dynamic frameworks are extremely common in AppStore apps. What you're probably seeing in posts is that you cannot manually load frameworks at runtime on iOS (i.e. there's no access to dlopen). They all have to be loaded at link time. You also cannot ship "shared" frameworks, where multiple apps share a single copy (like Apple's system frameworks). Each app must contain all of its custom frameworks.
But you can certainly ship dynamic frameworks in your bundle.
I have a npapi plugin(bundle) for chrome, which use C++ and objective-c. now it needs to be build by google native client.
I wonder that can nacl support objective-c? how to compile o-c file by MakeFile
And if possible, how to build nacl plugin in Xcode? I tried, but i found that the libraries of nacl are " archive with no architecture specification".(use lipo -info *.a)
I hope someone to help me, thanks a lot!!!
If you use Objective-C without any of its usual libraries then you should be able to use the PNaCl toolchain (which is based on LLVM) to have it parse Objective-C. I'm not aware of projects that have done this, so you should definitely let folks on the mailing list know if you get something working (do keep the questions on SO, though!).
It sounds like your application won't be running on the open web (where only architecture-independent PNaCl can run, not NaCl), so you could either use the PNaCl toolchain to create a .pexe, or you could use the same toolchain to create a .nexe for each architecture you target. The documentation I linked to helps with both approaches, but note that using the PNaCl toolchain to create a .nexe is currently being improved. You can therefore follow the instructions on the bug tracker, or try out nacl-clang when it's released (or build it yourself if you're brave).
This question already has answers here:
How do third-party libraries work in Objective-C and Xcode?
(4 answers)
Closed 9 years ago.
I am from a Windows background and I am used to creating SDKs by creating (.dll)s and then distributing all the libraries and Documentation.
So, if a user wants to use it, he adds a reference to the library and uses it. However, in a Mac, I am working on a SDK and I want a way of creating and distributing Mac libraries.
(I want to create the library in Objective-C)
Please help me :)
If you're creating a Mac library, you have either the option of creating a dylib, which includes only the compiled binary for the library, or creating a framework, which includes the compiled binary as well as headers and other bundle resources used by the library, in a single package. Frameworks are the preferred method of library distribution for the Mac.
If you're creating an iOS library, iOS doesn't support dynamic libraries of any kind (no dylibs or frameworks) so you're stuck with creating static libraries to distribute your code.
Both Mac and iOS have Dynamicly Linked Libraries. They just are not called that. They are generally just referred to as Shared Libraries and they typically are wrapped in Frameworks.
Unfortunately, iOS limits the use of Shared Libraries to System Libraries and does not allow installing shared libraries on non-jailbroken devices.
Both platforms also support Static Libraries.
I have a static library base on MapKit.framework CoreLocation.framework etc.
I want to distribute the static library to other developers, to make it easy, I hope to find a method to eliminate the process of linking against frameworks in developers project.
I know there are some people achieve this.
If you can read chinese, you can refer to
http://dev.umeng.com/releasenote/releasenote_ana_ios.html
简化SDK集成，一句代码集成友盟SDK([MobClick startWithAppkey:]),不再需要手动link framework
There is no way to do this as of Xcode 4.5.2. A static library cannot specify its dynamic library dependencies. Only a dynamic library can do that.
I'm creating a modular open-source library. Let's say the project has 15 .m files in it.
Should I (1) release it like the Venmo iOS SDK (Cocoa Touch Static Library) or (2) release it like JSONKit (just the source code)?
Releasing as source code means you, and your developers, don't have problems when a new architecture comes out. A static library built as armv6 wouldn't work with the latest Xcode today.
One caveat with source code releases, since you don't know what build settings the project it's added to will have, you'll need to do extra work to make sure it builds without warnings as best you can, even for pedantic warnings.
I prefer frameworks over static libs. Its easier to ship resources in the framework bundle if you eventually need to and there no cost to dynamic linking. If its pure C and the libraries dependencies are guaranteed to be there then it might be ok. But in general I try to avoid static linking unless I know the target OS has the exact dependencies for that binary at deployment time.
Its much easier to load a dynamic library with the endpoints you need at runtime (which were compiled for that exact platform but have the same external interface) than it is to fail with a static lib that was compiled directly to external dependencies which dont exist on the target platform.
Maybe Im crazy but this is what Ive always done in C, C++ or obj C. Just my opinion.
http://en.wikipedia.org/wiki/Static_library