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)
Related
I'm currently working on a contract job where I've been asked to help integrate a 3rd party SDK with an existing React Native app. The SDK only comes in Android and iOS specific flavors, meaning that it has to be added on the platform-specific side of things (in my case, the iOS side with Xcode).
For the app, the client has created a react native module which gets built into a Library in Xcode, represented by a separate nested Xcode project in Libraries/MyLibrary.xcodeproj from the root of the base Xcode workspace project. This library has several method stubs defined in React Native which will need to be implemented in Swift (and likewise in Android), as this is in these methods that the 3rd party platform-specific SDK is utilized.
The issue I'm having has to do with accessing the 3rd party SDK framework in the library's existing bridging header file. I have followed every tutorial under the sun for how to integrate external frameworks with an existing Xcode project. This includes steps about adding the framework to the project, adding it under the Embedded Binaries and Linked Frameworks and Libraries sections of the project target, adding it under the Build Phases/Link Binary With Libraries section of both the project target and the library target, and adding the framework path under Project Settings/Framework Search Paths. From here, I add the appropriate import statement to my library's Library-Bridging-Header.h file with #import <MyFramework/MyFramework.h> so I can then access the framework in Swift. (This import statement is copied directly from the bridging header file of the sample project included with the SDK, so I know it is correct and should not be given in a different format such as quotes instead of angle brackets).
Regardless of following all of these steps multiple times over and in various combinations, I still get this error at build time: MyFramework/MyFramework.h file not found.
To clarify, MyFramework is just an alias for the actual 3rd party framework I'm attempting to integrate, and MyLibrary is an alias for the existing library with nothing but method stubs given to me by the client to implement in Swift.
Again, I have read every tutorial and forum under the sun, but none seem to address this very specific issue of integrating a 3rd party framework in a xcodeproj Library within the iOS version of a react native app. I would appreciate any new insights or suggestions anyone might have to offer! And please, please don't just post a link to or copy the steps from existing forum posts about a similar-sounding issue, as I've probably already read it 😉. Understand that I think that there is something subtly unique about my specific circumstances which are causing these same steps from the 10+ articles that come up on the first page of Google and StackOverflow NOT to work.
Figured it out! I'll post my solution here in case anybody out there ever runs into the same issue as me.
TLDR - You must add the 3rd party framework in the root of the xcodeproj Library (NOT the top level project) AND ensure that the files were actually copied into that directory, not just referenced from the directory you copied the framework from (be sure to double-check in Finder, since checking the 'Copy if needed' box doesn't always work for some reason). Then, you must add $(PROJECT_DIR) to your xcodeproj Library's Build Settings/Framework Search Paths, and also drag and drop the framework from the root of your xcodeproj Library into the Library's Build Phases/Link Binary With Libraries panel.
I'll address some of the issues with other tutorials/forums that I found, with hopes that it might help someone else that finds themselves as frustrated as I was in this position.
Most only address adding the framework to the base level project, not the obscure case of a project within a project. Therefore, when you start following the steps, it can be confusing to know whether you should be changing the settings of the top-level project or the sub-project. Again, as I discovered, all changes should ONLY be made to the sub-project.
There are a few tutorials that do seem to address this situation regarding a project within a project, but the steps describe adding the framework to the top-level project under Embedded Binaries and Linked Frameworks and Libraries, but I believe the situation described in these tutorials are somehow subtly different than this situation here. Again, only mess with the sub-project.
There's a lot of discussion out there about "umbrella frameworks", but that doesn't really apply to this situation, and again, the terminology similarities can make it seem like it's a similar issue. As I understand it, "umbrella frameworks" are discouraged by Apple, but again, this situation is not the same.
Sorry for the long-winded explanation, but I'm hoping to provide the kind of detail I would have liked to have found when I was searching for solutions for this weirdly obscure problem.
Cheers!
I've just converted my app to Swift 3, and as part of this I have updated the well known "Charts" framework. All of my converted code is fine and building/testing well, so I have no concerns about that.
I have embedded the binary to use the framework after unlinking the old one, cleaned the project, built the project before trying to use any framework code, and cleared derived data.
However I still get a "ChartViewDelegate" is not available, cannot
find swift declaration for this protocol.
This is odd to me, as the Charts module imports fine, and autocomplete recognised all member classes of the framework. Also, it doesn't seem to be an issue with the framework, as when implementing the framework on a "fresh" project, it works perfectly as expected.
I'm at a loss of what to try next, apart from rewriting an entire app into a fresh project where I know the framework works. The framework is an integral part of the app. Thanks!
EDIT: I have already tried cleaning/clearing derived data.
I've been having this problem recently with any frameworks I added to my project manually. I fixed this by totally removing the offending frameworks and then installing via cocoa pods.
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 want to build a custom framework in pure swift. Then I want to export that custom framework and import it into another pure swift app project. I want to do this by linking to the framework in the "Link binary with libraries" build phase. Seems straightforward but I never get it working in this particular approach.
I have googled for solutions and tried out some things. However I don't want objective-c interoperability. It's all pure swift anyway. Also I don't want to create an app project and then add embed a framework in to that (what is the point of this anyway?). Neither do I want to reference the framework project (by dragging the framework project into the app project). And I certainly don't want to create a workspace. All the solutions I found fall into one of these categories.
Every framework and every app I work on should be contained to its own little project universe.
Thus far I am stuck at the errors "no such module" and "linker command failed with exit code 1". A link with step by step instructions would be appreciated or any other advice you might have pertaining to this issue.
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.