The Swift Package Manager (SPM) allows support for different platforms (e.g., iOS, macOS). I'm adapting a Swift library to use SPM, and the need is for some of the code for iOS and macOS to be shared, but to have some differences as well.
I've seen a similar example of this with the Facebook libraries:
https://github.com/facebook/facebook-ios-sdk/blob/master/Package.swift
In that case, they use multiple targets, each with its own (independent) code. This is not an example of platform dependency, rather of target dependency.
I see two paths forward:
1) Have separate library targets for iOS and macOS-- and use a similar approach to Facebook, but the bulk of the code would be shared across the targets. I'm not entirely sure if SPM allows code shared across targets. A downside here is purely in terms of syntactic sugar-- naming differences. It seems unfortunate that you'd have to import say "MyLibrary_iOS" on iOS and "MyLibrary_macOS" on macOS.
2) Have a single target for iOS and macOS, but embed conditional compilation within the source code to conditionally include/exclude specific files. This doesn't have the naming issue as above. But it seems unclean to have to do this conditional compilation.
Any other suggestions?
Thanks!
Wait for the upcoming release of Swift 5.3. This has been added via SE-0273.
Related
My iOS app has two dependencies (Alamofire and Charts) that it incorporates using Swift Package Manager.
When I build it, I get this warning wherever I import the modules in question, e.g.:
import Alamofire
Module 'Alamofire' was not compiled with library evolution support; using it means binary compatibility for 'YourApp' can't be guaranteed
What I don't understand is:
Why is this binary compatibility an issue, if my app builds the dependencies from source code using SwiftPM (not embedding frameworks distributed as binaries), and
What should I do about it?
The Alamofire repository's issue threads suggest that Library Evolution Support cannot be added to the current version because it hinders development, however it is supported in the previous major version (4). Perhaps that could be a workaround, but I don't want to perform the major code modifications that would result on my app from downgrading Alamofire.
I think the point is that with binary compatibility we don’t have to embed the Swift language frameworks into the app; the system Swift language frameworks will keep working for your app even if the language evolves in the future, without your having to recompile the app. Hence the name, library evolution.
So without that guarantee, the language will be embedded into the app, swelling its size and losing the other advantages of binary stability, such as the ability of your app to take advantage of faster code in the system frameworks when they improve things in the future, etc.
You can probably test that theory by building the app and looking inside it.
So if I’m getting this right, that is the sense in which Alamofire is holding you back, and explains the warning.
I support a suite of related iOS apps, some of which make use of extensions (WatchKit and Today Widget). All of these apps and extensions make use of a shared private framework I've built up over time for handling certain workflows around authentication and common business logic. This framework is maintained as a private pod.
Recently, I've run into a problem where I'd like to add a method to the framework that's only really useful for the iOS apps (extensions don't need it) that uses certain APIs that are unavailable to extensions (such as [UIApplication sharedApplicaion]). I'd like to get the usual benefit of shared code, where this is implemented in only one place (the shared framework) for all my various apps to leverage. However, I can't find a way to conditionally include that method for just the apps and not the extensions without getting a compile-time error.
Normal recommendations around this problem usually suggest the use of a preprocessor macro to opt-out around the problematic code if desired, but that doesn't really work for a shared framework situation. Macros are applied at compile-time, so the shared framework is either going to include that method, or not, and there doesn't seem to be a runtime solution to optionally exclude it. If it's included, the extensions can't compile. If it's not included, my apps can't make use of the feature.
I also started investigating if there was some way that Cocoapods could automatically make two versions of the framework, one to be used by the apps, and one by the extensions, but this would seem to introduce problems around duplicate symbols, and generally doesn't seem supported.
Are there any other suggestions for how to handle this, apart from just extracting out the problematic functionality into a different framework? (I really would prefer to just share one)
I'm trying to find more information / explanation for the following scenario:
I'm writing a library in Swift and would like to use some open source library in it.
If I just integrate them into my library, is there a chance of namespace collision?
What would happen if the host app will use:
The exact same open source library
The same library but different version
Does using CocoaPods changes something here?
Consider a scenario where I import AFNetworking for example (via CocoaPods) in my library, and the host app will use it too.
Using the same library, you won't have any issues. Using different version will likely cause problems, but that is going to be dependent on the changes made in the different versions.
Namespace collisions in Swift are rare. As #mattt stated, each module acts as a namespace, so naming conflicts with classes or functions from another module won't exist as they do in Objective-C. If you have a naming conflict, the compiler will tell you. In that case, you can just prefix the conflicting signature with the module name.
I would highly recommend you use Cocoapods for dependency management. It handles version control and will make your life much easier.
The first thing I tried is to create a static library but later I found out that it's not supported yet. Apple Xcode Beta 4 Release Notes:
Xcode does not support building static libraries that include Swift
code. (17181019)
I was hoping that Apple will be able to add this in the next Beta release or the GA version but I read the following on their blog:
While your app’s runtime
compatibility is ensured, the Swift language itself will continue to
evolve, and the binary interface will also change. To be safe, all
components of your app should be built with the same version of Xcode
and the Swift compiler to ensure that they work together.
This means that frameworks need to be managed carefully. For instance,
if your project uses frameworks to share code with an embedded
extension, you will want to build the frameworks, app, and extensions
together. It would be dangerous to rely upon binary frameworks that
use Swift — especially from third parties. As Swift changes, those
frameworks will be incompatible with the rest of your app. When the
binary interface stabilizes in a year or two, the Swift runtime will
become part of the host OS and this limitation will no longer exist.
The news is really alarming for me a person who writes components for other developers to use and include in their apps. Is this means that I have to distribute the source code or wait for two years?. Is there any other way to distribute the library without exposing the code (company policy)?
Update:
Is Swift code obfuscation an option at this point ?
Swift is beta now, and even for 1.0 Apple has been pretty clear they're after a restricted feature set -- better to do a small number of things well than to try to do everything.
So for now, there's no way to distribute binary static libraries. Presumably that'll change sometime after Swift 1.0. For now, you can:
Distribute source
Ship a binary framework (instead of a library) if you're okay with the ABI being fragile
Use ObjC for library code
You can always combine approaches, too: e.g., implement the critical (secret) details of your library in ObjC, and ship Swift source that wraps it in a nice Swift API.
Obfuscating code written in a language that's very much subject to change sounds like a recipe for a maintenance nightmare.
I believe the whole approach is wrong. You cannot do something that is not (yet) doable by the technology you are trying to use.
Rationale: Swift is a new language, currently in Beta, and therefore changing. As I see it, this fact means not only that you are not able to ship static libraries, but that (real) developers will not be actually use third-party static libraries. What's the actual use of a library that may not work in the next release of the compiler? The issue gets bigger if you whant to use more than one library, because they might not be compatible! Therefore, even if you would be able to ship static libraries, they wouldn't be actually useful for production environment. So, what's the point?
Suggestion: write your static libraries in Objective-C (or C or whatever "non-beta"). Developers who need third-party libraries (e.g. yours) shouldn't expect them to be written in Swift until Swift is stable. You don't use experimental materials to build real bridges, right? You use well-tested, predictable ones.
From Xcode 9 beta 4, Xcode supports static library with Swift sources.
We have a fairly rich e-learning app, built mostly using cocos2d. Currently we are in alpha and want to setup our project structure so we can also build a Mac version to target the Mac App store. It is about 80% cocos2d with some intitial screens in UIKit which will have to be ported to Mac (re-written).
What is the recommended setup for targeting both the Mac and iOS app stores from a single code base? I assume the choices are:
Create 2 xCode projects in the same application source code root folder and use each project to build a single target. This would be: Project.xcodeproj and ProjectMac.xcodeproj
Add a new Mac target to our existing iPad application project and then fiddle with target membership to get the desired results. This would be just: Project.xcodeproj
Further complicating the situation is that we currently use cocos2d as a static library for the iOS app. We also have a library called CoreInfrastructure that has a lot of code we use across all our projects. Recently I have figured out that I can create a project to simultaneously build a framework targeting Mac and a library targeting iOS from the same code base. This is done by starting with a framework project and adding a target to build a static lib for iOS.
So just wanted to get everyone's opinion and insight. Anyone know of any caveats to watch out for in the above choices? Anyone who is building for Mac and iOS app stores simultaneously care to share their structure? Adding a target worked on our library code ... is that the way to go for the application as well?
Are there any issues doing archive and distribution builds for either choice?
Thanks in advance.
WWDC session "Sharing code between iOS and OS X" answers all the basic questions in this topic. iWork team presented how they have got away with creating Pages, Keynote and Numbers with shared code base for both iOS and OS X.
The key for their project was using:
separate Xcode targets for iOS and OS X
separate project for the shared code in a form of a .framework
target dependency on the framework from the point above
I encourage to watch the video or read the transcript from this session:
WWDC 2014 Sharing code between iOS and OS X
ASCIIWWDC transcript
I recently used kstenerud's iOS Universal Framework to build a shared framework codebase that works for both iOS and Mac apps. I just needed to manually add a target for a Cocoa framework after I had created a project for an iOS framework. That way I can develop the sharable code once in the framework and link it in both the iOS and Mac apps. You can even make the framework contain UIKit-specific code for your iOS app and AppKit-specific code for your Mac apps. I wrote about it in my blog if you are interested.
For the applications use two separate projects. Using multiple targets for iOS and Mac in one project is very useful if they are sharing a library or framework. However, in your top level application almost nothing is shared. The UIKit code will need to be totally rewritten to use AppKit, the dependencies will be different, and even most of the project settings will vary.
Of course if you really want to see everything at once you can put both platform specific application projects and all the shared dependent library/framework projects in a single workspace. This is more a question of work style. If you want to switch back and forth between the two frequently this makes the most sense. If you want to simplify what you are looking at you can put them in separate workspaces that share many of the same projects. Separate workspaces has the disadvantage that a project can only be open in one workspace at a time so you effectively can only work on one at a time.
I just use multi-platform static library targets for the shared sources. You will need to expand that to the dependencies, however. If you have platform dependent implementations, you may want to create supplemental export libraries for those symbols.
So your structure might take this form:
CoreInfrastructure - cross platform static library.
PlatShared - cross platform static library.
PlatSpecific-OS X - OS X static library (or framework).
PlatSpecific-iOS - iOS static library.
The OS X app links to CoreInfrastructure, PlatShared, PlatSpecific-OSX, Cocos for OS X, and system libs.
The iOS app links to CoreInfrastructure, PlatShared, PlatSpecific-iOS, Cocos for iOS, and sys libs.
Problem (I've found) is, there are a lot of people who have not had much/any experience developing and maintaining complex project structures in Xcode. It's a pain (IMO) to setup duplicate targets, and properly maintain them as they grow -- even when they all refer to the same source files. That's why i prefer minimal targets and proper dependency structure.