Our Xcode project contains a sub-project that builds first party frameworks which we use as our standard libraries. One is built for each platform (iPhone, iPad, watchOS,...) but there is significant overlap between them (extensions for example).
In our Objective-C code in the main project, I simply have a different prefix header for each target based on its platform, and I import the relevant framework header. This means in my entire project I can use all the symbols that are in our "standard library".
I want this to happen in our Swift code as well (for both Swift and Objective-C symbols). From what I'm aware, Swift doesn't have the concept of prefix headers, so I'm needing to import the framework/module manually in each file.
What's more annoying, my imports won't just need to be
import MyFrameworkForiPhone
But because of the platform specific frameworks, with the help of Swift compiler flags, they'll need to become
#if RD_IPHONE
import MyFrameworkForiPhone
#elseif RD_IPAD
import MyFrameworkForiPad
#endif
Does anyone have any suggestions about how to cleanly work around this problem, or am I stuck with this for the time being?
While it may not be advisable to have separate modules for different platforms, sometimes we find ourselves in this situation and have to deal with it. Fortunately, there is one way to shorten that boilerplate...
Solution
You could create a third module, perhaps called MyFramework that selectively includes the appropriate framework for the current platform. Such a module would only need one source file that looks just like your example above:
#if RD_IPHONE
import MyFrameworkForiPhone
#elseif RD_IPAD
import MyFrameworkForiPad
#endif
Then, every other source file would simply import MyFramework. This works because a module will re-expose anything public from other modules it imports.
Analysis
This approach also provides a sensible location for anything that the two platform-specific modules have in common. Shared code can move into this platform-agnostic module, helping you move closer to the ideal scenario.
Notes
If you're using Swift Package Manager, see the documentation on modules. It's as simple as making a new directory.
In Xcode, creating a module means creating a framework. See Ray Wenderlich's guide for an example. It references iOS, but the same process applies to other platforms.
I would strongly advise against creating frameworks designed only for iPhone or iPad. If there is any UI code It would likely make it impossible for an app to be resizable on iPad and there isn't any code that will compile for one and not the other.
Besides that, you're not compiling separate binaries for iPad and iPhone if it's the same app. Imports are done at compile time, so you cannot dynamically include different frameworks based on the device on which it's being installed.
If you have completely separate apps that only support iPhone or iPad (which should be avoided), you could add compiler flags to each of them to do different things with the same files.
[edit: oops, I answered the wrong question. This answer is for Frameworks that target multiple platforms]
The support for cross-platform frameworks is still pretty bad. In Xcode, I work as follows:
create a single source tree for my library
create subfolders for platform-specific stuff
if a class is implemented differently for different platforms, it appears in each platform subfolder (where it is supported at all)
Now create a "Target" in XCode of type "... Static Library" for each platform you want to support (I have WatchOS, iOS, and MacOS in mine). Name them differently, obviously. However, change the "Build Settings | Basic | Product Name" on every one of these static libraries to be the same, like "MyLibrary" for example.
for each source file in your library, tick the "Target Membership" in the file properties to select which the platform libraries that should include this file. Obviously, everything in the platform-specific folders should only be included in those platform targets.
for other platform-specific targets, add Library linking and Target Dependency for the platform-specific target, like "MyLibrary_MacOS" or whatever you called your library targets above.
Now you can have "import MyLibrary" in your source files and it will automagically find the one that is actually available on the platform that you are compiling. This way, you can have platform abstractions or platform-specific stuff in your library and it doesn't appear everywhere in the code, just like "Foundation."
I also add headers in there for MacOS to provide dummy implementations of WatchOS APIs that I need for testing, for example. That way, I can unit test code on MacOS.
No, this is not optimal, because a formal "Framework" compile would be better, but it is the only way I have found to do it locally with full debuggability.
If anyone else has actually used something that works better, please let me know. Please don't recommend something you haven't actually used :)
Related
I have some source code in C/C++. I have to make static library to use in my iPhone application. is there any third party tool to create static library for armv6/armv7 ?
this link will help you create a static library in xcode ...
http://www.icodeblog.com/2011/04/07/creating-static-libraries-for-ios/
just rename the .m file to .mm file and write your c/c++ implementation code in it....
try it for a small function first and if it works for you can implement all your classes in it...
Please make sure when you try to use this library in any other project in XCODE , only use .mm extension for all your files even the appdelegate... hope this helps.
I would recommend iOS Universal Framework. I have used it to create a number of static frameworks that I link against my application projects. It works like a charm and is really easy to setup - no need to come up with your own complicated shell scripts.
It adds a template for a new target project type, which you can then import and use just like an ordinary Apple framework. I would recommend setting up a workspace containing both the framework project and application project, that way the dependencies are handled automatically by Xcode.
In general, you DO NOT WANT to link to a static lib that is made with another compiler than the one used to compile the lib. Static libs are not really portable between compilers, since static lib formats are not covered by C/C++ standards. Due to name mangling and other formatting differences, you may not be able to link at all, or worse, it seems to work but injects bugs. Worse, if you use the standard library from your compiler in your lib, it will create horrible name collisions when someone links to your lib and they don't use an IDENTICAL version of the standard library!
Publish the lib using the compiler you expect them to be using. And if you must use the standard library, then you have to make sure they have the same version you have. Really, you should just have them compile the lib themselves or prebuild it for each compiler you support. It sucks, but that's the reality of it as it stands today.
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.
Each C/C++ library has some amount of headers that should be used with that library. And if you're use more than 1-2 libraries, custom header paths is kind of headache.
So I thought: is there a way to compile C libraries as frameworks. Static library + headers + versioning.
I found in XCode template for Cocoa framework but nothing about iPhone framework building. This simple step could allow developers to build and share between each other frameworks with some interesting code.
Also it would be great to use libpng, libjpeg and other libraries packaged as frameworks.
I won't use dynamic libraries in those frameworks. Only static version will be present.
I combined techniques I found here and here into my open source library here (NOTE - I have since removed the relevant scripts from this project. I have updated the link to point to the last revision that included these techniques.). Think that's basically the solution you're looking for.
Basically, it has a target that will build a fat static library (lipo builds for arm6, arm7 and i386). It has another target that takes that library and builds it into a framework.
There's no reason you can't use the same techniques for a C project. In fact I've started work on porting C the VTD XML parser to an Objective C framework using the same techniques.
Frameworks are basically just bundles of dynamic/shared libraries. Since this is not allowed in the App Store, you have to build static libraries and link them with your App's executable at compile time.
However, to ease the pain a little, you can have a Xcode project for each library and compile each library into a static lib. Another way would be to put all required source files into the main Xcode project and configure it appropriately so it all builds at once (I did this with small libraries like Minizip, for instance).
Hope that helps.
the problem you are trying to make already exists - it's called DLL hell
Best way is to stick with plain old static libraries when making small apps and organizing source/headers structure
I've build a static library working nice in a Cocoa Touch environment. Now I'd like to compile it also for Cocoa.. Can I have a single XCode project with different sdk targets? Is there some resource out there able to give hints about best the practices in this (and other) sense?
This last two months I have been working on exactly this task ( cross compiling static library for iPhone/Android/Mac OS/Linux/Windows...
It is certainly possible, a nice way, is adding an external xcode project as a target to your first xcode project. So you create a new "Active Configuration" for Mac OS X, iPhone and other platforms that you want to support.
Here, you can find a good tutorial about how to use a secondary Xcode project as a target of your main project to build a static library. It's a cool way because if you debug for example you still have all the symbols of the library, etc.
It can be done but it requires some manual tweaking of the build.
Start with the Xcode Build System Guide.
As an informal way of accomplishing this, you can create two separate projects and add references for exact same set of library source files to each project. Set one project to compile for Cocoa-Touch and the other for Cocoa. If both projects reference the same files, changes made in one project will be automatically reflected in the other. (If you have both projects open, Xcode will complain that the file has been changed by another app but otherwise it won't notice.)
I have a utility class that I continually dump new methods in. I add it to every project and just park methods as I need it. The new methods show up in old projects because the source files are shared across all the projects.
I'm trying to write an SSH client for the iPhone, and I'd like to use the libssh2 open source library to do so. It's written in C.
How should I include this C library for my iPhone app? Should I compile it into some binary that I include into the my app, or do I add all the source to my project and try to compile it along with the rest of my app?
I'm interpretting this question as:
"Should I compile the C library code once, and include the binary library in my project? Or should I include all the source and compile it every time I build my app?"
It depends. One of the projects I work one depends on several external libraries. Basically, we have a simple rule:
Do you think you will need to change code in the C library often?
If you will be changing the code, or updating versions often, include the source and build it with the rest of your project.
If you're not going to change the code often or at all, it might make sense to just include the pre-built binary in your project.
Depending on the size of the library, you may want to set it up as a distinct target in your project, or for even more flexibility, as a sub-project of your main project.
If I was in your place, I would build libssh2 ahead of time and just include the binary library in my iPhone project. I would still keep the libssh2 source around, of course, in case it does need to be re-built down the road.
I have an iPhone app that is 90% c. I have had no problem adding 3rd party sources to my project and compiling. I am using Lua, zLib, and libpng with no modifications. I've also included standard libraries like unistd and libgen and they just workâ˘
The Three20 iPhone library has a great howto on adding their library to your xcode project. Give that a shot.
I think you will find in the long run you will be better off building it into a standalone library and linking it with your application. This makes it easier to integrate into future apps. Another benefit is that it encourages code separation. If you feel pretty confident with the library, you can link your debug exe to the release build of the library and get some extra performance.
I can't really think of any downsides to creating a library, after the initial cost of setting it up, and having an extra project to modify if you have some changes that need to be made to all your projects. Even if you don't know how to make a library for the iPhone, this is a good excuse to learn.
Just adding the source to you project should work fine as well.