Hacker News new | past | comments | ask | show | jobs | submit login
I Don't Know Swift (robnapier.net)
235 points by speg on July 20, 2014 | hide | past | favorite | 109 comments



Great article. Swift is one of those rare opportunities where the barriers to entry are reset, and any dev willing to put in the effort can be rewarded. Feels like Java felt 17/18 years ago, but only much more accelerated. The big, BIG difference is you need to commit to a single platform, whereas Java ran/runs on Windows, Mac, Linux, etc.

Swift isn't a language that opens your mind like Lisp or Haskell, but it seems like it is a language that can reset a career.


I've been developing a mid-sized project in Swift since its release. And while the language feels new and interesting, the only thing that matters (and has remained largely the same) is the Cocoa touch API.

One's career is built more on knowing the ins and outs of the significant collection of frameworks provided by Apple, not the language. The language can be used to explore new design patterns and implementations, but it's really the API that makes it capable.

I think Swift is as much a barrier to entry as Objective-C (i.e., not a very big barrier). The hard part is knowing the APIs available, when to use them, how to use them, and how not to use them. That has not been reset with the release of Swift; in my experience with the language so far.


The next generation of Cocoa APIs will be developed with Swift in mind. Every Cocoa API today is developed for the features and limitations of Obj-C. And yes, for a number of years to come, APIs will still retain Obj-C compatibility. But we'll also start seeing Swift-only APIs (even if these are functionally equivalent to other Obj-C APIs), using design patterns that are appropriate for Swift instead of Obj-C.

So yes, you do need to know the Cocoa APIs. That's extremely important for developing applications today. But the applications of tomorrow will be developed using APIs we don't have now, APIs that are based around idioms and design patterns that will be developed over the next year (or few years) as people explore Swift and figure out what they can do with it that's different from Obj-C.

Apple will undoubtedly define many of the idioms and design patterns themselves. But there will be many that emerge from the community, from experiments that people do and open-source libraries they write.


I agree that Swift will influence the development of future APIs, however I think my point that it will not reset careers still stands.

I don't believe that languages influence API design very much — unless they are of a fundamentally different paradigm, which Swift is not.

Most of the iOS concepts I see new developers struggle with are related to architectural decisions not informed by language design. For example, the biggest thing I see new iOS devs struggle with is reusable table/collection view cells: the concept of cells moving into a pool once scrolled off-screen and re-used was made for performance reasons, new developers often attach model state to their cells and end up with all sorts of bugs. This is not a language issue.

APIs are where the majority of the learning is. For example, if you try Reactive Cocoa (or Swift RX), you are going to be thinking about your app design in a completely different way. Same thing applies to auto-layout, device trait collections, layer-backed view hierarchies, and so on. These concepts are not likely to be influenced by Swift, and these are the things that really matter.

That said, I do see Swift eventually dropping message-passing-heavy APIs (NSNotificationCenter, target:selector patterns) in favour of more strongly typed APIs. But most developers should not find the transition jarring.


This is absolutely true ! I'm new to the iOS development, and while swift is really easy to get into, the API's are a complete mystery. Even building a simple app involves a ton of tutorials/articles and Googling, because one really needs to know the APIs as well as the concepts of doing things. I can write quicksort in swift, but not build a simple app.


Truly I wish Swift was cross platform, then I would commit myself to learning it and doing cool things with it.

As it stands though, it's just another walled garden. Aren't developers tired of those yet? Even microsoft started opening up .NET a lot more. Who, in 2014, creates a new programming language and thinks it's a good idea to lock in the developers to Apple products?

Maybe the language will be a revelation and it'll be implemented by volunteers on Linux and what not. But until then, what's the point?

Tell me, iOS/OSX developers, why bother? I want to know why people think it's a good idea to learn Swift at this point (other than purely for technical curiosity which is great).


To be fair, learning a new language is a joke. It doesn't require a substantial investment of time.

You're most likely going to be gluing API calls together and that's where you'll spend 80% of your time: Learning APIs. Even then this is more likely looking things up in documentation or googling for answers on StackOverflow. Whether you glue them with Python, Ruby, Objective-C, Java, Swift, etc. it really doesn't matter.

If a new programming language is your only gripe then you have a way bigger problem on your hands when it comes to writing applications :)


> To be fair, learning a new language is a joke. It doesn't require a substantial investment of time.

I suspect Peter Norvig would disagree with you there -- http://norvig.com/21-days.html

> You're most likely going to be gluing API calls together and that's where you'll spend 80% of your time

For certain problems this is the case, and you can get away with writing Python/Ruby/etc in Swift syntax.

For other problems it isn't the case. Choice of language does matter; if it didn't, would Apple have invented Swift in the first place?


Learning to program is not the same as learning a new language. Norvig is talking about something utterly different that has no relevance here. It's even hinted at in his own words -- "Learn at least a half dozen programming languages.".


> Learning to program is not the same as learning a new language. Norvig is talking about something utterly different that has no relevance here.

At least in parts of his essay, Norvig is talking about learning a new language when one already knows how to program. For example, where he says:

In 3 days you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for.


> To be fair, learning a new language is a joke. It doesn't require a substantial investment of time.

I think that rather depends on the language and your past experience. Most programmers with experience in mainstream languages will indeed require a substantial investment of time to learn a radically different language like Haskell.


>radically different

But swift isn't radically different paradigm shift like switching to a purely functional language like Haskell from a life spent writting c++.

I think your confusing learning functional programming with learning a "functional programming language." The "functional" part takes longer then the "programming lanague" part.


I didn't say anything about Swift: rather, I was responding to the parent's overly general assertion.


> Tell me, iOS/OSX developers, why bother?

Learning Swift really isn't a big deal.

If you want to make something, then just make it. If you need to learn something that might not be permanently useful: so what?

Really, the knowledge you learn when developing an app is not "wasted" because the language is proprietary. The important parts will relate to design and architecture, not implementation details such as language used.

Once you are a competent programmer you don't really "learn" new languages, anyway. You just jump in and use them, then look up reference when you get stuck. It's a trivial thing in the scope of building an application or a game.

> Maybe the language will be a revelation and it'll be implemented by volunteers on Linux and what not. But until then, what's the point?

What's the point of developing in Objective-C? For practical purposes it is a proprietary language. Yet it is used by many people and used successfully. The point is to build something that will be used.

Your argument applies equally to many successful languages and development environments. I don't think Swift should really bother you, considering what it is designed to replace.


> Learning Swift really isn't a big deal.

Often I feel that learning a new language is more like learning a local dialect or slang than a truly new language. Some languages are very different, but I'd wager that if you're looking to learn swift you've probably worked with another very similar language before.

Sure there'll be some stumbling blocks, but you can get to a point of "this works, but probably isn't the best or fastest way for this language" fairly quickly by trying things and copy-pasting errors into google.

> If you need to learn something that might not be permanently useful: so what?

Indeed, and unless it's a really poor language you'll probably take something useful away from it. Maybe it'll be a language-feature that saves a lot of boilerplate that makes you wonder if you can implement in your own favourite language. Maybe it'll be an awesome package manager or module structure. Maybe it'll just be fun or make you think more about how different approaches work for different situations.


Have Microsoft given their official blessing to the multi-platform ports of .NET then? If not, .NET and associated languages are in the same position as Swift, surely?

Plenty of people write software for Windows using .NET, which happens to be the main fashionable system to use on Windows, and isn't typically popular on Mac OSX. But this does not make .NET rubbish - it just happens to be designed for Windows and isn't natively available on Mac OSX from Apple. Does this make .NET and associated languages "bad" or "not worth learning"?

Just because Mono is available on other platforms thanks to the huge effort from the community does not necessarily mean it would be a good choice to use for a cross-platform product, as the real journey and path of the platform is still in the hands of Microsoft. This is the same as Java used to be. But it didn't stop people writing plenty of software in Java, thanks to the main platforms supported by the Java VM. Did this make Java "not worth learning"?

I suppose Apple doesn't really need to care about making a language for other platforms. From the perspective of developers on Apple platforms, the need for a cross-platform language/system would seem redundant. As other posters have mentioned, the niche Objective-C language has found plenty of developers, and that's typically available on Apple devices (unless you count GNUstep). Does this make Objective-C "not worth learning"?

And remember that just because Swift is on one platform doesn't mean you CAN'T do cool things with it. It just means that you can only do them on one platform. That is in Apple's best interests. Does it really need to be available on every platform to be usable?

For example, they don't serve pizza at my local Chinese takeaway. This doesn't stop the food there from being great. And it doesn't make pizza less delicious when I buy it from elsewhere. But I'd be foolish to complain about the lack of pizza from the Chinese takeaway and refuse to eat the lovely Chinese food they serve there. Chinese food and pizza are both delicious, and they're only available from different places, but that doesn't diminish their taste.

I suppose the witty solution to the problem you face is to just learn C or C++ and do cross-platform stuff with that.


This is quite an unfair comparison.

First of, Microsoft does support the development of .NET and associated components. It is definitely not an active support relationship, but MS answers the questions Mono developers have and has provided some help for the Moonlight project. Furthermore, it seems Microsoft is making an effort to make ASP.NET on Linux more attractive.

Having said that, it doesn't even matter what Microsoft does with .NET. If Swift stays 'closed' as it is, you can use it to develop Mac and iOS applications. If .NET stays 'closed' as it is, you can use your .NET experience to develop Windows desktop applications, 'Windows Store' applications, web applications and services, client side web programming, Windows Phone apps, apps for iOS and Android with Xamarin, Linux desktop applications, and even operating system development or protocol verification if you're an adventurous academic. All of these things are being done right now by people, and good tools exist for those things. I realize that people on HN don't like Microsoft's lock-in or tools, but experience with .NET does give you access to a very diverse set of areas to program in.

Now I'm quite convinced that Apple will open source Swift (they appear to have informally confirmed they'll be doing exactly that [1]). And then its basis on LLVM will make sure that it can be used in other places as well. But I doubt Swift's uptake outside of Apple apps will be bigger than Objective-C's simply because, unlike Microsoft, Apple won't use or promote Swift anywhere for anything else than Apple apps.

The point is that 'openness' of a language itself does not matter much for the value to learn it. It depends on how much you can do with the language. Even if you assume "You can never use Swift outside of Apple's context" and "You can never use .NET outside of Microsoft's context" are both true (which they are not), Microsoft's context for .NET is much broader than Apple's is for Swift.

[1]: https://twitter.com/mxweas/status/474581160454942721

[2]: Of course one can argue that developing Mac+iOS applications itself presents more value than all of the .NET things I mentioned combined. But that was not the point of this discussion.


When you say "closed" I thought the .NET compiler was accepting pull requests from anyone as of recently, I remember that being a fairly large announcements.

I don't mean to be argumentative, but the Roslyn compiler is open source right? I'm genuinely curious.


There's a reason that I put 'closed' in quotation marks. Many important parts of .NET are indeed open source. It is also unfair to discount Mono, which is a very functional implementation of the platform. But even if you assume this 'closedness' for the sake of the argument, his/her comparison was still unfair.


Perhaps the comparison was a bit off. I am not intending to be argumentative in the slightest.

Microsoft's context for .NET is only broader due to community effort and NOT due to Microsoft's active help. When .NET first came out, was it as widely usable on all those platforms and for different types of applications? No, and that's exactly the position that Swift is in right now. In a few years time, there might be a community effort for Swift on different platforms, but look at the success of GNUstep and the libraries surrounding it; there is not wide adoption by any means yet Obj-C remains popular.

A large portion of the list of applications that you mention are typically Windows platforms - Windows desktop applications, Windows Store applications, web applications on Windows servers, Windows phone apps. Replace the word "Windows" with Apple or iOS and you get the complaint that the parent mentioned. It's entirely a point of view problem, ie you don't get iOS/Mac OSX developers complaining about new language features in T-SQL when SQL Server is not available for iOS/Mac.

I suppose the same complaints were made against .NET all those years ago - "why bother learning it? I can use the libraries and languages I already know!". It is a poor complaint to make really, as the effectiveness of a language or library does not depend on it being open source, eg. Java (years ago), the Win32 API, MFC, Carbon, Cocoa, C++ (does the committee steer itself based on our suggestions we just throw at them?). Their success and use has happened on closed-source platforms and with closed-source devices, but it's entirely irrelevant in the same way that adoption of an open-source language is, surely?

It would be interesting if Apple does open source Swift, but as you say they won't promote Swift outside Apple apps (in the same way that I can't see that much marketing material from Microsoft encouraging us to use Mono on Linux; ie, Microsoft doesn't promote .NET use outside Windows platforms either). But that doesn't stop an army of C# developers existing. It would be interesting to know how many of the C# developers use that language because it is available on multiple platforms (perhaps we could have a poll?). I would think that very very few developers are using because they know it is cross-platform to some extent ("I'm going to use C# and .NET for my Active Directory MMC snap-in page because I can attempt to compile it on another platform!"); in fact, C# and .NET jobs mention Windows development 98.9% of the time don't they?

I just thought that refusing to even take a look at a language due to it not being open-soured was a bit of a foolish thing to do or complain about, and to be upset that a language (designed by a company for its own operating systems and own devices) was not available on other platforms and OSes was a bit of an odd complaint to make too!

EDIT: I have reread this and it sounds quite harsh! I don't mean it to sound harsh. I did not know that Microsoft has opened up the .NET system a bit; I was more attempting to highlight that the original parent's comments was a bit whiney for no reason, and I wasn't meaning to pick a quarrel with you btw. Apologies!


> Tell me, iOS/OSX developers, why bother? I want to know why people think it's a good idea to learn Swift at this point

I'm sure that swift is of great interest to people who need to write iOS apps, and who like to use modern languages.


I may yet be disappointed but expect Apple to Open Source it after release as they normally do with their LLVM/Clang changes.

It is still in Beta and still in flux at the moment (language not just implementation).


Being in on the ground floor of Swift doesn't confer the ability to ship good apps, which is the actual career-maker. The old hands of iOS/Mac development retain their advantage over the newcomer even if they ignore Swift until after it has settled down.


Most of my iOS client projects are dumb wrappers around a JSON API. Even with the most mind-blowing language in the world, I would still be worrying about session timeouts, client-side persistence and navigating a tree of view controllers. I don't understand why people get so excited about Swift while the APIs we need to build actual apps only grow more and more bloaty.


It's better than that. Java 17/18 years ago was still not designed compared to similar languages of the time - particularly Python 1. Swift, on day 0, is a typed language that requires far less token noise than Java did on day 0 (and still does today).


> Feels like Java felt 17/18 years ago, but only much more accelerated.

The article mentions that Swift wasn't tested by building a nontrivial application prior to release. It's worth mentioning that Java was tested this way: Sun built HotJava.


You mean "Java ran/runs poorly on Windows, Mac, Linux, etc.", right?


Haha, a snide jab at Java. How intriguingly novel!


Yeah, but I remember in 1995 and afterwards where Java products popped up and applets appeared in every webpage, and it was truly slow, particularly for paupers still languishing with small amounts of RAM. Anyone remember JBuilder?

Things have probably changed significantly from then, but I do remember it being slow. Compared to today's generation who get frustrated when a webpage doesn't appear within about 3 seconds, they would lose their mind if they were transported back to 1995 (with the general speed of everything being slower).


The linked Twitter post does bring up a good point: I wish Apple would make it easier for third parties to build tooling for the iOS/OS X development environment. Stuff like alternative IDEs, Xcode plug-ins, tools for instrumentation/debugging, alternative simulators. Some of this already exists out there (e.g. AppCode), but most of it is really dependent upon the often-buggy first-party tooling. Better support for third-party tooling would ameliorate the pain developers feel when Xcode doesn't work well.

I don't even see any downsides. A thriving third-party tooling ecosystem would only serve to lure more developers, resulting in more applications and increased hardware and software revenue. It's not like Apple currently makes money selling its development software to developers.


Definitely take a look at the Alcatraz package manager fro XCode[1]. I discovered it recently and it's heavily improved my experience!

[1]: http://alcatraz.io/


I think we can be reasonably certain that Apple will not support, and, wherever possible, will actively discourage the development of third party primary development environments. They learned their lesson with CodeWarrior, and aren't going to let third parties take a leadership role in their development environment.


For the sake of someone who has never developed on a Macintosh and only saw CodeWarrior in action a few times, could you explain what happened and how Apple responded?


It became the de facto development platform for MacOS, then when Motorola bought it they started de-emphasising MacOS support, eventually dropping it. Apple responded by putting a lot more work into their own development tools.


The problem for Apple is that doing that would then hold them back; they would be required to not break other people's code with new releases, and I feel they would like to be able to completely reqrite large parts of Xcode as often as they like without worrying about outcry when they break someone else's code.


Could lost desktop & laptop sales be a downside? I think it's easy to under-estimate how many developers have purchased a Macbook Pro or Mac Mini primarily so that they could develop for iOS.


I would say yes. I just bought a Mini and an Air, just for iOS development :)

Well, I also got the Air because it's such a fantastic laptop, after years of using corporate Dell bricks.


"If you’re reading my blog, there’s a decent chance that I know more about Objective-C than you do. I have opinions about it. You should take them seriously even if you disagree."

That's a weird way to start an article. I was hesitant to read the rest. And the rest of it was a mixed set of odd arguments, e.g. "I predict with great confidence that Swift will be TIOBE’s language of the year."

I have no idea why would I be interested on your prediction on a not-very-useful index.

I don't even understand his argument: he is complaining that normally languages are evolved in small circles before publishing, and says that Swift has come naked, half-baked, to the world but then also remembers to say it isn't even released (!)


Did you just read the first half of the article?

The rest of it is the main point.

Given that it's likely to be very very popular, and nobody can claim to be an expert, you can be one of the most knowledgeable people in the world about it by getting in now. Want to be the author of a very popular framework in a very popular language? Write a framework now in Swift.


These are exceedingly poor motives.

Write a framework in Swift if the abstractions it introduces are considerably better and more conceptually complete than the existing tools.

Otherwise you're not really improving things, just piling on more crap for people to learn.


Dude! There are no existing tools!! That's the point of the whole article!!!


Or, write a framework in D.


Agree. I think the main point is to say that Swift is new and not fully baked, there are no experts, so now's a great time to jump in and become an expert. Get active.

Seems like a fairly clear point... What I don't get is why making that point needed the "I know more ObjC than you do" preamble.


Agreed. I came away from this thinking "wtf did i just read?" 1/2 of it seems like him saying how Swift should have been reviewed more before release then him saying he expects greatness. With no real grounds for the latter, except that he has a lot of experience with Obj-C. Not that I have an opinion either way, i have not personally looked into Swift(and know very little of Obj-C).

Just seems like he didn't even know where he was going with this article.


> I have no idea why would I be interested on your prediction on a not-very-useful index.

Because it's a prediction about internet, community, and people's behaviour, based on the previous knowledge about languages. Not based on the knowledge of Swift. It's a commentary about people jumping on the language that is likely to be pushed very hard by Apple - whether it's ready and useful or not.


I'm currently building an imitation of Apple's keyboard in Swift (https://github.com/archagon/tasty-imitation-keyboard). Learning process has been pretty easy so far: a few hours with the documentation and the rest picked up along the way. Playground was great for getting up to speed. It's pretty fun to be on the vanguard of a new, evolving language and have it actually be capable of production use. Also very frustrating: there are a number of design decisions that drive me crazy (lack of auto casting between CGFloat/Float/Double/Int... usually), and the latest Xcode and compiler betas have a bunch of bizarre non-deterministic bugs, performance issues, and error messages that have nothing to do with my code and require workarounds. I'm a little too lazy to file Radar bugs for them — Apple is not paying me to write bug reports, and they'll surely get discovered by others — but I'm really looking forward to writing a brief postmortem when I'm done.

(PS the code is super messy right now. I'm in the "hack away" phase, cleanup will come later.)


> Apple is not paying me to write bug reports, and they'll surely get discovered by others

So you are happy to write a long comment here in exchange for karma, and are excited to blog later in exchange for eyeballs, but won't submit radars to improve your tools because Apple isn't paying you?


These are bugs that will be found, unlike most other Apple bugs. Also, I'm busy and bug reports take forever to write and reproduce, especially for the kinds of eisenbugs that I'm seeing. Why so judgey, friend?


FWIW, duplicates are really important to getting bugs fixed.


If they're not fixed in a few betas, I might file them.


I'd have to agree that it's not fully baked but as someone learning it currently, I have to say that it's a pretty awesome language. It fixes a lot of the annoyances I have about other languages and wraps it all together. Things like multiple returns, closures, etc are super handy features that I've wanted in other languages.

Shameless Plug: Check out www.LearnSwift.tips if you're trying to learn. It was born out of my desire to learn Swift and is just a simple curation of resources, tutorials, code samples, etc to learn Swift.


> multiple returns, closures, etc

What other new(ish) language in this day and age does not support this? You have closures in e.g. Haskell, Java, C#, Rust, C++, JavaScript, Python and Ruby. You have destructuring/unpacking support for tuples/lists or something similar that can be used for multiple return values in e.g. Haskell, Rust, Python and Ruby. I think there will be destructuring in future JavaScript standards and I don't know about C#. I think a new language that doesn't support these things would be disappointing.


C# can pass parameters by reference, which is often used to return multiple values from a function. In new C# 6 it will look like this: if (int.TryParse("1234", out int result)) { /* do stuff */ }


If you count that than so can C/C++/Objective C (via pointers/references). But I like to use tuples and destructuring of tuples more (syntax wise).


When you say multiple returns do you mean something like generator functions, functions that return some form of tuple like construct, functions with variable return types, or something else? I haven't looked into Swift much at all, so I'm curious.


Tuples are used for multiple returns in swift.

So a function definition might look like:

    () -> (Int, String)
(Function that takes no parameters, returns an Int/String tuple)

Edit: Tuples can also have named parameters, so something like this is possible:

    () -> (index: Int, name: String)
Then the resulting tuple can be accessed by name:

    //Where x is a tuple returned from the above function
    x.index
    x.name


As interpol_p says tuples are available. It is also quite possible to return a function or other closure so a generator function is definitely possible.

The return type does have to be defined though so there isn't a way to have a variable return type. I suppose you could return something of "Any" type but would you really want to?


I think this post makes a valid point, and I also think it's important to remember that Objective-C has also been changing incredibly fast during the Apple's meteoric rise and the accompanying developer interest. Swift did not come out as fully baked as some might like, but Apple made the right move releasing it sooner rather than later.

Forcing developers to use a language with as much baggage as ObjC couldn't continue, particularly when compared to the much preferred web languages. ARC and Storyboards were big changes but with the amount of headaches developers have suffered dealing with the App Store, they needed something exceptional to keep old talent and bring in new I believe.

I'm excited to see how fast Swift can be baked, but just judging from HN / Reddit it is earning Apple a lot more developer love than any time in recent memory.


In the wake of the Swift announcement, it feels like some 'incumbent' iOS developers are saying 'sure learn Swift but if you want to do iOS dev you still need to know Obj-C' (as opposed to 'sure learn Swift but if you to want to do iOS dev you still need to know UIKit' which I agree is obvious) as a strategy to protect their turf.

Or perhaps it is just words from the wise?


There are several reasons I'd say someone still needs to know Objective-C.

Swift is still half-baked. No, make that quarter-baked. It is not newbie friendly. Vast areas are undocumented, the IDE is even more unstable than usual for Apple, the compiler crashes constantly (I probably crashed it more than a hundred times just in the first week), the standard library is lacking, etc. etc. All of this makes it pretty difficult for veterans to work with. If you're new to iOS, or god forbid new to programming in general, you're going to have an extremely difficult time.

Virtually all the sample code is in Objective-C. Discussions assume Objective-C. The APIs, though translated to Swift, are still rooted in Objective-C. Trying to follow all of this without knowing some Objective-C is going to be tough.

In a year or two, when the language is solidified, then going straight for Swift will probably be viable. But right now, it's a terrible choice for anyone new.

It has nothing to do with trying to protect our turf, and that's rather insulting. I feel no need to protect my turf, because as an arrogant dickhead, I feel secure in the knowledge that I will still be a better programmer than 90+% of the folks out there no matter how much good advice they get. I've never even heard of anyone remotely competent deliberately giving out bad advice to protect themselves.


Beta 3 might be half baked. The array semantics are fixed and it crashes far far less. For the first two betas quarter baked was definitely a fair description.


I think you might be confused. Most professional and experienced iOS developers are working for established startups or enterprises. As such they are dealing with existing Objective-C codebases that they continually add new features to. It's nothing to do with protecting their turf just the realities of working in the industry.

So if you are planning on making iOS development a "career" then learn Objective-C first. If you are creating your own startup or playing around then learn Swift first.


If for no other reason, the sheer amount of Objective-C example code out there is reason enough why having Objective-C literacy is a emphatically a Good Thing.

I've found a fun exercise while learning Swift is to re-write Objective-C examples line by line and see how much terser you can make them. The end result is usually worth it, and when it breaks it's always insightful.


I read those comments as "it's not going to happen overnight." There's a lot of code written in Obj-C that will stay in Obj-C for a while. Many people don't even have time to learn Swift right now, and don't need to.


Hanging around the #swift-lang channel on IRC is very instructive in seeing where the problems of a lot of people that want to learn Swift to start their iOS programming journey. Very rarely do they encounter problems with Swift. They're hitting problems with translating Objc to Swift.

Well there are optionals. I think everyone ran into issues with optionals and syntax.

Protect their turf? If anyone is going to benefit from this its people that already know iOS/OS X frameworks and only need to learn a new language. Arguably, that didn't even mean much when the first iOS SDKs came out years ago.


I'm an ObjC dev and I encourage folks to learn Swift, which I am also doing. The thing about learning Swift and still needing to know UIKit is true - it'd be like learning Rails without Ruby, which you just can't do. The first Swift book did a good job introducing you to the language, but didn't delve in to the reality of UIKit at all, which the second book did fill in on. But there are still places where you have to use an NSDictionary over the fancy new Dictionaries, and that reality is very much still here.

If I were starting a new project tomorrow, I'd still use ObjC. If someone where working for me, I would encourage them to learn ObjC for now. Swift isn't going anywhere, but neither is ObjC, and the path from zero to app is still easier in old ways I think.


Well, I think it is wise at this point to learn some ObjC if you're just starting out with iOS development. If you plan to interface with (and therefore potentially debug) any 3rd party code it will be pretty important to know. Also many (most) iOS examples will be written in ObjC. The bridging between Swift and ObjC will remain important for awhile I'm sure.

So, in my opinion it is words from the wise - I'd still recommended focusing on Swift for experienced developers jumping into iOS development, but understanding the ObjC underlying just about everything one will do in Swift is important.


As a mostly-Java, Android and web apps type of developer who's only recently gotten into ObjectiveC iOS app development, I have two questions for the community:

1. Will Swift be cross-platform or is it going to be strictly for MacOS X and iOS app development?

2. Will Swift apps run on older versions of OS X and iOS? I've seen differing opinions (e.g., http://stackoverflow.com/questions/24001778/do-swift-based-a...)


1) Possibly. It seems likely that it'll be open-sourced sooner or later, like Clang was. Everything said by Apple people has been cautiously positive on this front.

However, it doesn't have much of a standard library as part of the language itself at the moment, being heavily dependent on Cocoa stuff. GNUStep/Cocotron could presumably be used.

2) Yes; Swift apps run on iOS 7 and up, and MacOS 10.9 and up. There currently seem to be some bugs which turn up on iOS7 but not 8 or vice versa, but Swift is quite buggy in general at the moment, and this will probably be cleaned up.


Personally I think Swift could really change things for apple if it could be used for server side scripting. An integration with core data, and you could easily share Models on the client and server side.

It would make it a no brainer language to use for a mobile app, because you could kill two birds with one stone. To date however, apple has made no comment about cross platform development


But you'd have to use Mac servers, right?


Unless they open source it, yes.

Knowing apple, I feel that they would have an off the shelf solution that you could just push code to. Almost like a parse type solution, integrated through Xcode.


Swift isn't stable yet.. You can't do big projects in it.. We did some stuff in Swift..but it's not something that can be scaled as of right now


What were your scaling issues in particular?


We learned Swift right after it came out , then we realized that it's just not mature enough and stopped our project


So here's a question for you mobile devs guys. I'm a software developer with experience in C#, Ruby and enough Go to be dangerous, where do I start learning Swift?

I imagine it's a twofer, learning Swift AND learning the iOS bits.

I don't mind paying money for a solid learning resource. Thank you.


My recommendation is:

- Download the ebook that describes how to use the language. You can get it as an iBook or a PDF, or just view the documentation on the developer site. The ebook is really approachable and will show you how to do most things in the language.

- Learn a little bit about Foundation and UIKit so you can use the Cocoa APIs. You can build command-line applications in Swift without touching any of the Foundation stuff, but without it you won't be able to do that much.

- Go to Github and look at some of the projects people are doing. Check out their code for ideas as to what to do/what not to do, or how to solve problems that aren't discussed in the book.


My process so far (I'm still learning): - Learn the basics of Swift the language https://developer.apple.com/library/prerelease/ios/documenta...

- Watch the Stanford iOS Intro videos to become acquainted with the iOS way of doing things http://online.stanford.edu/course/developing-ios7-apps-fall-...

- Start coding some projects and just learn as you go. It seems as if you know enough programming fundamentals to jump right into it with some basic intro material. Do check out my site www.LearnSwift.tips as well.


I'm going to emphasize this and add that writing Stanford's course example apps in Swift instead of ObjC is really a great way to learn the language.


The resources Apple provided have been awesome:

(IBook related to learning the language) https://itunes.apple.com/us/book/the-swift-programming-langu...

(Further resources) https://developer.apple.com/swift/resources/


Use the Playground feature and start tinkering with a simple UI thing. It's really, really good for learning since the results show up immediately and you don't have to compile anything.


The Apple books and WWDC videos are quite good; they're nominally aimed at ObjC programmers, but should be understandable enough anyway.


The article starts off by setting a negative tone.

"If you’re reading my blog, there’s a decent chance that I know more about Objective-C than you do. I have opinions about it. You should take them seriously even if you disagree. "

It's confusing when trying to understand his point and in all fairness I don't think it added to it.

Even the title is a bit self-serving after reading the opening paragraph, "I don't know swift" can be loosely translated into, "I don't know it so it must be new."

He makes a good point that we can help grow swift into a better "fully-baked" language by contributing.

I think the article would have been much better without the first paragraph. I think there would be less confusion amongst readers and would have set a lighter tone.


If you had to estimate how long it would take for the community to start producing code exemplifying whatever "idiomatic swift" turns out to be, how long do you reckon it will take?


I think the sentiment of this piece is very sound, but I don't know why I would ever expect anything out of Apple to be up to me to change. I've never known them to listen to anyone about anything and I don't know why this is an exception, even if listening would make sense.

Most likely a lot of people have already told them that Swift being limited to one platform is a massive mistake and if they're not listening to that I'd rather just give up on them now.


It is incredibly risky to release this unto the world without having tryed it internally. I hope they can iterate quickly enough to iron out the most glaring problems before the language is ossified by the amount of code already written in it.

Otherwise, we might just get stuck with something half-baked that never had a chance of growing up before widespread adoption.


It seems to have been used internally for some time. The public WWDC app was written in Swift, and many Apple engineers had moved to using Swift entirely by the time it was announced.

The most glaring problems exist in the IDE support for the language, not the language itself. There is minuscule risk of Swift not gaining widespread adoption amongst iOS and OS X developers.


The article actually states that all the API's are the old ones. And not so long ago most of the posts here were that Swift is "too conservative."

I claim that Swift is very good selection of more modern stuff on the tried and tested base. It doesn't even depend in GC and VM. It's great in its conservativeness.


Then in 20 years people will convert everything under the sun to run in it and claim it's the new assembly.


Apple once told us that the best way to write applications for the iPhone was using web pages. Caveat emptor.


if swift exited then this would have been great. By this time swift would have replaced javascript. Think of the way apple killed flash video. They could have killed javascript.


And that the future was GC


Good reminder of how new Swift is, given that I've recently seen a couple of LinkedIn profiles already declaring their owners as Swift experts, despite the language being released only ~1.5 months ago.


lol Reminded me of a joke when it first came out: Recruiters will be on the prowl for Swift devs with 5+ years of experience!


Oh, I'm sure a few corresponding job ads can be found floating around too, including on LinkedIn.


I wonder if such ads could be being used as a honey-pot. Useful for determining who not to hire. (and possibly not in compliance with employment laws at the same time, if no job exists)


If there is anything the software developer industry doesn't need, it's more tests to automatically reject people.


Given how generic they are, thats probably true. I recently had someone asking for three years of experience in AESON (for the uninitiated: thats a JSON parser...).


I once had a recruiter send me over a job spec asking for experience with ActionScript 4. This was back in about 2009, when Flash and ActionScript were still relevant, and ActionScript 3 was the current (and last) version of the language. When I quizzed the recruiter about this, and sent him a Wikipedia link, he told me that was what he'd been given in an email by his client and that he was furious with them for making him look like a fool. See, they're not all bad (or perhaps he just told me what I wanted to hear...).


I know some recruiters and what you say is true: it's not necessarily the recruiter but the client that is clueless. I did some hiring for some companies and saw some of this at work (e.g. the CFO writing the job offer, never passing it by us and then sending around something like this).

Considering the volume that recruiters have to handle, they also cannot check everything for validity, so they are probably the wrong persons to rant about.


Chicken or the egg?


Maybe they aren't Apple Swift experts: http://swift-lang.org/


Well, if one has 2 months of experience and everyone else has zero...


Here is a good resource to learn: http://ios-blog.co.uk/swift-tutorials/


A counterpoint: Swift is actually quite conservative and only uses features that have been proven useful in other programming languages before.


Looks like scala to me - not so half baked.


it is premature baby


"I Don't Know Swift"

So? Neither do I, and since it's a language for one specific platform, chances I will are not that high.

What's the big deal with it, that there are so many articles about it?


I'm learning Objective-C and want to learn Swift when it become 1.0. I don't care how small share of Apple from software cake will be, I love working with this highly polished platform.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: