"But is Swift really so easy (or at least as easy as anything else in a developer's workflow)? This new walkthrough of Interface Builder (via Dice) shows that it's indeed simple to build an app with these custom tools... so long as the app itself is simple."

What? Seriously Slashdot, if you're going to have Apple articles, at least have submitters that have half a clue what they're talking about. "How good is Swift? Let's find out by using Interface Builder which is not Swift at all!"

Swift and Interface Builder can be used together, but they're not strongly related components. They're related like a WYSIWYG web tool, like Dreamweaver, and JavaScript. They're both helpful to get what you need done, but they don't replace each other. To give you an idea of how true that is, Interface Builder first shipped in 1986. Now, it's advanced a lot since then, but it's almost 20 years older than Swift, so obviously it's had a long life away from Swift.

Duh you can't create a big complicated app with only Interface Builder like you can't create a big fancy web app with just the visual components of Dreamweaver. You've got get down and actually write some code, which you know, is what Swift is, Swift being a coding language and all. So I find it really odd that this post is talking about reviewing a programming language in the context of trying to use a completely different tool that is not that programming language.

Sure, but I would assume any manual memory management system worth it's salt is doing retain/release. Most of the C++ big libraries do it.

Two things:
- Deallocation cascades are inherent in memory management. Neither reference-countless memory management nor garbage collection can avoid it. So I'm not sure what the point here is.
- As far as latency on dispatches, Apple is using tagged pointers (http://en.wikipedia.org/wiki/Tagged_pointer) which is using some room in the pointer for holding the reference count. In practice, this means means there is practically no latency for messing with the retain count.

Which is also a problem with Garbage Collection...

I don't see how it is at all. Results are instant. Overhead is far less. Pretty much every claim here needs citation. It's hard to see how an entire process constantly analyzing object references is less overhead than pre-handling those references. Memory utilization? I have to burn a bunch of memory on a garbage collection process, and then watch my memory climb and then drop off a cliff constantly while I wait for the garbage collection to run, while retain counted count generally stays with a pretty stable allocation count because it's instantly computed. Puh-lease.

I saw your claim below that GC is identical to retain/release in behavior. It really is not. If I clear out a reference in Obj-C or any other retain/release language, the memory is instantly freed. In Java, I have to wait for another run of the garbage collector, which can take a while unless I manually trigger it. Yes, YOU don't have to wait for anything in the code. But ignorance is bliss.

Here's basically the comparison I'd use: Retain/release is like having an incinerator you throw your garbage into. Garbage collection is like... well... having a garbage truck. In both cases when I'm writing code I can just throw things away in my trash bin and pretend it's not there. With retain/release/an incinerator, the memory is actually gone as soon as I throw it in the trash bin. With garbage collection, I've thrown it in the bin and forgotten about it, but that doesn't change that the trash will continue piling up until the trash guy comes, which may still be a bit away. The large amount of piled up trash is also a problem, and actually makes the cascade problem you were concerned about with retain/release WORSE. Instead of a few cascade relationships being dealloc'd at once, all the dereferenced objects are going to pile up, wait for the garbage collector, and then the garbage collector is going to have to pour through thousands of relationships all in one go, causing the program to come to a halt while everything waits for the garbage collector to catch up. I've had to clean up a few Java messes that had that problem by manually firing the garbage collection to spread out the load.

That's not what the term CLR actually means (http://en.wikipedia.org/wiki/Common_Language_Runtime) nor does that necessarily apply to Swift. Swift does indeed have a slightly larger core function base than Obj-C, but still not enough to build an entire app. For example, there is no I/O (either file or console, except for printing to console), networking, or GUI support that is part of the core implementation. You won't be building much with the Swift core library by itself.

Here's a list of every single function present in the Swift standard library in June. That every single function can be listed on a web page should tell you that it's nowhere near as expansive as the Java or .Net standard libraries:
http://practicalswift.com/2014...

It's primary API intended use API is Cocoa, but that is entirely un-attached from the language. As of posting time, Cocoa is still entirely written in Obj-C, so the primary library intended for use by Swift is not even written in Swift itself. But I digress, Swift itself definitely does not have a very large standard library. When Swift is ported to other platforms you won't see Cocoa anywhere with it. And Cocoa is different on iOS and Mac, so even if you're sticking to Apple platforms you don't have a common library between the platforms. So right there, even if we decide Cocoa could be called Swift's standard library (which it isn't) it fails the fragmentation test you've put forward.

Not to mention, the R in CLR stands for runtime, and we're talking about the Swift standard library, not the runtime (which is the Obj-C runtime, not the Swift standard library anyway.)

Oooof. So much wrong in a single post. Let's review....

Swift definitely does not do garbage collection. Obj-C actually had a garbage collector for a while (Swift never has) but it was optional, and support for it has ended.

What Obj-C has now is something called ARC (Automatic Reference Counting). At compile time (not run time) the compiler does a static analysis of the code and determines where it needs to add memory management code, and then quietly does so for you. This means there is no run time hit, and behind the scenes everything is still manual memory management. Sometimes you still need to hint to the compiler what to do (usually when trading pointers with C), but 99.99% of the time it just works.

Swift is built on the same runtime as Obj-C, so it inherits ARC. With Obj-C, you can turn ARC off and continue writing manual code, and I'm not sure if Swift allows the same, but it's the exact same behavior. Swift uses the same manual memory management functions as Obj-C in the background, while in the foreground the developer still writes without memory management. I'm not sure what this "benefits of a CLR" is you're talking about, as that's a term usually associated specifically with the Common Language Runtime of the Microsoft language family, but it's neither here nor there. Swift does not run in a VM (it's natively compiled just like C or Obj-C), and it does not have a garbage collector. (But the compiler will add your memory management code for you.)

As far as Swift being multi platform, Swift most definitely for sure runs on OS X, so the language choice has absolutely no bearing on what platforms you want to port between. I have a partially Swift project going on the Mac right now. Swift is definitely not iOS only. Beyond that, it looks like Apple will be working to open source much of it and move it to other platforms.

I'm not sure what this business is about Swift being for lightweight solutions. It runs on the same runtime as Obj-C, it's starting to be as fast as Obj-C, and it interoperates with any Obj-C code (as Obj-C will interoperate with any Swift code). Apple has never messaged that it's for lightweight apps, and developers aren't treating it that way. I still prefer Obj-C, but I'm not sure what that bit is about at all.

As I said I'm going to stick it out. Ended up using my 5 yesterday for a bit while recovering from 8.0.1 and it still seemed slightly big to me. For now I still find myself thinking more consciously about how to use it ( i.e. if I need to shift hands etc. ) than my old phone; but hopefully that will improve over time. I haven't had it slip from my hands as much the last couple of days which is big improvement.

Heh. No, for cars that's what do not distrub mode and hands free operation are for if absolutely necessary. I love that my car ( prius ) has a built in text option to respond "I am currently driving" in the bluetooth integration.

There are lots of valid reasons to use a cellphone one handed. For example when shopping, it's much more convient to be able to pull up member cards etc. without having to sit everything down or shift it around. Using the phone on breaking while drinking, or eating, etc. I could type a very long list here of other uses... but I could care less about playing along ( though only slightly less, I did list a couple examples after all :P )

BTW did you know that the touchtone ( DTMF ) actually allows for 16 keys. 0-9, octothorpe (#), star (*), and A-D.

I bought an iPhone 6 recently figuring I'd skip the obviously too big 6+. While I like most of the features I've found even the base 6 is a too big. My thumb doesn't even reach all the way across the bottom of the screen and only about half way to the far corner if I'm holding the phone in a good stable grip. Even reachability mode doesn't get everything in close enough. I wish that it shrunk the screen slightly as well. I find that I either have to carefully balance the phone or use two hands. I've already drop it a few times trying to reach the stuff just a bit to far, and the area between my thumb and rest of my hand hurt the first few days after I got the device from trying to force my thumb to reach across. To be honest I was expecting it to be a bit big as there is a small part of an iPhone 5 screen I can't reach without shifting the phone but that bothered me only occasionally. Going to stick this one out, but not sure I want another large phone, especially since I carry a tablet* with me most of the time. Granted I guess I have short hands, my thumb is almost 1.5" long.

* - Okay, sometimes I carry up to 3 with me so that I have Android, iOS and Surface covered; as part of checking to see how stuff runs on different OSes. And yes tablets are much bigger, but they are two handed devices.

The iOS 8 app upgrades are pretty much for things like being able to target new/any screen sizes. If you're on an existing device, that doesn't mean much. I don't think there is anything in the new SDK that would imply a performance decline in apps that adopt it.

The X.0.0 upgrades are pretty well known for including slower/unoptimized drivers and code paths. Apple is usually in a hurry to get the release out the door and they don't do all the optimizations they should. Usually by X.0.1 or X.1 they get things cleaned up. So it doesn't surprise me that 8.0 is a little pokey. 7.0 had basically the same issues.

Heh. The dream of the 90s is alive on Slashdot.

It wouldn't be the first. Java and HTML/JavaScript long beat Android to the punch. In fact, HTML/JavaScript does it better. OpenGL ES on Android isn't exactly platform neutral (my Mac doesn't have an ES driver for it's Nvidia/Intel hardware so the best it can do is software rendering, while WebGL is abstracted so it can render it perfectly.)

We can use the lessons from it's forebearers to tell why it won't be adopted in the marketplace as a universal app solution. Both Java and HTML/CSS make universal app deployment technically a reality. For the past 20-ish years I've been able to write a Java app and deploy it on any platform. HTML/CSS run well on both desktop mobile devices as well.

The usability problem that is always run into is that by pretending all platforms are the same, the usability strengths of each platform are ignored. A mouse and pointer is a really really basic example that both iOS and Android can handle, but what about security models? The Android security model, OS X security model, iOS security model, and Windows security models are entirely different. Apple platforms like to give capability access capability by capability, at the time they are accessed. Android doesn't work like that at all, it wants everything up front. So an Android app trying to access my Address Book doesn't at all have the API to do so on my Mac.

Or what about contextual menus? I expect those on a Mac but Android doesn't have them. Macs also draw differently. They expect scrollable content to slow under window sidebars and titlebars. Android doesn't expect that. You can't make an Android app act like it's running natively on a Mac without reflowing all the widgets in the window. And Android apps don't have multiple windows. I expect that on a Mac. Mac applications also have toolbars (as do Windows applications) but Android doesn't even have an API for that. All Mac applications have a re-arrangable toolbar, but Windows doesn't. Mac and Windows computers can have multiple GPUs, which means that Android would need an API to handle a window having to shuffle from one GPU context to another, and I don't think it has that... There are also font layout issues. Both Mac and Windows have different default fonts which could dramatically shift around line spacing, and what text fits where. Mac at least also has contextual definitions when you right click on a word. Will Android apps have that? My Mac apps support QuickLook in the Finder, but there isn't anything like QuickLook under Android to abstract into. I also like searching with Spotlight, but Android apps don't have any Spotlight vendors. Do Android apps ask for my user name and password to do secured operations? Again, Android apps don't have any idea of on demand security, and I really don't want to have to enter my admin username/password every time I launch an Android app. Same thing would apply to UAC.

If you hadn't stopped reading by now, you might be starting to get my point. The reason Java failed to take the desktop world by storm is that not all desktops are the same or even have the same capabilities. Yes, as you suggested, you can go down the road of adding a bunch of APIs to handle all these different scenarios. But then you're back to writing a bunch of code to support a bunch of different platforms. It's right back where you started. Java didn't end up saving time for multi-platform because the dream of writing once and running anywhere was unobtainable for desktop GUI applications, and it still is for the same reasons. It's technically possible, but the same user experience everywhere was unacceptable to users and unworkable. Even Microsoft wasn't crazy enough to believe they could get away with write once, run anywhere for Office. Office on the Mac runs/looks different than the PC version because when they tried to make the Mac version look like the Windows version Mac users revolted. I've had Windows Office users equally pitch a fit when they've been set up with the Mac version of Office.

HTML/JavaScript sidestepped this by defining very broad APIs and letting the platform make inferences as to how things should work. It was also shaped by the communal cooperation of all the different platform vendors to build something that could be molded to work on everything. Android's API does not leave much room for the native platform to reinterpret application logic at all, and it wasn't written by the platform vendors together.

It wouldn't surprise me if Google added this capability to Chrome. It would surprise me if there was any wide uptake.

This works because iMessages are stored on your device, and not the server. So when you change your password, and update your devices password's the iMessages will re-transmit their history to other devices. So no, not wrong.

If you pull all of your devices offline and reset them, and then take them back online, the history won't be available to sync so all your messages will be gone. Apple does manage delivery, but the initial handshake is done by a peer to peer key exchange, so while Apple is caching and flinging data, they don't sit in the middle of the key exchange, so they can't read messages.

Email is another matter. The nature of how email works means they probably have some sort of access.

All the complaints about how buggy iMessages is make sense when you look at all the mechanics that they go through to keep messages secure.

You're right. It's faster than dial up. That STILL doesn't make it broadband. The definition of broadband is not 'It's faster than dial up."

If we're still calling the 100 mbps cable connection I have now broadband 30 years from now because it's faster than dial up... Well that's just going to be stupid.

Yeah it's a real issue. And in many environments even installing another browser isn't an option for various reasons. Going to be a pain for those websites that want to reach pre-XP SP3 machines once root CAs stop issuing SHA-1 certs.

Because I had to worry about clients using XP SP2, I'm stuck using ROT-1. But I found that if I use it 26 times, it gives just as good protection and also avoids the inverse directional issues ROT-1 has with some implementations.

That's like saying I should be able to advertise my bicycle as a car if I'm selling it in an area that is still using horses.