In this tutorial on how to use CocoaPods I am having trouble understanding the following paragraph:
Unlike Objective-C, the standard Swift runtime libraries aren’t
included in iOS! This means your framework must include the necessary
Swift runtime libraries. As a consequence, pods written in Swift must
be created as dynamic frameworks. If Apple allowed Swift static
libraries, it would cause duplicate symbols across different libraries
that use the same standard runtime dependencies.
Here are my questions:
What exactly are the "standard Swift Runtime Libraries"? Is the Swift Standard Library one such standard swift run time library, would a framework I write in swift be considered a swift run time library?
What exactly does "Swift runtime libraries are not included in iOS" mean? I guess I am having trouble inferring what "iOS" refers too.
Any additional insight, links, resources or explanations regarding this paragraph would be greatly appreciated!
Edit:
After reading the runtime library wiki article I am no longer confused about Q1. The following paragraph clarified this for me:
The concept of a runtime library should not be confused with an
ordinary program library like that created by an application
programmer or delivered by a third party, nor with a dynamic library,
meaning a program library linked at run time. For example, the C
programming language requires only a minimal runtime library (commonly
called crt0), but defines a large standard library (called C standard
library) that has to be provided by each implementation.
However I am still confused about Q2.
Objective C has a stable (unchanging) runtime library, so it makes sense for there to be one shared copy of the library, provided by the OS (macOS/iOS), available to all applications that need it. In contrast Swift is a rapidly evolving language, which means that its runtime library undergoes vast changes between versions. Because of this, Xcode bundles in a copy of the Swift runtime library as part of each app, to ensure that a copy of the correct version (the version the app uses) of the runtime library is available to the app.
Swift Standard Library vs Swift Run Time Library
[Swift Standard Library]
Swift Run Time Library is a part of Swift Standard Library
Before iOS v12.2 there were not ABI[About] stability on iOS level, that is why you could see a lot of frameworks(Swift standard library[About]) inside each built target
Also you are able to adjust it via Always Embed Swift Standard Libraries(ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES) for targets before iOS v12.2
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 have a project that includes a shared library as source files.
Some of the library classes need the include of some Frameworks (like the known Apple Reachability).
Those Frameworks are not included into the project because I don't use the classes / methods that needs them.
I have a MyStandardLib.h that references all the library headers, and that is included in the.pch on my app.
But...
When building my app, the linker generates link error for those objects I don't use/call in the app So they should logicaly not be linked.
As an example, if I remove from the project the incriminated classes and Frameworks, everything works fine.
If I add the needed Frameworks :
It's crazy to do that for each project because of classes I won't use
It increases my app file size for nothing useful (26 Ko -> 1.2 Mo)
How can I avoid those linker error, and avoid links that should not happen :
keeping my library as is in the project (I don't want a precompiled library)
Not needing to include all those useless Frameworks until I really need them
The reason for those errors are clearly because the frameworks you are including in your project do require those other frameworks (from what you could provide they use: Reachability, the CFNetwork Framework and the CoreLocation Framework)
What is happening is that when the compile links your objects (in the compiler sense of it) it is also looking for objects 'mentioned' in your added frameworks and it is not finding them because they have not been included to your projects.
If you use a Framework A that is linked with Framework B then if you application C uses framework A it also needs framework B because frameworks are not exactly self contained.
If your code compile without those frameworks and your application needs to take low space simply remove them from your Build Phase and you'll be good to go.
However, if it doesn't compile without those frameworks you will have no choice but to include them in your project and, therefore, increasing even more the final space required by your application.
This is probably not a simple question so I am not looking for a definite answer but just some pointers to get me in the right direction.
I have absolutely no experience with C/C++ but have good knowledge of Objective-C. I also don't know much about different compilers and architectures so please be nice if I am talking stupid :)
I have some MatLab code that needs to be ported to Objective-C to run on an iPhone application. My first tentative path to get this done would be to check if MatLab can export the code as a static C/C++ library that I can call from within my Objective-C code.
This seems to be the case but I am not entirely sure what to do next, and what things I need to keep in mind when compiling the library on the MatLab side (i.e. architecture, compatibility, PC vs Mac, etc).
I have been provided with a .DLL and .LIB files which I believe are Windows compiled so they will not be useful for me, is this correct? From working with previous static libraries I can see they all have a .a extension - what do I need to do to get one that is compatible with the iPhone architecture?
And once I get the library compiled, how to I import and use it within my project? Will I just be able to call the public methods directly from within my code?
What else do I need to know or be aware of?
Any help is very much appreciated!
Thanks,
Rog
Static libraries contain binary code tailored for some specific operating system and platform. That means that it will use the OS to internally acquire memory (if it uses dynamic memory) or to perform any other OS specific operation (logging, output).
Even if the generated code was completely OS-agnostic (basic math could be implemented without OS support), the platform is completely different, matlab will generate code for an intel platform and the iPhone runs in an ARM architecture, with a different instruction set calling conventions...
Unless matlab is able to generate static libraries for the iPhone or at the very least for an ARM platform and make it OS-agnostic, you are out of luck.
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