Swift

[emilwojtaszek]

It's really great project, but what about Swift?

[misterfifths]

@emilwojtaszek, thanks for the support!

I've been thinking about Swift and Amaro quite a bit recently. I've collected those thoughts below, but the short version is this: I don't think there's much to be done in Amaro. That will almost certainly change in the near future as CocoaPods support for Swift matures, but right now there's nothing preventing the user of Swift, and not much to be done to facilitate it.

Here's the situation as I see it, in detail:

CocoaPods support for Swift is not there yet.

CocoaPods has historically used static libraries as its method of integrating third-party code into projects (and until iOS 8, frameworks were not an option). However, Swift does not support being built into static libraries. So, the Pods folks have to make some major changes to get that working (not to mention the difficulty of backwards compatibility, the rapidly changing Swift language itself, and Clang modules).

Work is underway, though. See CocoaPods/CocoaPods#2272 and CocoaPods/CocoaPods#2222 to track that progress.

In the meantime, third-party Swift projects have no choice but to return to the old ways of integrating, like manually copying in compiled libraries or git submodules. I'm not willing to go out of my way to support those types of integrations in any official way when Pods support will be there soon. Especially since there's nothing stopping users from doing that on their own.

Adding .swift files to Amaro-generated projects works as-is

Xcode 6 has no trouble dealing with Swift files added to an otherwise Objective-C project. And if you add includes in the bridging header, Swift can access most, if not all, of the libraries Amaro recommends.

There is very little actual Objective-C code in Amaro

If, for some reason, you can't stand the idea of having some Objective-C code in an otherwise Swift project, there is very little code to port. (And what is there is very simple.) The AppDelegate and main.m are about it, really. And you could theoretically just subclass the AppDelegate if you didn't want to change the code.

One problematic area is the recently added code generation for storyboards and asset catalogs. Those spit out code that could be much better-suited to Swift (using, e.g., its fancy enums).

So, with all that in mind:

Potential/probable updates to Amaro in support of Swift

• Swift-friendly code generation from the various build-time scripts.
• Perhaps adding a Swift bridging header by default?
• Stay on top of Cocoapods developments and ensure compatibility as things change.
• Ensure build settings are appropriate for Swift code. By and large, jspahrsummers/xcconfigs should take care of this, but it never hurts to keep tabs.

I'm going to close this issue and add a link to this discussion in the readme.

If you encounter any problems with using Swift in an Amaro project, or if there's a specific feature/functionality you'd like to see, please file an issue or pull request.

Thanks again!