And how do you figure they are wasting space? Ever examined the content of their apps?

It's all about distribution issues. One-size-fits-all ends up requiring App developers to ship with 1x, 2x and now 3x bitmaps for the artwork. This does inflate apps, just as having multiple interface files specialization for multiple device sizes (~iphone & ~ipad xib files, or the bloating AutoLayout + Size Classes super storyboards). It's inevitable.

But Apple is also taking steps towards reduced bitmap footprints.

As of iOS 7, there has been FAR fewer bitmaps in the core OS in favour of lighter (visually and storage-wise) user interfaces.

With the introduction of PDF-based image assets that auto-compiles all the required resolutions, developers are now in a position to gradually rid themselves of the burden of maintaining multiple bitmaps (those where getting quite a hassle in large projects where every image was a trio of increasing sized bitmaps).

In OS X, PDF images are rendered natively and bypass the asset compiler. In iOS 8, the path is paved for abandoning bitmaps altogether.

So, no, Apple is not making their OS fatter on purpose. It's the cost of added features and backward compatibility that does that.

Breaking into VPN isn't that easy.

A bajillion dollars wont work.

You need rubber.

Enough said.

I'll wait for the Netflix release.

Your certificate is authenticated by checking against it's parent certificate authority. That parent also has a parent. Rinse and repeat until you reach one of the top certificate authorities. There are seven of those (or just about?).

For as long as the parents are valid and your certificate is valid, then it's considered signed.

VeriSign, a top certificate authority back in 2001, had made the news because it's DB got compromised. All certificates underneath where disabled and the whole tree had to be re-created. Symantec bought VeriSign since.

by fricking trains with lasers beams attached to their heads.

Touché. But an alias is still a distinct identification, unlike anonymous posting, for an alias is linked to an email address and that can be traced. Besides, my linked home page clearly identifies me.

And supports anonymous posting.

Being open-sourced it'll get forked and in no time Hawking will be able to communicate with the reptilians.

Most non-coders have the same attention spam as a Linux distro.

Soon enough, their free time forks off into another party. And we're not invited.

They are called Jobs Crisis and are meant as guidance. Solutions are the realm of the secret, hidden Second Jobs.

Cities are going to be built around this.

Because already they had too much.

Actually, it was the other way around.

I started with a blank project to write a Swift framework in order to learn the language and reach a usability goal of signing into a production server, make a couple of REST calls and yield out Switch class instances in a hierarchy, through unit tests. No UI.

Then I proceeded to replicate the same thing in Obj-c using the same class hierarchy, same object model. There was a near 1:1 correspondance in the whole thing. Where things differed were where Switft could not directly handle things like NSClassFromName where an Obj-C factory was embedded in the Swift code.

The exact numbers (now that you got me out of bed) was 84,341 bytes (file system rounded to 184k) for 29 items for the Obj-C version and 249,282 bytes (324k) for 23 items for Swift.

Size comparaison is no longer possible because the Swift was frozen on ice since jully-ish while the Obj-C version given considerable more smarts, expanded object model, additional services (REST calls handlers) and additional auth method (Basic, SSO, Form with redirection support while Swift only had Basic auth).

And yes, I know Swift is a moving target (we all cringed when they promised not to promise source compatibility between releases...). I can only hope it keeps on getting better. I just dont think its mature enough for a corporate environment such as ours.

Wish I could show side-to-side comparaison of where the major differences where and why swift ended up taking more code but sharing code is not the kind of thing my employer is very keen about (they own java and we all know how that went).

I can tell you where is a lot of "as String" or "as NSString" going on, and things like foo!.dynamicType(). One line I'll replicate is this one:

                                        var version : NSString = bundle?.infoDictionary["CFBundleShortVersionString"] as NSString

Isn't it completely useless and mind boggling that I have to use "as NSString" at the end of this line if I took the express care of typing the "version" variable as NSString? Damnit, the compiler should be smart enough to do it for me. Things like that really need refinements. This ain't Hypertalk (remember that?).

Noteworthy is that I used the same coding style in both language in terms of line spacing, variables/types alignments using tabs and K&R style braces. As long as style did not contravene the convention of the language.

And I thought I was pretty nice (in Swift's favour) to not have mentioned "SourceKit crashes". But that's an XCode issue, not a language one.

The code was written for production consideration. In the end, the Obj-C version was retained. Yup. NSJsonSerializer. The was a level of abstraction around it to allow using a different (and faster) engine but not during those tests.

The wrapper includes facilities to map the resulting NSDicts to corresponding classes if they existed, or use custom class maps for customizing recipient objects based on calls. This conversion of dictionaries to class instance is recursive. Meaningful keys are also trapped on a per class basis so a -toJson round trip can be achieve, including optional retaining of unknown values (should the server object model not match the compiled classes. That was the part that Swift had shortcomings.

About them enums, I'm saying that havng to use a specific toRaw() to access the value is effin idiotic. For an inferred type language, you sure have to write an effin lot of garbage.

Wether your code is small and modular doesn't change the fact that you are still sending out entire source code out rather than simple headers that outline intended usage. When dev group x sends code your way, if the interface is full of symbols you should not directly access, wether they are marked privates still doesn't make the published code easier to deal with.

The Obj-C mangled names was in the documentation and WWDC presentation at Time of This comparative exercise.

And yes, code size was bigger in swift. Despite having 2/3 the number of files that the Obj-C version had (due to the header+mplementation duets). The exact numbers on my laptop but off the top of my head it was 234kb for Swift and 182 for Obj-c. If I could upload pics in /. Comments, I have a screenshot of both folders inspectors opened.