I am creating my first Swift framework and I notice there is a default .h file (Obj-C). What purpose does it serve in a Swift Framwork? Can it be removed without causing problems?
It is a bridging header to make sure everything plays nice with Obj-C frameworks. You may be okay deleting it depending on the intended use of your framework, but it won't hurt anything to leave it in so that's what I would recommend for best practice and to make sure you don't accidentally break anything in different contexts that you use the framework in.
Related
In C, C++ and Objective-C you can compile part of an executable into its own "object file" and use it (and/or a library containing multiple object files) from any other code by including a "header file". Highly-templatized C++ code notwithstanding, a "header" typically contains just the declarations needed to validate the correctness of calling code (and assist the IDE with autocomplete, etc.).
But Swift does not have header files.
Now, apparently it is not currently possible to make a Swift static library, but in the future how would a situation like the above work, wanting to use some existing precompiled code from "new" source code, given that Swift does not have headers?
Would it work something like how [I infer] Java must work, where the compiled form can be introspected enough for the compiler to verify it is being used properly? Does Bitcode in addition to its intermediate representation also provide the necessary "protocol" for retaining such metadata?
If Apple were to port Cocoa to Swift (and keep it closed source), how would it then be "imported" into Swift apps?
Although, really, this question is not anything to do with "closed source" per se but rather trying to understand the boundaries around compilation units in Swift. Based on a similar question for the Go language, mine here could be re-phrased as: can you link to a pre-compiled Swift library without the source?
Well, just consider Apple's Swift libraries. They are closed-source, and you can use them fine and you can see pseudo-"headers" for the stuff in the library in the compiler. The exact mechanism of how this works is not currently publicly documented, but it must exist.
In addition to #user102008, the good new is, Swift will be open sourced by the end of this year, and even ported to Linux by Apple. While we can't guarantee it will always work that way (as Apple has poor records on those kind of issues), people will found suitable solutions within this even if Apple has no interests in doing so.
Even more, afaik, Swift objects were actually Objective-C objects. There'll not be that different to make Swift things work than Objective-C. (More details: http://www.eswick.com/2014/06/inside-swift/) After they were compiled, just do a class dump (or load it into a debugger such as IDA) and you can easily create a .h to make it work like normal static library or a framework.
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)
I am trying to use a framework which does not use ARC and it seems that I have to turn this feature off before I can use it. My question is, what are the potential ramifications of doing so? If I turn this off, what will I have to do to my current code to make sure I don't have any memory leak or any other issues in general?
ARC works fine with static libraries that use manual reference counting. If you're copying a bunch of .m files into your project, though, that's a different story. Fortunately, it's pretty easy to turn off ARC for specific files; you should do that for the files in that framework and leave your own files using ARC.
When I'm using big frameworks like the Three20 Framework,
I always have the choice whether to #import the whole framework or to #import only the single file of it i'd need.
I guess there's a difference in compilation-overhead since it has to open all files of the framework, but is there also a run-time difference? like bigger memory-usage? Or does the compiler-optimization already remove everything that's not needed?
And if I use the same framework pretty much in every class I use, is it recommended to include the framework in the prefix file instead of every single class?
Greetings
Infinite :)
There will be a compilation difference, yes: including everything will take longer to compile. But there shouldn't be a run-time difference.
Your idea of including the framework in the prefix is a good one for frameworks you're going to be using throughout. However, there is a catch, which is that if you change something in that framework your entire codebase will have to be recompiled.
There is no performance hit in runtime. No matter how many frameworks or files you import, if you don't use whichever classes they won't affect the resultant bytecode when you compile. The compiler doesn't even optimize anything; unused classes just "aren't there" at all.
Include the framework in the precompiled header file if you're sure it's going to be necessary.
You footprint won't be any different unless you actually use the classes however I prefer to be more frugal with my headers, only including the ones I need. If I need a lot from the same library (like Three20) then you can add the whole reference.
Only include headers in the prefix that don't change much, but it will speed up compilation greatly.
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.