Swift and C# Quick Reference – Language Equivalents and Code Examples [pdf]
download.microsoft.com
download.microsoft.com
Also, the code at http://aka.ms/scspostercode is nice.
I definitely see it improving in the future (I personally view Xamarin development as a better option for Android than standard Java), but it's not something I would recommend for an actual workplace to use.
I agree it's an inconvenience but I find after the initial setup it works quite well. My workflow is to have a Mac Mini under my desk, with a USB extension lead taped beside my keyboard. Then I plug my iPhone in and once I push F5 Visual Studio talks to the build host which talks to my iPhone and builds/deploys/starts debugging and everything "just works".
The biggest impediment to being productive with Xamarin, in my opinion, is that every second release manages to break something.
Storyboards are a decent solutions for certain problems, but if your app ends up as one monolithic or a group of large storyboards, you are going to be structuring and defining things in ways that will have friction with some of your better practices in your C# code.
That's not to say Xamarin "should be a cakewalk, you're doing it wrong." I found pain with dealing with the same area you describe -that back and forth with designs built heavily in storyboard. Not to mention, so many helpful posts on dealing with UI features and quirks seem handled or better handled in plain old NIBs + custom code, etc. Drag and drop layouts with D+D segues are nice, but when the client wants things "just so" I'd end up having to tear things out of the storyboard/designer to get all the things moving and performing well.
The storyboard failed me with AND without Xamarin.
I am also really loving Swift when you can use it on its own (I.e., without relying on an older Obj-C based library). The strictness of the type system eliminates many runtime bugs.
Your suggestion makes no sense to me.
For example I am not a C# developer, rather a developer.
I use whatever technology stack our customers require us to do. I change project almost every year.
So I can imagine some customers would have iOS only projects and in those cases I would try to push for Swift instead of Objective-C.
On my case, enterprise customers actually went with Cordova for mobile multi-platform. On the few projects I took part on.
For my hobby projects so far I went with C++, as they tend to be small multimedia stuff and I don't feel like paying Xamarin for hobby projects I do with months interval and sometimes are left unfinished when life takes over.
So Native UI + C++ (now C++14) suits me better, although the NDK is a big pain to use and quite limited, but at least Windows Phone and iOS are nicer to use.
If I had to do it professionally on my own company, maybe Xamarin would be an option, specially since Qt seems to be way behind Xamarin in terms of device support.
And why not setup an iOs project with a portable core project so you could build an Android/Windows phone/other project next to it in the future?
Im also a not a fan of the pure white, but thats quite a minor complaint.
The session was interactive/follow along, the instructor led in swift and I decided to try following along using C#/Xamarin iOS (disclosure: I use Xamarin.iOS daily and am a big fan of C#). On iOS I had worked for a couple of years in obj-c before moving to Xamarin, but hadn't touched swift. Having read comparison articles similar to this, my otherwise uninformed opinion was that swift looked to provided a far more reasonable experience, similar to C# - to the point that I wondered whether it was worth paying the fee for Xamarin to avoid the archaic objective c language. However, there were a few things from the demo that changed my mind (some are apple ecosystem, some are swift):
- no first class support for package management, and adding references to to libraries by hand can still be error prone and frustrating. We spent 10 minutes getting the room set up with their cocoapods - lucky me I had NuGet and in a few clicks had the packages installed. - no `await`-style capability - it seems small but nested callbacks is not something I want to have to deal with anymore, and it makes certain patterns unwieldy. - no LINQ query provider style support - making a call to the azure mobile service with a filter and sort clauses required newing up awkward predicate and sort objects and attaching them to a query before running (which then, again, required a callback!). In C# you could use the same syntax you would use if the collection were local - `await table.Where(i=> i.Name.Contains("Bob")).OrderBy(i=> i.LastName).ToListAsync()` - and the clauses would be transparently translated into parameters for the service call. - Lots of "crashes" in the IDE while writing swift code, where the compiler would bomb out and syntax highlighting etc. would be disabled while it sorted itself out again.
Swift still seems to be a huge improvement over obj-c, and some of these will be improved as time goes by, but fundamental features like await make a big difference, especially working on mobile where you are often waiting on network calls, user activity etc. And that's all before you even touch the topic of code sharing.
Cocoapods with Swift support is still in beta. You'll probably have a better experience once it's been officially released.
> Lots of "crashes" in the IDE while writing swift code, where the compiler would bomb out and syntax highlighting etc. would be disabled while it sorted itself out again.
Likewise for this; Xcode is a much better IDE for Objective-C than it is for Swift at the moment, but it is improving (a new beta of Swift 1.2 + Xcode has just been released that fixes a lot of problems).
https://github.com/ServiceStack/ServiceStack/wiki/Swift-Add-...