19 ms·

The Death of Cocoa

242 points by andrewbarba 12y ago

gurkendoktor 12y ago
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.
philliphaydon 12y ago
"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?
- veb 12y ago
  For those wondering, what OP quoted was a response to the author: > In defense of Apple, I once asked an engineer at a WWDC Lab why it took so long for iOS to support JSON. Their answer made a lot of sense. However, I'm not sure that it makes much sense to me... I guess I may be missing something essential?
- tolmasky 12y ago
  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 12y ago
    > 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 12y ago
      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 12y ago
        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.
- timthorn 12y ago
  Apple also released a framework for Publish and Subscribe in System 7, though I don't think that's still supported! http://en.wikipedia.org/wiki/Publish_and_Subscribe_(Mac_OS) http://en.wikipedia.org/wiki/Publish_and_Subscribe_(Mac_OS)
onedev 12y ago
I'm in love with the Cocoa
bovermyer 12y ago
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 12y ago
  Nope, I love it too. I made my personal website the same way. Long live meaningful and well written text being the focus.
imron 12y ago
>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
- kennyledet 12y ago
  >only viable But wait, since when was Safari the only viable web browser anyway? Disclaimer: I'm an Apple fanboy and rMBP user.
  - imron 12y ago
    Safari isn't the only viable web browser. Javascript is the only viable webscripting language in browsers.
- rezistik 12y ago
  About as interesting as adding Dart to Chrome. Except with none of the market share.
  - masters3d 12y ago
    Only every iPhone and iPad out there.
    - oblio 12y ago
      Awesome. Let us make Apple-only sites! /sarcasm
      - tomelders 12y ago
        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.
      - orbitur 12y ago
        Let's be honest, though. Apple ignoring Flash on iOS did help move the whole web ecosystem away from Flash.
gilgoomesh 12y ago
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 12y ago
  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 12y ago
    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).
- matttthompson 12y ago
  I have no illusions about the amount of effort and investment necessary to change technology stacks. Carbon was only officially deprecated in OS X 10.8. To speak of the death of technology is only to acknowledge that it is mortal. My claim isn't that everything will be rewritten in Swift—far from it. Instead, the article is an exploration of what it would mean for Swift to evolve beyond the constraints of Objective-C & Cocoa interoperability, and how that may occur as Swift gains momentum.
msoad 12y ago
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.
masters3d 12y ago
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 ;)
- deleted 12y ago
  [deleted]
jarjoura 12y ago
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.
- deleted 12y ago
  [deleted]
- e28eta 12y ago
  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.
CookWithMe 12y ago
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 12y ago
  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.
johnny_reilly 12y ago
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.
- imron 12y ago
  Not sure why you're getting downvotes. Even as someone who develops with Cocoa, the chocolately drink was my first thought too.
- dottrap 12y ago
  Cocoa was named partly as a pun of Java. Remember when NeXTStep was folded into Apple, Java was getting a lot of attention.
  - Alphasite_ 12y ago
    Cocoa was Java compatible, as a first class target.
Normati 12y ago
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)"
- richardwhiuk 12y ago
  It sounds like a fairly terrible tradeoff actually. Presumably one of those encodings is the underlying representation, and accessing it in any other representation is going to cause a horrible hit to performance as it thunks between the two. In practice it feels much better to define a encoding for the platform (say UTF 16 for Java / Windows - though personally I feel UTF-8 is a better choice) and then have a [string encodeIn:UTF16] method if you want something different. Ideally, the encoding would be specified in the type - e.g. String<UTF16> rather than arbitrary unspecified byte arrays.
  - masklinn 12y ago
    > Presumably one of those encodings is the underlying representation, and accessing it in any other representation is going to cause a horrible hit to performance as it thunks between the two. Which does not usually matter, you're accessing it in a specific representation because you need it in that representation, usually for IO. The "horrible hit" is one you'll have to eat either way. And if you're baking the implementation details of your internal strings into your IO… god help your soul. That aside, there's not much of a horrible hit unless you're preallocating the whole output string every time. Swift has iterators/iterables built in and I may be mistaken but I believe Swift does the sane thing and exposes noalloc iterable views, you're paying for some bit-twiddling (for the transcoding itself) and stack-allocated int8/int16/int32. Not sure how good Swift's compiler is, but I know Rust's can turn such iterations into the equivalent of the corresponding C loop, there's little to no overhead. > In practice it feels much better to define a encoding for the platform Why? What does that give you, aside from exposing broken implementation details as the type's public interface and having unfixable string for a decade (see: Java and everything Microsoft, because they exposed strings as being O(1)-indexed UCS2 code units early on). > Ideally, the encoding would be specified in the type - e.g. String<UTF16> That's crazy talk, why would you encode the implementation detail of the string's internal encoding in the type interface? I can think of a hundred things I'd put there, but the internal encoding?
jawngee 12y ago
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 coughAVFoundationcough. 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.
- meesterdude 12y ago
  14 hours a day, and your problem is ambiguous documentation and temperamental behavior? I don't mean to detract from your primary points, but 14 hours a day is quite a chunk of time. I hope its not your norm, because that just sucks.
  - copperx 12y ago
    Not even doctors work that many hours. Holy shit.
    - kennyledet 12y ago
      Out of school for winter break and I code pretty much 20/7.
  - jawngee 12y ago
unicornporn 12y ago
Totally OT, but the only thing I could of when I saw that domain name was https://en.wikipedia.org/wiki/National_Socialism_%28disambiguation%29 https://en.wikipedia.org/wiki/National_Socialism_%28disambig... hipster...
deleted 12y ago
[deleted]
- dirtyaura 12y ago
  The purpose of Set abstractions is to provide set operations like union, intersection and complement, which Dictionary doesn't provide. Set operations are regularly needed in various algorithms. Void vs. Bool issue might be due to fact that Nate Cook's implementation was written at the time of Xcode and Swift beta and there were a lot of type inference bugs. Maybe Void dictionaries didn't work correctly. For example, using map that returned void crashed the compiler in one beta version. This was actually used in Nate's set implementation and I had to modify it to work.
  - deleted 12y ago
    [deleted]
nailer 12y ago
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 12y ago
  "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 12y ago
    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 12y ago
      I don't think anyone is advocating for abbreviations.
  - nailer 12y ago
    > This is perfectly reasonable because valid JSON can also be an array Are arrays (and primitives which can be boxed) not considered objects in every OO language ever? Agreed re: usls ctrctns. That's the other extreme. One wants to convey the required meaning in the minimum amount possible - no more, no less. Edit: thinking about it, you probably mean that the top level object is a hashtable, since ObjC is strongly typed. If I was going to do that I'd rather check the whole structure (rather than just the top) with an interface.
tempodox 12y ago
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.
ZanyProgrammer 12y ago
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.
michaeljbishop 12y ago
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.
naaaaak 12y ago
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...
alblue 12y ago
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.
marstall 12y ago
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 ...)

242 points by andrewbarba 12y ago

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.

philliphaydon 12y ago

"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?

veb 12y ago
For those wondering, what OP quoted was a response to the author: > In defense of Apple, I once asked an engineer at a WWDC Lab why it took so long for iOS to support JSON. Their answer made a lot of sense. However, I'm not sure that it makes much sense to me... I guess I may be missing something essential?
tolmasky 12y ago
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 12y ago
  > 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 12y ago
    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 12y ago
      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.
timthorn 12y ago
Apple also released a framework for Publish and Subscribe in System 7, though I don't think that's still supported! http://en.wikipedia.org/wiki/Publish_and_Subscribe_(Mac_OS) http://en.wikipedia.org/wiki/Publish_and_Subscribe_(Mac_OS)

onedev 12y ago

I'm in love with the Cocoa

bovermyer 12y ago

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 12y ago
Nope, I love it too. I made my personal website the same way. Long live meaningful and well written text being the focus.

imron 12y ago

>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

kennyledet 12y ago
>only viable But wait, since when was Safari the only viable web browser anyway? Disclaimer: I'm an Apple fanboy and rMBP user.
- imron 12y ago
  Safari isn't the only viable web browser. Javascript is the only viable webscripting language in browsers.
rezistik 12y ago
About as interesting as adding Dart to Chrome. Except with none of the market share.
- masters3d 12y ago
  Only every iPhone and iPad out there.
  - oblio 12y ago
    Awesome. Let us make Apple-only sites! /sarcasm
    - tomelders 12y ago
      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.
    - orbitur 12y ago
      Let's be honest, though. Apple ignoring Flash on iOS did help move the whole web ecosystem away from Flash.

gilgoomesh 12y ago

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 12y ago
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 12y ago
  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).
matttthompson 12y ago
I have no illusions about the amount of effort and investment necessary to change technology stacks. Carbon was only officially deprecated in OS X 10.8. To speak of the death of technology is only to acknowledge that it is mortal. My claim isn't that everything will be rewritten in Swift—far from it. Instead, the article is an exploration of what it would mean for Swift to evolve beyond the constraints of Objective-C & Cocoa interoperability, and how that may occur as Swift gains momentum.

msoad 12y ago

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.

masters3d 12y ago

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 ;)

deleted 12y ago
[deleted]

jarjoura 12y ago

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.

deleted 12y ago
[deleted]
e28eta 12y ago
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.

CookWithMe 12y ago

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 12y ago
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.

johnny_reilly 12y ago

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.

imron 12y ago
Not sure why you're getting downvotes. Even as someone who develops with Cocoa, the chocolately drink was my first thought too.
dottrap 12y ago
Cocoa was named partly as a pun of Java. Remember when NeXTStep was folded into Apple, Java was getting a lot of attention.
- Alphasite_ 12y ago
  Cocoa was Java compatible, as a first class target.

Normati 12y ago

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)"

richardwhiuk 12y ago
It sounds like a fairly terrible tradeoff actually. Presumably one of those encodings is the underlying representation, and accessing it in any other representation is going to cause a horrible hit to performance as it thunks between the two. In practice it feels much better to define a encoding for the platform (say UTF 16 for Java / Windows - though personally I feel UTF-8 is a better choice) and then have a [string encodeIn:UTF16] method if you want something different. Ideally, the encoding would be specified in the type - e.g. String<UTF16> rather than arbitrary unspecified byte arrays.
- masklinn 12y ago
  > Presumably one of those encodings is the underlying representation, and accessing it in any other representation is going to cause a horrible hit to performance as it thunks between the two. Which does not usually matter, you're accessing it in a specific representation because you need it in that representation, usually for IO. The "horrible hit" is one you'll have to eat either way. And if you're baking the implementation details of your internal strings into your IO… god help your soul. That aside, there's not much of a horrible hit unless you're preallocating the whole output string every time. Swift has iterators/iterables built in and I may be mistaken but I believe Swift does the sane thing and exposes noalloc iterable views, you're paying for some bit-twiddling (for the transcoding itself) and stack-allocated int8/int16/int32. Not sure how good Swift's compiler is, but I know Rust's can turn such iterations into the equivalent of the corresponding C loop, there's little to no overhead. > In practice it feels much better to define a encoding for the platform Why? What does that give you, aside from exposing broken implementation details as the type's public interface and having unfixable string for a decade (see: Java and everything Microsoft, because they exposed strings as being O(1)-indexed UCS2 code units early on). > Ideally, the encoding would be specified in the type - e.g. String<UTF16> That's crazy talk, why would you encode the implementation detail of the string's internal encoding in the type interface? I can think of a hundred things I'd put there, but the internal encoding?

jawngee 12y ago

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 coughAVFoundationcough. 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.

meesterdude 12y ago
14 hours a day, and your problem is ambiguous documentation and temperamental behavior? I don't mean to detract from your primary points, but 14 hours a day is quite a chunk of time. I hope its not your norm, because that just sucks.
- copperx 12y ago
  Not even doctors work that many hours. Holy shit.
  - kennyledet 12y ago
    Out of school for winter break and I code pretty much 20/7.
- jawngee 12y ago

unicornporn 12y ago

Totally OT, but the only thing I could of when I saw that domain name was https://en.wikipedia.org/wiki/National_Socialism_%28disambiguation%29 https://en.wikipedia.org/wiki/National_Socialism_%28disambig... hipster...

deleted 12y ago

[deleted]

dirtyaura 12y ago
The purpose of Set abstractions is to provide set operations like union, intersection and complement, which Dictionary doesn't provide. Set operations are regularly needed in various algorithms. Void vs. Bool issue might be due to fact that Nate Cook's implementation was written at the time of Xcode and Swift beta and there were a lot of type inference bugs. Maybe Void dictionaries didn't work correctly. For example, using map that returned void crashed the compiler in one beta version. This was actually used in Nate's set implementation and I had to modify it to work.
- deleted 12y ago
  [deleted]

nailer 12y ago

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 12y ago
"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 12y ago
  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 12y ago
    I don't think anyone is advocating for abbreviations.
- nailer 12y ago
  > This is perfectly reasonable because valid JSON can also be an array Are arrays (and primitives which can be boxed) not considered objects in every OO language ever? Agreed re: usls ctrctns. That's the other extreme. One wants to convey the required meaning in the minimum amount possible - no more, no less. Edit: thinking about it, you probably mean that the top level object is a hashtable, since ObjC is strongly typed. If I was going to do that I'd rather check the whole structure (rather than just the top) with an interface.

tempodox 12y ago

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.

ZanyProgrammer 12y ago

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.

michaeljbishop 12y ago

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.

naaaaak 12y ago

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...

alblue 12y ago

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.

marstall 12y ago

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 ...)