
The Death of Cocoa - andrewbarba
http://nshipster.com/the-death-of-cocoa/
======
jawngee
I like Matt, but I think he's wrong.

Objective-C isn't going anywhere, just like C++ hasn't gone anywhere, nor has
C left the building either.

There are 124 public frameworks in the 10.10 sdk, 357 private ones. While a
good chunk of these are written in Objective-C, a good deal of them are
written in C, or Objective-C with the guts in C++. AVFoundation, for example,
is mostly C++ in the "backend".

The amount of effort it would take to move those to Swift would be fairly
substantial, and with no real gain. This doesn't mean that new frameworks
won't be written in Swift, but still interoperable with Objective-C, this will
probably happen - though I doubt it'll happen in my development lifetime. So
we are looking at a gradual replacement of frameworks, or superseding with
newer ones (QuickTime -> AVFoundation -> ???).

He brings up Carbon, but erroneously as Cocoa actually predates Carbon and
Carbon was only meant to serve as a compatibility bridge from OS 9 to OS X.
Carbon was meant to die.

I don't plan to switch to Swift unless I absolutely have to. I spend 14 hours
a day developing for OS X, but my problem isn't Objective-C, it's the
ambiguous documentation and mildly temperamental behavior of certain
frameworks _cough_ AVFoundation _cough_. I didn't need Swift, wasn't looking
for Swift. I have nothing against it, I'm sure it's awesome, but language
isn't my issue at this point, so I don't really have much to gain by it.

~~~
cageface
My initial enthusiasm for Swift faded pretty quickly when I tried to actually
use it. The tooling is buggy and unstable. Code that calls Cocoa APIs is often
no less verbose than ObjC. Every XCode release brings syntax-breaking changes.
It feels like the language design was compromised by the requirement to bridge
to Cocoa; all the strictness of the language is just a facade when you're
manually casting every time you deal with a collection, for example. I guess I
like the strict handling of nils in principle but in practice I've found this
often means the user gets a crashed app instead of a more tolerable bug.

I'm getting out of iOS/OS X coding anyway for other reasons but even if I
weren't I certainly wouldn't use Swift for production yet. Apple should not
have pitched Swift as production-ready at WWDC. I think a lot of us would be
less critical if it had been billed as the technology preview it was (and
still is).

~~~
archagon
I'm really loving Swift, but Xcode has gotten _atrocious_. I have a keyboard
app with 8 different sub-keyboards, and 80% of the time, when I open my
project, Xcode gets stuck in indexing. You can't build, you can't close Xcode,
you can't do anything but force-quit and hope it doesn't happen next time.
There are also frequent SourceKit crashes, random crashes to the desktop, and
incredibly laggy typing and auto-completion. WTF?

"I guess I like the strict handling of nils in principle but in practice I've
found this often means the user gets a crashed app instead of a more tolerable
bug."

How are you using optionals in such a way that it crashes your app? I've found
that using optional chaining and the "if let" block guards your code against
accidental nilling even more. My rule of thumb so far is to never ever use the
"!" operator except for initialization. I've found that whenever I get a crash
— which is rare these days — it's usually because I forced an optional, or
possibly used "as" instead of "as?".

"All the strictness of the language is just a facade when you're manually
casting every time you deal with a collection, for example."

I dunno, I kind of like the explicitness of (cocoaArray[i] as? ABMyObject).
It's no more work than you'd be doing with a generic NSArray anyway, and you
get type checking for free. (And, of course, all your Swift native arrays and
maps don't have to follow this pattern.)

~~~
ktran03
Xcode 6.1.1 fixed most of the problems you mentioned in the first paragraph
for me. Sourcekit crashes was the biggest annoyance, ughh.

~~~
archagon
I'm on latest and the indexing issue is just getting worse and worse for me.

~~~
almassapargali
Try removing (backing up) all folders from ~/Library/Developer/Xcode/iOS\
DeviceSupport. It helped for me.

------
gilgoomesh
Holy clickbait headline, Batman.

Yes, Carbon has been replaced in the past but that involved a $400 million
acquisition and 10 years of continual complaining, kicking and screaming from
established Carbon users who had no desire to change. I doubt it's an example
of how future changes will occur.

Replacing entire application frameworks is hard. Super, super hard. It seems
like it might be simple to start by replacing Foundation with Swift's standard
library but actually, replacing Foundation would mean replacing every Cocoa
framework since they all rely on it. And there's a gigantic amount of work in
those frameworks; 25 years of development (all the way back to the early NeXT
days).

I think this is why Swift includes such extensive support for Objective-C
interoperation: Apple expect Swift will need to link against Objective-C APIs
for a long, long time.

I think we're much more likely to see a major deprecation sweep through Cocoa
in one or two years time (probably once Swift finally has all the features
Apple have hinted are coming). Not deleting things, per se, but simply saying
"these things look ugly or silly in Swift" so use these other things instead.

~~~
e28eta
And what's the practical difference between death and deprecation? As the
Swift standard library grows, and it becomes the widely preferred language for
iOS and Mac development, isn't that a form of death?

~~~
gilgoomesh
Simply: I don't think Apple are going to suddenly replace Foundation (or any
other Cocoa framework) with a Swift only version. They'll just iterate the
frameworks they currently have to make them a little more modern and a little
more Swift friendly.

Not that they could anyway: according to Chris Lattner, Swift is currently 1-2
years away from including a language "resilience model" that would allow safe
linking to frameworks built with a different version of Swift. Until then, the
Swift standard library needs to remain as small as possible because it is
statically linked into every Swift app (it can't be shipped separately with
the OS).

------
CookWithMe
I had the same feeling when I did my first side project in Swift earlier this
month. My main experience is with CoreData.

An example with 1:n relationships: CoreData returns and expects an (untyped)
NSOrderedSet. Now I may either keep the NSOrderedSet, but have to cast each
object I want to use - and my Swift code is just as bloated as Obj C would be:

    
    
      let obj = mySet[0] as MyClass
    

instead of:

    
    
      let obj = mySet[0]
    

Plus, map/reduce etc. won't work on an NSOrderedSet.

Or I create a typed Array from the NSOrderedSet, which is fine to work with in
Swift - except that it is not managed by CoreData anymore. So I'd have to be
careful to synchronize with CoreData manually, and it's not just saving that I
have to watch out for, but also other operations like rollback etc.

Another example is NSNumber. NSNumber needs to be manually mapped to Int,
while the other direction works automatically. That makes sense when it is
unknown whether NSNumber is an Integer or a Floating Point Number, but in
CoreData I have specified that it's an Integer 32... (Well, I think it was
similar with Obj C, actually).

So, working with Swift in the Playground felt like a huge improvement over Obj
C at first, but then working with some Cocoa APIs it started to feel ... more
clunky again.

I think it was/is similar with Scala. If you can stay in the Scala libraries,
awesome. It is a huge improvement over Java. But Scala won't automagically
turn a terrible Java API in a great Scala API. Yes, you'll save a couple of
semicolons and type declarations, but it's not that big of an improvement.
Thankfully (in Scala), there are a lot of better frameworks or wrappers for
existing frameworks by now. I guess Swift will have to go the same way...

~~~
bjustin
I don't know about NSOrderedSet, but for number properties on Core Data
objects, you can avoid NSNumber entirely by using primitives. There is an
option when generating model objects in Xcode to use primitives, which will do
so for you. Properties may be a mix of primitives and objects, too. E.g. if I
have a "Car" model that has "tankSize" and "milesPerGallon", I could have
"tankSize" be a 32-bit int represented by a int32_t, and "milesPerGallon" a
32-bit int represented by a NSNumber*.

I'm using CoreData via Swift and find it mostly more enjoyable than
Objective-C.

------
Normati
This feature of strings is cool! It sounds like the end of the Unicode
encoding mess that most languages drag the programmer into:

"One of the truly clever design choices for Swift's String is the internal use
of encoding-independent Unicode characters, with exposed "views" to specific
encodings:

A collection of UTF-8 code units (accessed with the string’s utf8 property)

A collection of UTF-16 code units (accessed with the string’s utf16 property)

A collection of 21-bit Unicode scalar values, equivalent to the string’s
UTF-32 encoding form (accessed with the string's unicodeScalars property)"

~~~
dilap
Haven't used Swift of its strings yet, but I have used string/unicode in
python, NSString in Cococa, and string in Go. The only one that hasn't bit me
in the ass is string in Go; the approach they take is a sequence of bytes,
utf8 encoded by convention (which is easy to follow); there are methods to
work with unicode code points when you need to, otherwise it's just bytes.
It's simple, well-defined, non-magic, and doesn't screw you over.

~~~
bpicolo
Python 3 uses utf8-as-a-default as well. Not to mention you can easily specify
the encoding as well in python 2. Never bites me.

~~~
dilap
Wish I had documented my exact frustrations, but it wasn't not being able to
choose the encoding...something more of the flavor of:

Most of the time I just trying to shuffle bytes from one place to another, and
didn't really care about the contents of the bytes, but I hit numerous bug
because of exceptions due to things like "external data wasn't valid utf8"
(NOT helpful to throw an exception here), and bugs caused by 'str' vs
'unicode' confusion (made more tricky by lack of static type system).

The one time I did actually need to do some calculation involving unicode I
got burned by behavior that didn't match the documentation, because my
bullshit package-manager-provided variant of python had some insane compile
time option that made it pretend utf16 code units were the same thing as
actual utf code points, to which I can only say "ha ha ha... _fuck those guys_
".

Can't speak to python 3, haven't used it, probably never will :)

------
marstall
A lot of people on the thread are focusing on how hard/not hard it would be to
make a wholesale transition of Cocoa from one language to another ... I'm
coming from the world of Windows, which might offer an instructive history. In
short, Microsoft would think nothing of making a change like this.

The Win16/Win32 API was a thing of beauty and was the whole universe for
several years. It was written in C.

Then MFC came. It was the new hotness in the late 90s and it was based on C++.

Early 2000s. Goodbye to C/C++. If you want to build a native Windows app, you
would probably think first of C#, which used a completely new, non-C Windows
API called Windows Forms.

Today ... want to write a Windows app? Visual Studio's new primary language
for you is Javascript, talking to a complete javascript-native API for
windows.

And let's not forget Visual Basic, the most popular language in the world,
which has its own Visual-Basic esque toolset and Windows API.

Microsoft certainly has a much bigger vision for its development tools, and a
much longer history. Its very first product, after all, was a programming
language (MS Basic) - and developers have in a sense been a much larger target
market for them than they have for Apple in their shared 30+ year history.

But now Apple, with its skyrocketing income, surely must be aspiring to the
herculean scale of Microsoft's year-in/year-out dev tool undertakings.

My bet is Apple will come out with a Swift-native version of Cocoa within 18
months or so. ObjectiveC Cocoa will be supported for a LONG time (I believe
all the above MS dev technologies are still usable in some form or another
...)

------
jarjoura
Swift has the potential to become a great systems language but I am cautious
it will replace Foundation/AppKit/UIKit. For example, a Swift string IS an
NSString (at the moment at least).

It's impossible to know for sure, but when you look back 15 years ago when
Cocoa was the new and shiny to the old-trusty Carbon. Apple was actually
writing software in Cocoa internally. Everything they were building towards
extended from the NeXT Objective-C world. Though true, they didn't publicly
commit to Cocoa 100% until OS X 10.4, but you better believe internally they
were always in. It's just the world didn't see it until the "We're rewriting
the Finder in Cocoa" campaign was announced.

At Apple right now, no one outside of the compiler team is working on anything
interesting in Swift. It's still locked away from them. To be fair, it's an
evolving language and will cause a lot of heartache for everyone until the
language has been baked in more.

I know Mattt is excited for Swift. Plus, a lot of developers are already doing
some really cool stuff. So we shall see in a couple years how the story plays
out.

~~~
e28eta
Isn't it just an implementation detail that NSString and String are the same?
Couldn't the implementation diverge, as necessary, without breaking things? We
also have toll-free bridging to CF types.

------
philliphaydon
"Apple is a company with a long view of technology. It's really difficult to
tell whether a technology like JSON is going to stick, or if it's just another
fad. Apple once released a framework for PubSub, which despite not being
widely known or used, still has to be supported for the foreseeable future.
Each technology is a gamble of engineering resources."

Apple doubted JSON would be around?

~~~
tolmasky
JSON was invented (discovered ;) ) in 2001, the website went up in 2002. Major
services like Google and Yahoo were providing their data in JSON format in
2006. If this article is correct, Apple didn't include JSON functionality in
Cocoa until _2011_ , that's 9 years after the public website and 5 years after
inclusion in major web services. This is an _eternity_ in technology time. I
personally find the explanation that "each technology is a gamble of
engineering resources" in light of this a bit ridiculous.

As an aside, I think the lack of built in JSON support in Swift remains
telling of Apple's simply puzzling take on this new programming language. When
Apple first announced that Swift would be good for both "systems programming"
and "scripting", it set off red flags in my mind. That statement is usually
only made by people that have worked a majority in one of these domains, and
doesn't really understand the other that well. In my mind, if the second you
want to grab some data off the internet in the most popular format you either
need to 1) drop down to a bridge API that everyone agrees is terrible (as
mentioned in this article, NSJSONSerialization is even more frustrating with
the optional stuff), 2) download a third party framework, or 3) learn monads
or roll your own, then this does _not_ feel like a scripting language by any
stretch of the imagination. Just look at this:
[https://twitter.com/andy_matuschak/status/549268259871002624](https://twitter.com/andy_matuschak/status/549268259871002624)

~~~
quesera
> If this article is correct, Apple didn't include JSON functionality in Cocoa
> until 2011, that's 9 years after the public website and 5 years after
> inclusion in major web services.

JSON was added to Ruby stdlib in 1.9.2, released in August 2010. Available as
a gem for years prior. Ruby was probably slow because YAML was the anointed
format, and JSON isn't distinctly _better_ than YAML.

JSON was added to Python modules in 2.6, which was released in October 2008.
Likely available as an egg prior, but I don't remember.

There were Objective-C libraries for JSON well before 2011 too. The first one
I remember using was in June or so of 2009.

So, I half agree with you. It might be hard to remember nowadays, but JSON
wasn't universally seen as a Good Thing initially. It came with a lot of
JavaScript baggage, which in some circles hung around for a loong time.

But Apple was definitely late to the JSON party, and it was disappointing at
the time.

~~~
tolmasky
The biggest difference being that both Python and Ruby were module cultures,
so saying that a gem existed actually means something. On the other hand, Mac
dev didn't have Cocoapods until 2011. Apple dev at the time (and I'd argue in
large part still today), was mainly using Apple's monolithic frameworks (and
downloading AFNetworking source code to include in your project), so it was
much more important for it to be included in the standard library. However,
the point still stands that we now have a new language that still does not
have this basic support.

~~~
quesera
True, the ObjC culture was undeniably different than the CPAN-inspired code
sharing cultures of Ruby and Python. So there were fewer quality libraries.

But the libraries did exist, and Apple devs in general came from a background
of C and UNIX programming, where static libs weren't an oddity.

This is all different now, due to the huge influx of ObjC devs from the web
world. Expectations have changed, CocoaPods emerged in response, etc.

But I have no explanation for the Swift situation, except that it looks and
feels like ObjC and Cocoa. I think Mattt's point is that it needn't.

This might be a bit of C culture still showing through...any other conversion
process would be, ultimately, magic. ObjC has never been about brevity or
implicitness.

------
masters3d
I think vanilla cocoa is being replaced slowly by cocoa touch. They will
probably rename it and then force cocoa touch onto macosx. I don't see
foundation changing much though. Maybe foundation touch "universal" is coming
;)

------
tempodox
I think Swift has promise, but I don't expect it to replace Cocoa anytime
soon.

My main complaint about Swift is the lack of available documentation. In C
languages, you have static header files which you can read and learn about
APIs & types / classes / whatever. API documentation in Swift is generated on
the fly when you search for a specific term that happens to be a function /
type / protocol / whatever. But how do I find out what functions / methods are
applicable to, e.g. a String? There is no chance to just `grep` existing
headers for 'String' or some such trick, to find everything related to that
type. This may seem minor to some, but for me it is a major stumbling block
making Swift effectively a black box for me.

------
imron
>Will Swift unseat Javascript as the only viable web scripting language by
adding interpreter to Safari?

Adding Swift to Safari would be an interesting development

~~~
rezistik
About as interesting as adding Dart to Chrome.

Except with none of the market share.

~~~
masters3d
Only every iPhone and iPad out there.

~~~
oblio
Awesome. Let us make Apple-only sites! /sarcasm

~~~
tomelders
I would imagine there would be a javascript transpiler so the browser can
request .js or .swift file depending on its own capabilities.

As a web dev myself, I'd love this solution.

------
gurkendoktor
This has been my biggest worry since Swift was announced. I am really happy
with Foundation (much more than with AppKit or post-iOS 6 UIKit). But if 2014
Apple were to reinvent it, I am sure it would suck.

Has Apple recently released anything that they have dog-fed to themselves
before, and that was not buggy? Swift itself is a good example of how Apple
seems to work now: Let engineers build a toy, release it as v1.0, wait for the
early adopters on Twitter to sing their praises, then maybe start using it
internally. Maybe.

I wish Apple had instead designed better frameworks for UI and persistence and
then built a language to make working with them easier.

------
msoad
With Objective-C they had to do a lot of things in higher level (standard
library or the framework). With the new shiny language that had tons of
features that are remained unused it makes sense to slim down Cocoa and move
things to language level.

A good example is string interpolation. Swift makes it unnecessary to have
things like `stringWithFormat` in framework level.

------
ZanyProgrammer
I gave up on Swift when I couldn't just do an import CommonCrypto, and had to
do hackish bridging workarounds. For a language that was supposed to be much
higher level and just work, it really didn't.

------
bovermyer
Am I terrible for loving the minimalist design, and simultaneously wondering
how I can read the archives from above the fold on the home page, instead of
reading the article?

~~~
cportela
Nope, I love it too. I made my personal website the same way. Long live
meaningful and well written text being the focus.

------
michaeljbishop
I agree with the click-bait sentiment. This article says "Cocoa" and then goes
on to talk only about Foundation. But "The Death of Foundation" wouldn't get
all the clicks.

I also agree with the pro Objective-C sentiment. I do understand that some
developers thought it strange and just because the syntax of Swift looks
closer to what they are accustomed to, they are ready to throw out the baby
with the bathwater. Dynamic-dispatch is an _excellent_ design for making GUIs.

------
alblue
I've been working with Cocoa for 20 years, back from the NeXT days. I
certainly see where Swift is going, and there's a possibility that it will
surpass Objective-C in the future, but for the time being they will live
together in relative peace.

Objective-C provides a number of patterns that aren't available in Swift due
to the dynamic nature. For example, transparent network proxies are possible
in Objective-C using message forwarding techniques. Similarly, it's possible
to swizzle method implementations under the covers so that a replacement
mechanism can be called instead. These don't sound like much but they are used
to implement some powerful mechanisms, like the observable patterns and key
value binding that is built upon it.

Swift is really a much better C++ than a better Objective-C. The language is
terser and the underlying compilation mechanism can perform more optimisations
than C++ (or Objective-C!) can. For example, Swift has the concept of a module
(aka framework) and the Swift compilation can provide module-visible functions
that can be called between different classes but still be optimised at the
module level (e.g. in-lined).

There are a lot of compromises in the language at present; it can fallback to
generate an Objective-C class which then means that the Swift optimisations
aren't effective; and when data is passed from one layer to another it may
have different performance characteristics (a built-in Dictionary will perform
differently than an equivalent NSDictionary, even if they can be used in the
same way).

A lot of the problems stem from the fact that Objective-C has grown over time,
and itself has had new mechanisms added. Blocks were only added relatively
recently, and so some APIs have support for callbacks with blocks, whilst
older APIs don't have block support. Those that do support blocks work
particularly well with Swift, because you can have a trailing lambda(closure)
and pass that in as a block; if it doesn't then it involves writing a separate
Swift/NSObject class that implements a callback interface, which increases the
size of the codebase.

I would imagine that Apple will focus on the important things - like fixing
the compiler/xcode bugs (they've got a lot of work to do there still) and
introducing newer features/fixes (class members can't be that hard...) before
there's an exhaustive overview of the APIs. That said, I think the existing
APIs will largely do their own things (being looked after by different teams),
perhaps adopting blocks where they are not yet present, but there would have
to be a big shift away from things like UIKit in order to make a change.

Close observers will note the UI layer is already being abstracted with
CoreGraphics (a C library) and Metal (a lower layer C library) so it's not too
much of a stretch to imagine a new UI layer written in Swift -- but Apple will
keep that under wraps for a long time until it is baked.

Disclaimer: I published Swift Essentials
([http://swiftessentials.org](http://swiftessentials.org)) and expect Swift to
only grow from here, even though Objective-C was my first love.

~~~
lerno
Interestingly, Swift may not even be a "better C++" for all domains dominated
by C++:

The memory model is strictly ref-counted which is unsuitable for certain tasks
(e.g. high perf game programming) and the runtime performance is still
extremely brittle (i.e. dependent on optimization passes).

Lots of apps also use c++ as the common core model. Since Swift isn't
multiplatform, it is not replacing c++ there either.

------
naaaaak
Cocoa has a ton of bugs and cruft and could very much benefit from a mass
refactoring. I'd like to see everything deprecated actually removed and a
bunch of other aggressive actions taken to prune APIs that never worked well.
Replace all target-actions and delegates with blocks. Redo anything where the
solution is to defer an action by one runloop cycle. Rid the world of NSCell.
Redo views using layer composition. Admit CoreData hasn't been up to task for
years and still lags behind and ditch it. Work with the security team and
introduce new entitlements (still a stupid name) to allow more APIs to work
under sandboxing. Introduce more fixes and changes throughout the year, not
locked to an annual OS update cycle. Open up the bug base for this thing so I
can see when something is broken instead of losing hours on end thinking I'm
doing something wrong. Be bold. Break compatibility and call it Cocoa 2 for
marketing. Do whatever steps are needed to make Cocoa awesome again.

But this shouldn't be done because of Swift; this should be done because it's
necessary to breathe new life into the frameworks and rethink them for how we
work now.

Swift is not ObjC without the C, gets the defaults wrong and should be dynamic
by default, and is changing too frequently to provide any of the stability and
productivity that good frameworks need to provide. To anyone on the Cocoa
team: don't cater to fads (you saw what happened with garbage collection).
Make them actually give you Objective C without the C or a language better
suited than ObjC to app development before you even consider going out of your
way to support it. When that happens, you can have a great refactoring again
and call it Cocoa 3...

------
onedev
I'm in love with the Cocoa

------
nailer
Oh god, NextStep API:

    
    
        NSJSONSerialization
    

What else does JSON do if not serialization?

    
    
        JSONObjectWithData
    

As opposed to JSON things that aren't objects and don't have data? The
signal/noise ratio is so low.

~~~
pavlov
"JSONObjectWithData" means that it produces an object from NSData input. This
is perfectly reasonable because valid JSON can also be an array and the input
could be something else than a buffer, for example a string.

I don't find Cocoa's verbose names to be a problem because the logic behind
them is very consistently applied and Xcode's autocomplete fills them in
anyway.

Personally I greatly prefer Cocoa's excessively "literary" style to the
arbitrarily shortened style used in many dynamic languages like Ruby. Unlike
"JSONObjectWithData", method names like "eql?", "gsub" and "len" can't be
deduced, you just have to remember them or look them up.

~~~
darkFunction
I agree entirely. It's just as fast to read and typing abbreviations is
actually slower than typing full words most of the time because of keystroke
muscle memory. Sure, it can make a screenful of code 'look' uglier but in the
end it reads explicitly and that can only be a good thing.

~~~
nailer
I don't think anyone is advocating for abbreviations.

------
johnny_reilly
I clicked on this link thinking "yeah, hot chocolate has kind of vanquished
cocoa hasn't it?" Very disappointing to discover this had nothing to do with
chocolatey drinks.

~~~
dottrap
Cocoa was named partly as a pun of Java. Remember when NeXTStep was folded
into Apple, Java was getting a lot of attention.

~~~
Alphasite_
Cocoa was Java compatible, as a first class target.

