I meant turning try before the super.init() call into no-op.
Yes I understand. That makes sense, and we are considering this, It all depends when the silver toolchain will be more robust. It is amazing, but currently it is quite raw, bugs in the toolchain are still very frequent, also frequent Fire crashes on debugging and during deployment to Android devices. Also Swift runtime is needed too. So the safest choice for us was scoping Silver for the Android-side of the shared library. (Turned out to be an amazing choice)
I can bet most of the iOS developers will prefer building for iOS with Appleās toolchain, while using Silver for other platforms. Actually, the only fact that we preferred Silver for shared library over previously-planned Xamarin integration, is that it is same swift codebase and our team can still develop within Android Studio and Xcode for the apps client-side.
You have to see what is the major needs of the silver developer-base. It is definitely that the majority will come from iOS community. This pretty much is the integral point, we donāt know yet how the competitive landscape for cross-platform Swift will look like in the coming years, but you definitely donāt want to have Silver got obsoleted by Appleās toolchain being ported to Android for example, so the best choice to my point of view is aligning it to the goals of Silver to the need of this community.
I think the very fundamental need for the community is just porting the existing swift codebases to build for Android. If that is extremely smooth, everyone will prefer Silver to whatever multi-billion counterpart it competes with.
Thereās no way we would ever leave XCode for iOS development. You would be pushing shit uphill all day. Itās such a closed eco system, that developing iOS apps out of XCode is never going to be a good answer. If we would consider using non apple tools for iOS then Xamarin might have been an answer, but we dismissed that years ago and went down the C++ path. Ouch, that hurt.
Silver is a great answer to cross platform dev because you can continue using the Apple tools and get cross platform support from the same code base. So every time there is a little difference between XCode swift and Silver its friction.
I have not developed a serious Mac/iOS project in Xcode for two or more years, and Iād probably have to kill myself if I were forced to ā because doing it in Fire/Elements is so much nicer and saner, even (especially) when using Swift.
@mh, @jnermut: guys this conversation is getting a bit harsh.
@mh: After 4 month using Fire I do have to say - it is a nice IDE, especially taking into account the incredible amount of work it took ultimately to build it likely by 2 developers, it beat my initial skepticism I had, yet I had to agree with @jnermut, at this moment it cannot match with Xcode when it comes to writing swift. Disregarding the stability of swift toolchain, you have many nice goodies that makes coding time smoother, such as coding time syntax checking, you can see the inferred variable types, you can jump across multiple definitions at once that contain documentation in comments and so on. It is not perfect though, ever since swift got release you get code highlighting source kit server crashes from time to time but overall it is much smoother sail as you might say.
I do understand you as the main architect of this whole thing, and we are definitely looking forward to this Fire thing becoming ultimate, as primary iOS developer l am probably biased towards Xcode and Swift/Silver 1-to-1 syntax conformance, but I think the majority of developers you get attracted to Silver will be just like that.
Sorry, I wasnāt trying to dis Fire at all, but merely pointing out that our organisation will never move away from XCode first development for iOS, so that compatibility with XCode/Apple swift is our number one priority. This is a risk based decision more than anything. We have been bitten before trying to go outside the bounds of what Apple wants us to do.
As @hurden says, my assumption from our biased viewpoint is that the majority of potential users will come from an existing Swift code base written and working in XCode, wanting to compile it cross platform.
