Swift, the new way to build iOS Apps. Here's how(iosblog.co.uk)
iosblog.co.uk
Swift, the new way to build iOS Apps. Here's how
http://iosblog.co.uk/tutorials/developing-ios-apps-using-swift-part-1/
73 comments
How do you specify public vs private members? The language seems to be missing private/public keywords, and protocols (interfaces) are automatically generated.
You can't at the moment, but you will be able to soon: http://stackoverflow.com/questions/24003918/does-swift-have-...
You can create protocols with Swift. Did you mean that protocols also suffer from the same public/private issues?
I'm aggregating resources to learn Swift for both new/existing iOS devs. Check it out at:
http://www.LearnSwift.tips
Mostly for selfish reasons to share it easily with friends.
http://www.LearnSwift.tips
Mostly for selfish reasons to share it easily with friends.
I think the author misses the point of the `let` keyword. It's not meant as the equivalent of declaring constants in Objective-C; they're main purpose isn't to be global and static like constants.
And yet you've managed to shed no light on how constants should be used in Swift.
To shed some light on the practice of using `let` vs. `var`, an excerpt from the book by Apple:
“If a stored value in your code is not going to change, always declare it as a constant with the let keyword. Use variables only for storing values that need to be able to change.”
Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l
“If a stored value in your code is not going to change, always declare it as a constant with the let keyword. Use variables only for storing values that need to be able to change.”
Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l
Thanks Andrew, I am updating the posts as I learn more. We're all still learning.
Let is fine for defining constants, but it should also be used whenever possible for two reasons:
1. It gives you additional safety against accidental reassignment.
2. It gives the compiler a major optimization hint since the value is not a variable.
1. It gives you additional safety against accidental reassignment.
2. It gives the compiler a major optimization hint since the value is not a variable.
Quick question. Can Swift be used to build OSX applications?
It all compiles using the same compiler so you can not only create OS X apps, but you can create hybrid Swift/Objective-c apps.
"programming language called Swift which replaces Objective-C"
Does Swift really replace Objective-C?
Does Swift really replace Objective-C?
Not officially yet, but in due time I think it's inevitable.
No, it doesn't. It is a great way to do 99% of the tasks most developers do. There is, and always will be, a place for Obj-C on the Macintosh platforms. Apple recognizes that most developers don't need the verbosity and tight-knit compatibility with C that Obj-C provides, and that is where Swift comes in.
I see Objective-C been shown the door if Swift is successful, it just needs a few iOS and OS X releases, with C left around for the UNIX layer.
Lets say around XCode version 10 gets released.
Lets say around XCode version 10 gets released.
That is extremely unlikely. Enough so that I would bet money on it.
Swift is targeted at the largest user base of the Obj-C language, the iOS developers. Obj-C will be around for a long time both for legacy purposes and because Swift doesn't interop with K&R C (unless that code has an Obj-C wrapper, like CoreFoundation), and C++ code. Since both Swift and Obj-C support using Cocoa libraries, any API added to Cocoa will be usable by both, but Cocoa is only one of many libraries in the Macintosh ecosystem.
Swift will become a replacement for the development the vast majority of people do, but that doesn't mean that Obj-C is going away. Apple has done nothing to indicate so; they've really been stressing the point that Swift is intended as a new tool to work along side your old one (Obj-C).
Swift is targeted at the largest user base of the Obj-C language, the iOS developers. Obj-C will be around for a long time both for legacy purposes and because Swift doesn't interop with K&R C (unless that code has an Obj-C wrapper, like CoreFoundation), and C++ code. Since both Swift and Obj-C support using Cocoa libraries, any API added to Cocoa will be usable by both, but Cocoa is only one of many libraries in the Macintosh ecosystem.
Swift will become a replacement for the development the vast majority of people do, but that doesn't mean that Obj-C is going away. Apple has done nothing to indicate so; they've really been stressing the point that Swift is intended as a new tool to work along side your old one (Obj-C).
I remember Apple representatives promising to a room full of CERN researchers that the JavaBridge wasn't going away and how Java was a first class language for Mac OS X development.
This is not even remotely similar to that situation. Obj-C is far more important & integrated than I think you realize.
I know Objective-C since 1999, when I had to port some software from NeXT to Windows, so I do know a few things about it.
From my point of view, many will jump to Swift if given the chance.
From my point of view, many will jump to Swift if given the chance.
You are misunderstanding - this isn't about which is better. Almost all new application code will be written in Swif, but swift doesn't bridge between C and the Swift/obj-c runtime, so Objective-C will continue to be required for writing the glue layer.
Yes it does.
https://developer.apple.com/library/prerelease/ios/documenta...
Additionally, this is just version 1.0. So nothing rules out that if Apple sees the language being widely adopted, other improvements in the FFI area aren't made.
https://developer.apple.com/library/prerelease/ios/documenta...
Additionally, this is just version 1.0. So nothing rules out that if Apple sees the language being widely adopted, other improvements in the FFI area aren't made.
I stand corrected, and your argument holds, however there is a great deal of objective-c code out there, so it will take a long time to go away.
Yes, and I think people should head to Swift if it fits their needs. That is very different from Objective-C losing support however. Objective-C is not going away.
How many people actually wrote Cocoa apps in Java?
The only Java apps of the era that I remember used non-native UIs, and were painful.
Whereas I'd be shocked if Swift wasn't adopted wholesale by iOS developers.
The only Java apps of the era that I remember used non-native UIs, and were painful.
Whereas I'd be shocked if Swift wasn't adopted wholesale by iOS developers.
This is not about the present.
Rather back when Mac OS X 10.0 was being released and Apple was unsure if developers would be willing to write Objective-C code.
They created their own JVM, with Objective-C runtime support (JavaBridge) and let the developers choose.
At the same time, Apple representatives did sessions at UNIX heavy user groups, like CERN, where they sold Mac OS X as a better BSD, and Java as first class language was part of the feature list.
As they saw developers were comfortable adopting Objective-C in their toolchains, the JavaBridge was dropped.
Rather back when Mac OS X 10.0 was being released and Apple was unsure if developers would be willing to write Objective-C code.
They created their own JVM, with Objective-C runtime support (JavaBridge) and let the developers choose.
At the same time, Apple representatives did sessions at UNIX heavy user groups, like CERN, where they sold Mac OS X as a better BSD, and Java as first class language was part of the feature list.
As they saw developers were comfortable adopting Objective-C in their toolchains, the JavaBridge was dropped.
"C left around for the UNIX layer"
BSD is implemented in C, so it's not left around, it's the foundation of the system. The syscalls at the base level (read(), write(), socket(), fork(), etc,) are implemented in C and so are the tools that are used by virtually every programming language at some level. C is the standard upon which several abstractions are made, not just another programming language.
BSD is implemented in C, so it's not left around, it's the foundation of the system. The syscalls at the base level (read(), write(), socket(), fork(), etc,) are implemented in C and so are the tools that are used by virtually every programming language at some level. C is the standard upon which several abstractions are made, not just another programming language.
Oh I hit a nerve.
UNIX and C are symbiotic, so any UNIX system requires C, there is no way around it.
However everything else outside what POSIX requires can be done, and should be, in a more secure and productive language.
UNIX and C are symbiotic, so any UNIX system requires C, there is no way around it.
However everything else outside what POSIX requires can be done, and should be, in a more secure and productive language.
[deleted]
BTW, part 2 is here: http://jamesonquave.com/blog/developing-ios-apps-using-swift...
And the github project is here: https://github.com/jquave/Swift-Tutorial
There is an awesome Swift Cheat Sheet and Quick Reference: http://swift-cheatsheet.co.uk
What's the deal with optionals? I am not sure what the use case are.
Seems much better then ObjectiveC
Seems much better then ObjectiveC
The docs seem to cover it pretty well: https://developer.apple.com/library/prerelease/ios/documenta...
But the basic idea around optionals is a much better and cleaner way of dealing with possible null (nil) values. Lots of other languages have and are getting optionals.
But the basic idea around optionals is a much better and cleaner way of dealing with possible null (nil) values. Lots of other languages have and are getting optionals.
What was confusing me that they would specify it during initialization.
Free downloadable ebooks can be found there: http://www.iphonetransferrecovery.com/Swift/free-ebooks.html
So is this actually a lot easier to use than Objective-C?
Not sure if that was meant as sarcasm, but I'll take it as a real question..!
Being a mediocre Objective C programmer myself, I really like the look of Swift. The difficulty of programming for iOS (or any platform) is partly the language syntax and partly the library/frameworks. I think Swift will help greatly with the language, but there is still a lot to learn as far as the UI kit and such. Swift doesn't really change the fundamental way the libraries work - the syntax is just cleaner (as a matter of opinion, I suppose).
In addition to looking a lot more familiar and certain functions being much more readable, apparently using Swift will be safer in regards to memory issues too, which is comforting for people like me who are not guru-level with managing memory. I'm personally looking forward to using it starting this week.
Being a mediocre Objective C programmer myself, I really like the look of Swift. The difficulty of programming for iOS (or any platform) is partly the language syntax and partly the library/frameworks. I think Swift will help greatly with the language, but there is still a lot to learn as far as the UI kit and such. Swift doesn't really change the fundamental way the libraries work - the syntax is just cleaner (as a matter of opinion, I suppose).
In addition to looking a lot more familiar and certain functions being much more readable, apparently using Swift will be safer in regards to memory issues too, which is comforting for people like me who are not guru-level with managing memory. I'm personally looking forward to using it starting this week.
Yes...with caveats. It looks really nice, simpler syntax for the most part but the type system seems much stronger and I think those not used to functional languages/type theory may struggle to get complex things running straight away. But when it does run it should be a lot more robust (so I think it is a good change).
I think this is false. Things that are simple in Objective-C will be simpler in Swift, with better feedback from the compiler.
Things that are complex in objective-c will also be simpler and more robust in swift.
There is a kind of complex coding using generics and the type system that would be harder for an inexperienced developer to understand, but that seems to me to be strictly additive to Objective-C.
Things that are complex in objective-c will also be simpler and more robust in swift.
There is a kind of complex coding using generics and the type system that would be harder for an inexperienced developer to understand, but that seems to me to be strictly additive to Objective-C.
I think that Swift is better and will overall be easier (I started may comment with a "Yes") BUT there will be a fair few casts and use of optional values needed when integrating anything with the general existing libraries that would cause a beginner programmer difficulties.
Example 1 - implementing a protocol (AVAudioPlayerDelagate)
You get errors unless you also implement NSObjectProtocol. The easiest way to do that is to also inherit from NSObject.
Example 2 - typed arrays/dictionaries
You can shove any NSObject in an NSArray or NSDictionary but the Swift arrays are typed (a good thing) but one that may make some things more difficult for beginners.
I suspect it is the tip of the iceberg of type related complication. This is a worthwhile tradeoff for greater safety and despite this Swift will still be easier to use overall that ObjC in my view.
It may also take a while for the documentation particularly across the internet to catch up with the quantity of examples for Obj C but this is only an interim issue.
Example 1 - implementing a protocol (AVAudioPlayerDelagate)
You get errors unless you also implement NSObjectProtocol. The easiest way to do that is to also inherit from NSObject.
Example 2 - typed arrays/dictionaries
You can shove any NSObject in an NSArray or NSDictionary but the Swift arrays are typed (a good thing) but one that may make some things more difficult for beginners.
I suspect it is the tip of the iceberg of type related complication. This is a worthwhile tradeoff for greater safety and despite this Swift will still be easier to use overall that ObjC in my view.
It may also take a while for the documentation particularly across the internet to catch up with the quantity of examples for Obj C but this is only an interim issue.
I think you're wrong about both of these. Yes, it's true that you need to inherit from NSObject in some cases, but Cocoa is complex anyway, and this is not added complexity, so it's not different from objective-c in this regard.
For #2 you are flat out incorrect. Swift arrays can be containers of AnyType, in which case they interoperate perfectly with NSArray, and this is the default behavior when working with Cocoa.
Your fear about type related complexity being a real issue seems not to be justified by your examples.
Compared to dealing with the C based fragility of Objective-C, Swift is simply better for anything that it can do.
For #2 you are flat out incorrect. Swift arrays can be containers of AnyType, in which case they interoperate perfectly with NSArray, and this is the default behavior when working with Cocoa.
Your fear about type related complexity being a real issue seems not to be justified by your examples.
Compared to dealing with the C based fragility of Objective-C, Swift is simply better for anything that it can do.
I like Swift and my overall answer is still yes that it is easier to learn than Objective C and that having to deal with types is worthwhile for the safety it brings and increased chance that it will do the right thing when it does run but it is still a barrier to a limited degree.
I remember initially struggling with the stuff in ML in the first year at university, I got it but I and many others had an initial struggle. I think that at least for beginners and maybe those coming from runtime duck typed languages Python, PHP, Ruby etc. it will be more of a barrier than you think.
For #1 in Objective C you inherit from NSObject (or a subclass thereof) for every class anyway so it is in all the examples and it isn't something that you need to do especially for a protocol.
For #2 yes of course you can have an array of a generic type but firstly you need to understand enough about the type system to create your array in that form and secondly what you get out will <AnyType> objects rather than <id>'s which get automatically cast to whatever you assign them to. But I do like the idiom for downcasting using as?:
I remember initially struggling with the stuff in ML in the first year at university, I got it but I and many others had an initial struggle. I think that at least for beginners and maybe those coming from runtime duck typed languages Python, PHP, Ruby etc. it will be more of a barrier than you think.
For #1 in Objective C you inherit from NSObject (or a subclass thereof) for every class anyway so it is in all the examples and it isn't something that you need to do especially for a protocol.
For #2 yes of course you can have an array of a generic type but firstly you need to understand enough about the type system to create your array in that form and secondly what you get out will <AnyType> objects rather than <id>'s which get automatically cast to whatever you assign them to. But I do like the idiom for downcasting using as?:
if let movie = item as? Movie {
println("Movie: '\(movie.name)', dir. \(movie.director)")
} else if let song = item as? Song {
println("Song: '\(song.name)', by \(song.artist)")
}
Yeah - the central point is that there aren't really caveats about Swift being simpler than objective-c. It's not perfect, but Objective-C has a much greater number of rough edges so is strictly harder for new users.
Is the extension keyword a form of reflection?
Are we allowed to talk about this? Isn't this still under NDA?
The developer web pages are on public URLs that don't have any developer authentication or headers that say they are non-public information. It would be quite ironic if registered developers were under an NDA but the public was not.
https://developer.apple.com/library/prerelease/ios/documenta...
https://developer.apple.com/library/prerelease/ios/documenta...
No, Swift isn't under NDA
This is based on a SA thread posted by a Swift team member that I linked in another HN thread, the post is available here: http://forums.somethingawful.com/showthread.php?threadid=363...
and the relevant quote is from the second post:
Is this under NDA?
No.
Is this open source?
Not yet. It probably will be, but I can't make promises. Right now, our repository still has a lot of history that we don't want to make public, and we have a lot of work to do before we release.
This is based on a SA thread posted by a Swift team member that I linked in another HN thread, the post is available here: http://forums.somethingawful.com/showthread.php?threadid=363...
and the relevant quote is from the second post:
Is this under NDA?
No.
Is this open source?
Not yet. It probably will be, but I can't make promises. Right now, our repository still has a lot of history that we don't want to make public, and we have a lot of work to do before we release.
Considering that the book is available from Apple for free on the iBooks store....
It's again the same boilerplate-code to create something simple as a tableview. I don't understand why they had to 'invent' a new programming language for that.
That's not why they built Swift.
Objective-C is a difficult language to work with and has decades of cruft. Swift is a start-over, but with Objective-C interop so you still have full access to the full existing APIs for OSX and iOS. Thus, the same boiler plate.
Objective-C is a difficult language to work with and has decades of cruft. Swift is a start-over, but with Objective-C interop so you still have full access to the full existing APIs for OSX and iOS. Thus, the same boiler plate.
The thing is, understanding Obj-C was never the hard part. For example, understanding ARC, weak vs. strong (and now unowned [1]), and the various libraries is what took time and experience. Swift doesn't solve that at all and in fact offers its own oddities like the below:
“You indicate type methods for classes by writing the keyword class before the method’s func keyword, and type methods for structures and enumerations by writing the keyword static before the method’s func keyword.”
Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l
I do think the new language is neat and will be fun to work in, but it doesn't solve the parts that tripped up many people when working in Objc.
[1]
“You indicate type methods for classes by writing the keyword class before the method’s func keyword, and type methods for structures and enumerations by writing the keyword static before the method’s func keyword.”
Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l
I do think the new language is neat and will be fun to work in, but it doesn't solve the parts that tripped up many people when working in Objc.
[1]
@lazy var asHTML: () -> String = {
[unowned self] in
if let text = self.text {
return "<\(self.name)>\(text)</\(self.name)>"
} else {
return "<\(self.name) />"
}
}
Is there ever a time when you don't want a weak/unowned self in a block? Perhaps this should be made the default in Swift? (I understand that the Blocks spec requires all captured variables to be strong unless otherwise specified.)
>>understanding Obj-C was never the hard part.
It seems important for traction to make the beginning learning curve non-steep. See PHP, Python, etc.
It seems important for traction to make the beginning learning curve non-steep. See PHP, Python, etc.
>>Swift is a start-over
For me, Lua+LuaJIT+C/C++ as a cross-platform solution to everything is a start-over, and it gives me all kinds of things I don't get from Swift, one of them is the ability to make decisions for myself about how the basic structures of the application are going to be managed and under what conditions, either in the VM as needed or out of it, and with whatever current frameworks you want to interface with (e.g. everything). Plus, LuaJIT for the win. Plus put it, simply everywhere. (On:iOS,Linux,OSX,Win,Web,&etc.)
Swift is interesting, but I will not again be swayed to the darkside of using platform-provider-provided-platforms to achieve platform nirvana, for that harness contains nails upon which to be pinned.
Planks can be assembled of many kinds, but mine is shiny enough without another dastardly developer-mindset-grab by a very, very serious cult.
(<<--MacbookPro'er)
For me, Lua+LuaJIT+C/C++ as a cross-platform solution to everything is a start-over, and it gives me all kinds of things I don't get from Swift, one of them is the ability to make decisions for myself about how the basic structures of the application are going to be managed and under what conditions, either in the VM as needed or out of it, and with whatever current frameworks you want to interface with (e.g. everything). Plus, LuaJIT for the win. Plus put it, simply everywhere. (On:iOS,Linux,OSX,Win,Web,&etc.)
Swift is interesting, but I will not again be swayed to the darkside of using platform-provider-provided-platforms to achieve platform nirvana, for that harness contains nails upon which to be pinned.
Planks can be assembled of many kinds, but mine is shiny enough without another dastardly developer-mindset-grab by a very, very serious cult.
(<<--MacbookPro'er)
You are free to use one of the many tableview helper libraries if you aren't happy with the tradeoff between flexibility and convenience that the built-in API makes.
You could argue that the frameworks should ship with such a wrapper, but I'd personally rather that they spent their time making difficult things easier than making easy things easier.
You could argue that the frameworks should ship with such a wrapper, but I'd personally rather that they spent their time making difficult things easier than making easy things easier.
I think the problem is with the boilerplate of objective-c. I tried to make something last night and I'll be honest, I felt like I was in Go or Scala (functional) more than I was in a C-ish style language. I'm not gonna lie, I was looking at some of the docs with a "WTF" look, but I'm a big proponent of functional programming. In the few instances that I've used it, my code has been very concise, but not always easily readable.
What features of Swift do you find functional? What kind of functional features are you using? I'm asking out of genuine curiosity, not to put you on the spot. Thanks!
Not to speak for the OP, but two features bear resemblance to functional programming languages:
1) Function Types ( = higher order functions)
This allows functions to be passed around as function parameters or return values.
2) Immutable variables via let
let a = 1 // a is always bound to the constant 1
a = 2 // error
1) Function Types ( = higher order functions)
This allows functions to be passed around as function parameters or return values.
2) Immutable variables via let
let a = 1 // a is always bound to the constant 1
a = 2 // error
[deleted](2)
I couldn't find any built in list/map/set comprehension. Did they leave it out or did I just miss it?
A big one is sum types (which it calls enum, a la rust), which come from ML.