We would love to hear your feedback. This project is very MVP and definitely has some issues that we will be iterating on over the next week.

Any features you would like to see, let us know. We plan on adding a much nicer view for all the libraries with more information. The ability to the community to add tags to existing libraries, and more.

Hope you guys enjoy!

What about some kind of integration with CocoaPods? Seems like there's going to be some duplicated effort here.

Yep, going to look in to this in the near future. Going to talk to someone at CocoaPods on Friday.

Awesome!

2nding

Nice idea... Currently it's only legal to share source code libraries though right? Binary swift frameworks would constitute Apple NDA covered software, so unless they're compile with Xcode 5 we'd have to wait for pro-tool libraries like Parse, Splitforce and Google Analytics to arrive?

As a non-Mac person, it's fascinating to see the difference in interest between Swift and Dart. Sounds like you can do "incremental progress" and succeed (Typescript), "radical progress" (Swift) and succeed, but something between the two doesn't work, at least as far as community uptake is concerned.

One possible difference is that Apple has signaled that Swift will be the language at some point. As far as I know Google didn't do that with Dart and, in fact, couldn't without getting buy-in from all the other browser vendors.

> One possible difference is that Apple has signaled that Swift will be the language at some point

Have they? Then I really hope they add some easy form of C++ interop to swift in a future release.

There's so much C++ code out there in the Mac/iOS world that rewriting it to swift (or even just wrapping it in C) would make no economic sense.

Since you can use Objective-C (and therefore also Objective-C++) libraries directly in Swift, it actually has quite a nice integration. Objective-C++ is a far better interface layer than something like FFI or having to write C wrappers for everything (as you see in most other languages).

Nitpick: Objective-C and C are terrific for interoperation. FFI works pretty well with Obj-C and C too because it is all based on C binary compatibility and predictable symbol mangling. This is how previous Apple language bridges like PyObjC and RubyCocoa worked.

C++ and thus Objective-C++ has always been a disaster for FFI or anything that depends on binary compatibility or predictable symbol name mangling. Obj-C++ has a lot of ugly areas partly because of this. Kudos to Apple to making it work as well as it does.

Swift is terrific that it also seems to interoperate with C/Obj-C nearly seamlessly (bridging headers), but it is no surprise that the Swift documentation immediately says it doesn't support C++ and you must build C interface wrappers.

* Edit: reclarified comment

> Have they?

Pretty much; Apple doesn't tend to release big things like this on a whim. At minimum they've certainly signaled that Swift will be treated as a first-class language on par with Objective C, and has every likelihood to replace ObjC for most use cases.

I think the context of the replaced languages also matters. Objective-C is de facto Apple-only to start, whereas Javascript is currently the largest run-everywhere language, mostly due to an accident of history that Dart is not likely to replicate.

I totally agree,Dart should be first class on Android for instance.Or what the point creating a whole new language.To run it in the browser?it will never win in that field.Dart is a good language,Dart engine could be an alternative to V8 in nodejs too.

Fully agree. The Chrome dashboard tasks now show DartVM integration is being worked on.

Most likely it will be a ChromeOS language and that is it.

From the keynote, even with ART it seems Android official languages are still Java and C++ and it won't change in the near future.

I actually hope Apple won't abandon Objective C and continue to improve it. I'd like to have languages from both sides of the spectrum (dynamic ObjC vs strongly typed Swift).

I can't imagine ObjC is going anywhere, much like how ObjC didn't cause plain C or C++ to disappear. There's far too much established code out there, in third party applications and Mac OS X itself, so support will remain.

Besides, it's not like Swift is necessarily ideal in all cases. For example it might remain relevant for C library bridging code to be written in ObjC, even if the application itself is Swift at the core.

It probably helped that there was a lot of latent frustration about the Objective-C syntax, which looked very foreign for developers coming from other languages (apart from smalltalk :-)). So by announcing a language with a familiar and modern looking syntax, they captured the interest of a lot of developers who was attracted to building apps on iOS, but didn't want to use Objective-C.

I think that it also helped that they had a lot of high quality documentation (like the Swift book) ready from day one.

The politics with Swift are well understood - it's simply an alternative to Objective-C that is technically superior in. A bunch of ways. Objective-C is effectively proprietary, so if you are willing to program Objective-C, you are presumably ok with programming on Apple's platform and it's just a straightforward technical choice.

Dart is an alternative to JavaScript, and the politics are a lot more murky. JavaScript is the open language of the web and is not controlled by a single vendor. Although Google has opaquely submitted Dart to ECMA, the politics are much less clear, and of course they have given themselves a multi-year head start in implementing and understanding the language. Supporting Dart involves risking handing even more control over the web to Google.

Google submitting Dart to ECMA is no different from Microsoft submitting .NET to ECMA, alongside the .NET early versions source code (I forgot how it was called).

Agreed. It really just tags a particular version of the language. It gives zero commitment from Google about how the language will be evolved or deployed. Unless they do a lot more to make the language into a commons, it's really just a PR move so they can say 'but standards'.

I think it comes down to the perceived future of the language more than anything.

Dart support is pretty poor. You can compile to JavaScript, but that adds friction. Browsers don't support it directly, and probably never will. It seems like there's a pretty decent chance that Dart will be dead within a few years, at which point any time invested into it will have been somewhat wasted.

Swift support is pretty good. It's completely integrated into Apple's toolchain, and writing an app in Swift today is just like writing an app in Objective-C. Apple's throwing their weight behind it and there's zero chance that it will go away anytime soon. Putting time into it carries zero risk as long as you think you'll want to continue to target Apple platforms.

This is the upside of Apple's dictatorial "I am the platform!" model. If they decide that the platform shall support a new language, then the platform shall support a new language. On June 1st, the main language for development on Apple platforms was Objective-C. On June 2nd, it was Objective-C and Swift, just like that.

No company can swoop in and impose something like that on the web. This is generally a good thing, as one company can't fuck it up for everybody. But there are disadvantages, like it being really really hard to push a good new language.

Yeah! Screwing it up for everybody is what standards committees are for :P

Modded down because somebody can't take a joke? Truth hurts doesn't it?

If you want serious examples, look at OpenGL standardization and how every competent GL developer has to work around the standard via GL extensions because the standards body fails to deliver anything useful. Here's just one historical gripe. http://www.theregister.co.uk/2008/08/13/opengl_firestorm/

Or look to Douglas Crockford's snipes at the ECMA standards committee for JavaScript, such as how they failed to clean up known problems until only after the hilarious talk "WAT" (https://www.destroyallsoftware.com/talks/wat) went viral and really humiliated them.

By most measures Dart is outpacing Typescript in terms of uptake (Stack Overflow questions, #of major publishers releasing books, etc). I agree with the other posters that Swift has been all but declared as the de facto (and eventually de jure) future of a huge platform - neither Typescript nor Dart can make that claim.

> Stack Overflow questions,

true but not by a long shot :

ts : 2,441

dart: 3,465

now compared to all js questions both are insignificant anyway ( 641,566 )

> neither Typescript nor Dart can make that claim

as devs move to ES6 using TS will make more sense ,that's Microsoft bet.

Not from the code I see everyday being written on our consulting projects.

It is still pure JavaScript. No customer wants those languages on their code base.

Awesome project I know I'll use several of this packages. It would be awesome to list the packages CocoaPods name if it has one. So it's easy to install.

CocoaPods does not support pure Swift libraries yet. This Github issue lists some ways you can help: https://github.com/CocoaPods/CocoaPods/pull/2222

Would it be acceptable for me to submit someone else's package? Can they edit tags/etc?

Oh, and nice idea. I've been waiting for something like this. Ideally, I'd like to see something a package manager like brew or apt.

It would be acceptable. We will be adding the ability for the repo owner to manage the entire project, but also the community will be able to add extra tags, etc. These are in the upcoming weeks as we iterate on it.

It's already there CocoaPods, they already support swift and Obj-C and there is a huge library of packages available.

This is a great help for someone like myself who is just learning Swift. Pretty excited for some of the JavaScript style libraries being ported over to Swift.

If you are just starting out, checkout http://www.sososwift.com It has tons and tons of resources.

Seems to be quite a few in regards to the functional world. Underscore has a port over and a couple others that mimic this.

Good idea.