Creating reusable modules for both Fire/Silver and XCode

Hi All,

I am building an iOs app in Xcode using Swift. I am trying to split it into independent modules, so that some of them will be shared in the future OSX and WatchKit versions of my app. So let’s say my most basic reusable Swift component is called MyModel, contains only business logic and has absolutely no dependence on UI or data access or Networking or CoreData, etc. Just the business logic.

Next, I come across Silver Beta, and I think to myself, hmm, maybe in the future I can make an Android app using Swift, neat! And I will use reusable MyModel source files - how convenient!

And then I notice that all my classes in MyModel are actually descendants of NSObject and use some features of the apple’s Foundation framework.

So my BIG question is: in order to reuse my code for a Silver-based Android app in the future should I rewrite all my modules so they DONT user Foundation anymore? Android project will NOT understand it, right?

As well, I’d appreciate any other hints related to creating shareable components, thanks! Did anyone try doing this yet? How much of your architecture can you really make reusable? (Obviously, nothing UI-related, but what else)

I have similar issues, but they are with some runtime based functions. The answer is to recreate those objects and functions in a form that are independent of any particular platform, but whose implementation on each platform uses platform specific functions.

In your case, you may be able to find a port of those frameworks to Swift, or possibly translate open source versions of those frameworks to Swift from Objective-C.

This is going to be a common problem for users of the Silver language as it is, where you want to write platform independent code, but find yourself needing some fundamental functions and classes which are platform supported but not language supported.

Generally speaking though it should be straightforward to write platform independent code. The challenge is designing abstractions that work with your business logic, or other platform independent code, and make sense there, but also can be implemented across multiple varied platforms in a way that makes sense to, and is friendly for, the user.

correct, you will want tomato your classes to explicitly descend from NSObject. If you don’t specify a direct ancestor for your base class (or any of your classes, Silver (and Apple’s Swift) will automatically pick the appropriate base class for each platform, when you compile. e.g. go you define

public class MyEntity {
    var parent:MyEntity?
    ....
}

then this will compile for all platforms. on Silver/Cocoa, the descendant will will be NSObject, on Java it will be java.lang.Object, and so forth. But your code will not care, as long as these business classes don’t call into or override functions specific to those platform classes.

If you can use our compiler for all platforms (including Cocoa), you can make even more code sharable, by using the Sugar class library, which provides a lot of common objects (think XML, URL, Network calls, Strings with an API thats the same across all platforms). Iffier code uses the Sugar APIs, it (or those parts) wont complain Apple’s Swift anymore, because Sugar depends on functionality in or compiler. But that might not be a huge deal breaker, since you can target iOS and Mac with our compiler, as well.

Correct. If you out any effort into such APIs, i would suggest that you consider contributing them back to the Sugar project (or, depending on scope/target, the Swift base library, which we’ll also open source on GitHub soon, hopefully as early as this week).

A task for which Oxidizer can alleviate some of the grunt work for you. Check out Oxidizer.

Yes.he hope that we get a good community effort going to really add a lot of functionality to Sugar, here.

yours,
marc

Is there any way to use the Sugar library in an XCode project as an xcode framework?
We run straight XCode and Apple Swift for our iOS version, and compile a shared business logic layer with Silver for Android. We don’t want to use Silver for iOS, but having Sugar available on both platforms could be useful

Not sorry. Sugar depends very heavily on Elements compiler features, most importantly Mapped Types.

No worries. We have most of what Sugar offers in our portable layer by now anyway.