Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We have an idea for an framework or library that will be very helpful for any iOS developer. So we're seriously thinking about switching from app development to framework/library development.
But when we want to charge for the library/framework, we must protect the code somehow. How can we build a framework in such a way that the user of our framework can't see the source code, similar to how we can't see the source code of Apples frameworks? They only ship the header files and some weird Unix exe file with the compiled framework, I guess.
Or if it is not possible to make an compiled framework / library that other iOS developers can use without being able to copy&paste our source code, then is there a way to obfuscate the objective-c code?
Yes, it is possible to build frameworks so the user of the framework can't see the source code.
Check out these articles (I've successfully used the first one to create frameworks in the past -- the later articles are updates to the original):
http://www.drobnik.com/touch/2010/04/making-your-own-iphone-frameworks/
http://www.drobnik.com/touch/2010/05/making-your-own-iphone-frameworks-in-xcode/
http://www.drobnik.com/touch/2010/10/embedding-binary-resources/
To use the framework, your users would just drag the .framework bundle into Xcode. They will be able to see the header files you copy into the bundle (see the articles above), but not the source (as it's not included -- only the compiled output is in the bundle).
This can also be a great way to distribute code that is used for multiple projects within your company.
Update:
Check out the link featherless added below -- it is much more recent and all on one page: http://github.com/jverkoey/iOS-Framework. It also lays out the issues with several other approaches. This is the guide I now follow when trying to remember what to do when setting up a new framework. :)
Update2 (with Xcode 6 release)
There is a option, exactly that you a re looking for:
Universal Framework for iOS!
Will be my code visible to others? A: No. This Framework will export a compiled binary, so anyone can see inside it. You can make the same for some other files, like XIBs.
Why I need this? A: This is for developers/teams that want to share their codes without shows the entire code (.m/.c/.cpp files). Besides this is for who want to organize compiled code + resources (images, videos, sounds, XIBs, plist, etc) into one single place. And this is also for that teams that want to work together above the same base (framework).
(c) http://blog.db-in.com/universal-framework-for-ios/
This guide is a bit more recent for creating iOS static frameworks:
https://github.com/jverkoey/iOS-Framework
There is also a template for XCode 4 that will let you create iOS static framework projects.
Related
I have a requirement to create a framework for a shared set of common utilities that we plan to use in multiple iOS projects in our organization. The utility classes are written in swift and the framework needs to support projects in iOS 7 and above. I'm using Xcode 6.1.1.
I tried creating both a 'Cocoa Touch Framework' and a 'Cocoa Touch Static Library' and can't seem to get it working for iOS 7 builds.
With 'Cocoa Touch Framework', I get a warning that 'Embedded dylibs/frameworks only run on iOS 8 or later' and though I can get it to run, it fails during the iTunesconnect step with an error that the project's deployment target must not be less than 8.0 (mine is 7.0).
I tried with 'Cocoa Touch Static Library' as well using the steps given in http://www.raywenderlich.com/65964/create-a-framework-for-ios, but it just does not build with swift files. When I remove all swift files and add Obj-C files, it works properly.
Any help is greatly appreciated. How do I create a framework for a swift project with iOS 7+ support?
Thanks
Unfortunately, you cannot. It's one of the more disappointing factors about Swift.
As shown in the documentation, you cannot make a static framework/library with swift and dynamic libraries are only supported in iOS 8+.
The only option I recommend is that you develop an Objective-C static framework for iOS 7 and then begin to use swift when you wish to drop iOS 7 support. It's not the most ideal situation, but because you are able to have mixed languages in a dynamic framework, it means you won't have to waste time rewriting code (unless, of course, you want to).
Apple not supporting pure Swift frameworks before iOS 8 is somewhat hurting Swift adoption rate.
I'm not advocating the following solution as best practice. Honestly, it's a very flawed hack. We have a large pure Swift framework that does most of the heavy lifting for things here at work. And, we needed that framework in a product that ran on iOS 7.1+.
Here is the hack - Directory hierarchy is important. In an ideal situation, the project and the framework are siblings in the directory tree. Create a group in the project. In Finder, shift/command select all of the source files from the framework, and drop them into the newly created group. Make sure not to copy the files. Your telling Xcode to simply add the files to the project file, creating relative path links to them.
The framework should now compile directly into your project. I can't emphasize enough how fragile this solution is. As files are added to your framework, they also have to be added/linked into any project that you've "link embedded" the framework.
This "solution" should only be used as a last resort. Having to repeat framework parity across multiple projects is dumb. If time goes by with the project staying static, and the framework evolves, dump the framework in the project, and re-add it. It takes less than a minute to dump/re-add the framework, and reduces the chance of error.
Apple, please help us, so we can maintain best practices. I'm embarrassed to share this solution, as it's just a horrible way to get around something Apple is not supporting.
I'm exploring Swift with Xcode-6 and so far so good although I think the new collections need a little bit of work as I've managed to break the compiler a few times.
Problem is I'm now stuck trying to create the framework package to then use in another project. The project builds without issue and all tests pass successfully. When I go to create Archive (which I assume is what is required) I receive the error:
:0: error: underlying Objective-C module 'Sample' not found
Now I assume this has something to do with the contents of my Sample.h which tells me
// In this header, you should import all the public headers of your framework using statements like #import <Sample/PublicHeader.h>
which is fine except I have only used swift enums, structs and classes for this framework so therefore no .h files exist.
Can anyone shed some light on this one as I can't find any documentation available yet?
EDIT (7/27/2018)
The information in the answer below may no longer be accurate. Your mileage may vary.
I sat down with an engineer and asked this exact question. This was their response:
Xcode 6 does not support building distributable Swift frameworks at this time and that Apple likely won't build this functionality into Xcode until its advantageous for them to do so. Right now, Frameworks are meant to be embedded in your app's project, rather than distributed. If you watch any of the session videos or see the sample projects, this is always the arrangement. Another reason is that Swift is very new and likely to change. Thus your Swift-based framework is not guaranteed to work on the platform you originally built it on.
Slight Update
The engineer mentioned that it's not impossible to make a framework for distribution, just that it's not supported.
I was able to get past the error by going to the target for the framework and on the Build Phases tab under Headers, remove the MyFramework.h file
However I was getting the "Underlying Objective-C module not found" error when I was using a framework to share code between a containing app and an app extension, both of which were pure Swift.
Assuming you are creating a truly pure Swift module, you must disable the Objective-C Compatibility Header and any generated interface headers so the compiler doesn't go off assuming it can find an Objective-C module for the framework.
Do Not remove your public framework header. You'll get a module-map warning at link time if you do.
You might find this useful: Creation of pure swift module
In short: it's possible to make static framework, but there is one issue: it doesn't work in end user' project if "ProjectName-Swift.h" header included.
But, it works fine if you use only swift.
I think it's a bug in XCode 6, or that Apple does not allow archiving the Framework from XCode while in beta.
If you compile to profile XCode generates the framework correctly. (See the Release folder created in DerivedData)
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
Stable way to embed open-source code into static library in iOS?
I am not sure if this question belongs here. Please instruct me if it does not.
I am building an SDK which has Reachability.h and Reachability.m files. If a user drops my code into his own, and if he has files with the same names, he will have to rename my files or his own for it to work. Is there an elegant way around this such that the SDK could always be dropped in without causing any conflicts?
If you're providing source, then you can safely include Reachability (or whatever), but provide a target in the project file that doesn't include them. If you're providing a built library but not source code, then leave out the parts like Reachability that are readily available and provide instructions on how to get them and add them to the target project. Alternately, provide two (or more) versions of your library: one with Reachability and one without.
Change the names. Most reusable third-party Cocoa code employs three-letter prefixes (e.g. my own company uses FZA) on its class, function and type names.
i have developed a complete project for iPad and now i want the same source code to be used in my clients project but i dont want to share my source code with them. I found out that we can create some static libraries in order to accomplish this task.Can anyone help me with the process of creating a static library out of the source code which is already available with me.
Here's an answer I posted on external libraries. Although the question specifically relates to creating a fat binary it has some links to a tutorial site, plus Apple's guidelines.
iPhone external library
You'll also find tons of related questions on Stack Overflow, for example:
How to create a static library from an Xcode project?
Best thing is to do a search along the lines of "how to create iPhone static library". You should find lots of helpful resources.
You can get some stuff out of here,
http://dev.byteclub.com/blog/1-iphone-sdk/48-how-to-almost-create-your-own-iphone-os-framework
http://blog.stormyprods.com/2008/11/using-static-libraries-with-iphone-sdk.html
How do I create an iPhone framework and use it in other iPhone applications
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have been developing iOS apps for about a year. In that time, I have developed a fair number of classes that I frequently recycle from app to app. For example, I have a bunch of classes related to making it easier to write table views to control in-app settings.
Right now, I simply grab these classes from one app and paste them into the next one. My question is -- at what point is it likely to be easier to create and use a static library?
Static libraries have their problems as well.
Using a static library discourages you from fixing problems as you see them, since the code is in another project and it becomes troublesome.
GCC has a bug in whereas any method defined in a category is optimized away from the static library. Not good if you library code consist of lots and lots of convenience categories on existing classes.
So what you want is a solution where you can add dependencies to actual source code. This way you avoid the nasty GCC bug, and the boy scout rule is encouraged!
Our solution is a simple dependency system based on Rake. It creates sym-links to the source code of the shared libraries, and hard copies when building on the build server (You should never build the distribution binaries on a developers own machine!).
The sym-links allow developers to edit the shared code just as if it was part of the current project, while ensuring any cleanups, bug-fixes, etc. are always propagated to a single repository and benefits all projects using the shared library.
The hard-copies on the build server allows for the shared libraries to be tagged for version, so that the exact build of v1.0 you sent to App Store is forever reproducible!
A colegue of mine have blogged about setting up a build server for continious integration here: http://blog.jayway.com/2010/01/31/continuos-integration-for-xcode-projects/
I will nag him to blog and share the Rake based dependency system as well. It is basically just a handful of lines with Ruby script.
I have my own library of miscellaneous stuff.
I add things to it that I deem to be reasonably generic and that I can envisage using in the future at some point.
After all, there's no harm in adding it to your library, even if you never use it again.
As soon as you tire of copying and pasting you should create a library. Or, as soon as you make your first mistake (mis-)copying and (mis-)pasting.
Or, in more business-like terms: when the net present value exceeds the net present cost.
If you want to distribute your classes out to your "team", then you will not have to worry about changes they make to your code, thus keeping the libary consistant.
Or if you wanted to sell your classes as API's to another DEV team then your can hide the source code from the API user.
I have a few "utility" classes that I find usuful and I do tend to drop the class file into my solution as I find it easier and quicker, (not that the extra 2 to 3 clicks matter), so really i suppose i do it out of habbit more than anything else.
Another solution is to use use a version control system (such as git) that supports submodules. You can wrap up each of these helper classes (or even a collection of classes) in its own repository which can be imported into the main repository of your code.
In this way you don't have to worry about cutting and pasting errors. Also, if you make improvements to these classes they can be propagated to other projects that use them (if you want to), yet you can always roll back to previous versions for bug fixing / testing.
It is common to find such helper code on sites such as github example
I have a static library that is in a separate project.
That way I can fully develop the library, complete with unit tests etc. and then simply re-use it by making another project dependant on it.
It means I don't have to cut/paste, and it also means that should I find/fix a bug, or add/modify a feature of the library, then it can be regression tested easily.
Now all the projects that use that library can benefit.
So for my money, the time to turn a collection of 'useful code' into a library is certainly when you find you want to use it again.
(Of course we all have useful code snippets we re-use by copy/paste from a previous project - those aren't necessarily right for being in a library.)