I'm new to XCode and Objective C / Swift. I'm trying to make a Swift library project that doesn't depend on cocoa or anything. So it's just Swift files. What type of project should I be creating (I'm assuming there are multiple ways of doing this? How do I need to configure the project so that it builds to a .so file? And finally, how do I build it to a .so file?
I'm using Xcode6-beta.
You can create a Swift library for iOS by creating a new Xcode Project and selecting iOS/OS X -> Framework & Library -> Cocoa Touch Framework and then setting the language to Swift on the next screen.
Once this project has been created you are not required to link against the Cocoa frameworks, and can remove any references to them if needed.
Upon compiling this project Xcode will create a .framework folder in your build directory which contains a dynamic library which you should then be able to link against. Note however that I haven't had any success myself yet at linking directly against this file, even though it appears to be a standard dynamic library.
In terms of using this shared object file on Android I believe you will be out of luck, as the Swift language (much like Objective-C) requires a runtime library which is simply not available on other platforms at this time.
... I think you are limiting your train of thought a bit or expecting leaps and bounds to quickly swift is ready to work with objective c and cocoa so you aren't going to be able completely avoid cocoa however you wont have to write any of it the compiler will do that for you. but you will still have to use cocoa frameworks or modules like foundation( contains many specialized objects for program development), UIKit, CoreData however these don't require you to write the cocoa. and if Im not mistaken the .so file is made on compile so you never actually touch that file but rather is supporting files .swift
to do it
if your looking to do everything programmatically or if you want to xib or storyboards just make a new project I prefer an empty project.(set programming language to swift and decide if you want core data or not finish the project wizard thing and bam you have a YourAppDelegate.swift you can make another .swift file or a storyboard and hopefully you know what to do from there. Swift book is available on ibooks for free its nicely written
although it will be quite a while before cocoa and swift are completely separate... if ever
Related
I'm making stuff for IOS, Mac, and WatchOS - I have certain common functionality that is more about me and the way I program than about whatever it is I'm programming - helper methods etc
What I'd like is to have a "Common" framework or library in my app which is included into every other library. I understand I need a separate target for each of ios, macos, watchos, but I can't figure out how to set it up.
I can create a framework - and it comes with a target - I can duplicate that target and change stuff, but I don't seem to be able to change it from IOS to macos for instance. I can create a separate macos target, but then I can't seem to be able to change where it gets the code from.
Essentially in my source tree I want a single directory:
Common
and then have target frameworks CommonIOS, CommonMacOs, CommonWatchOS - that all just compile "Common". How do I achieve that?
You're misusing the word "framework". All you want is to keep some source code as a library that all your projects and targets, no matter what system they'll be compiled for, can use. You are describing a Swift package.
When I build my simple menubar cocoa application written in Swift 4 with Xcode 9, a lot of libswift*.dylib libraries are linked/downloaded/embedded into .app bundle,into Frameworks folder as seen below:
I am only using import Cocoa and import Foundation in my project, and some #objc functions as selector to timer functions. I really don't think my very simple menubar app would need some 3D rendering Metal library functions or any SwiftOnoneSupport, so I would like them to be removed from the .app bundle. (Same libraries are also included in the helper app for launch at login feature, which makes even the helper app over 10 MB)
I would have thought Xcode would just copy whatever is neccessary by default actually. Some similar questions were asked here and here but I don't think there is a fulfilling and up-to-date answer to both.
What I have tried so far
I set ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES to NO in Build Settings. It doesn't seem to have any effect.
I set LINK_WITH_STANDARD_LIBRARIES to NO in Build Settings. It ruined everything and couldn't make it build even though I tried to add some frameworks(Cocoa, Foundation) on my own under Linked Frameworks and Libraries section.
Simply put, it's not possible to exclude the standard libraries that Swift automatically includes with an app and expect it to work. Currently any application created with Swift bundles its own version of the Swift Dynamic Library. Swift doesn’t live on the OS, rather it lives within each app bundle. What this means is that any app that is using Swift 4.1 for example bundles in the Swift 4.1 Dynamic Library (containing the 4.1 ABI), and so forth.
One of the things on the Swift project roadmap is to eventually have ABI Stability. If Swift becomes ABI Stable, Swift will live within the OS and it’s ABI will be compatible with every version of Swift.
From iOS v12.2 ABI[About] Stability for iOS is on. That is why your target will not include Swift standard library[About] because it is a part of OS
Does anyone have a guide to setting up a project that produces a static library under recent versions of Xcode? There are a few for older versions, but they use a project setting called "C/C++ Library" which seems to have been removed.
I notice "External build system" is still in there, and maybe that's a solution? The C code won't be changing structure too much, so a makefile could be a solution - but I've never used this type before, so I'd like to hear from people that have.
Ultimately the C code will be consumed by a Swift/Cocoa application. Am I correct in thinking that I simply include both projects in a workspace, drag the .a and bridging .h into the Swift project, and go?
It's a new setting under "Build Options". What does it do? I can't seem to find any documentation about it. My guess is this: Does it have to be set to YES in a mixed Objective-C/Swift app to tell Xcode to link against the Swift Runtime?
It does not need to be Yes for linking. This setting is only for when you have a pure Objective-C target that depends on a mixed-source or pure Swift target.
Description:
Enable this setting to indicate that content embedded in a target's product contains Swift code, so that the standard Swift libraries can be included in the product.
Also in the release note of Beta 7:
The build step which embeds the Swift standard libraries in a bundle now only runs for
application product types, and only if the application itself, independent of any embedded
content, contains Swift source files. When building an application that itself does not contain
Swift source files, but embeds other content like frameworks, XPC services, app extensions,
etc. that do contain Swift code, you must set the build setting "Embedded Content Contains
Swift Code" (EMBEDDED_CONTENT_CONTAINS_SWIFT). That way the Swift libraries will
be included in the application.
Regards
According to Embedding Content with Swift in Objective-C
Swift standard libraries are copied into a bundle if and only if you are building an application and this application contains Swift source files by itself
If you are building an app that does not use Swift but embeds content such as a framework that does, Xcode will not include these libraries in your app. As a result, your app will crash upon launching
To workaround this issue, set the Embedded Content Contains Swift Code (EMBEDDED_CONTENT_CONTAINS_SWIFT) build setting to YES. This build setting, which specifies whether a target's product has embedded content with Swift code, tells Xcode to embed Swift standard libraries in your app when set to YES
I don't believe that is required to have general interoperability between Swift and Objective-C. It's as simple as adding Swift code and editing the bridging header.
If you see any of the documentation about Extensions for iOS, the lingo mentions "embedded" quite a bit: embedded content, embedded frameworks, etc. Because Extensions are organized, built, and run quite differently from normal apps, I wouldn't be surprised that there's a build setting like this one pertaining to them.
I'm in the process of porting some code from Linux to Mac OS X. The code is a static library that you add to your code. Basically after you compile the code you get a MyLib.a that can be linked to whatever project you want.
I'm managing the "project" via a Makefile.
Is there a way to have a project on Xcode that ultimately produces the same kind of library? How?
Thank you for the help.
Sure. You don't say so, but I am assuming you are using C or C++ as source.
Assuming you are using Xcode 3.2.2, you can create a new project (File > New Project...), which will bring up a New Project window with available project templates. Select the "Framework & Library" category under Mac OSX from the list on the left. You should now see a "BSD C Library" and "STL C++ Library" among the other library and framework types. For building a static library like you described you want the "BSD C Library" option. There are static and dynamic options for this which you will see when you click on the icon, but static is default.
Depending on which version of Xcode you are using, the location of the project template may be a little different since Apple has been changing this UI for the New Project window fairly frequently. So if you are not using 3.2.2 you may need to poke around the available projects a little bit.
Oh, and don't worry if you are trying to build C++. Event though this says it is for C, C++ libs build just fine as well.