Does anyone here know of any “pure” Swift libraries that implement handy basic library features but don’t depend on any platform-specific libraries?
One of the things that most excites me about Silver is the ability to create shared code in Swift between platforms. But this means not relying on Apple/Cocoa libraries or the platform libraries for Android or .Net.
Swift is a great language but a lack of base library for things like file operations, networking, etc… make it less useful for code sharing between platforms.
Sounds impossible to get platform specific functionality such as networking from a “pure” Swift library. But, I think we can be a “pure” wrapper and then supply platform specific implementation at link time.
Yes, I guess that’s true – RemObjects could build core libraries for Swift, but would have to write them for each platform. We could write libraries like that using the native interfaces, but would again have to write them on each platform.
Right now, there’s Sugar. Which we hope can expand with contributions from the Silver community, over time. What sort of classes and features are you looking for mostly, that Dugar doesn’t yet cover?
Haven’t looked much at Sugar, but it does seem to have a lot of what I’d want, file access, some networking, etc… My ideal kind of sharing code would be a setup like this:
Model, storage, sync and business logic classes written in cross-platform Swift.
For Android or Windows development, use RemObjects compiler to:
create native libraries and then develop app UI using native Java/C#
or
create whole app using RemObjects tools and Swift
But for Apple development, I would prefer to reference those Swift classes from a native Xcode project and do the UI development and model/logic class development together all from Xcode.
As I see Sugar, it’s not available to me if I develop the whole Apple side of the solution in Xcode, because Sugar looks to be only for the RemObjects compiler chain languages and platforms. Am I wrong about that?
You can’t use Sugar from Apple Swift, because it relies on features it doesn’t have (such as Mapped Types). But you can use Sugar in the library you build in Silver, and then use that library from AppleSwift (and ditto for Java and VC#).
That said, for bets code sharing scenarios, our suggested approach is to use Silver for the hole stack. Really no good reason not to
But the issue with sugar is the fact that it doesn’t work in swift. So I was +1 a library that worked in both. For example. A library that wrappers sugar or core foundation in a pure, cross-platform swift.
I guess you/someone could do an extra wrapper on top of a Sugar, or simply implement the same APIs as Sugar does, but on top of Apple Swift. But that seems like a lot of work for what is very little gain IMHO.
What spams against just using Silver and Sugar on Cocoa, as well, if code sharing is your goal? After all, that’s why we do support Silver on Cocoa, and not just on Java and .NET.
For Cocoa it’s mostly a risk thing to use Xcode. Xcode is already proven and accepted by my team.
The goal isn’t to rewrite sugar, though it looks pretty cool. The goal is to just get a simple library to make HTTP requests and read and write files in a way that works for both toolchains.
Should certainly be doable, and if you are willing to undertake this and do that open source, we’d be happy to assist you in any way we can. It’s not something we’ll be implementing ourselves, at this stage, because there’s only so many things we can do at once, an this area, Sugar will be our focus for now — i hope you understand.
