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.
I appreciate your feedback, but I think you're reading an entirely different argument than what is presented in the article. It's not that everything is going to be rewritten in Swift (I'm not sure where you got that idea). Rather, the article is an exploration of what Swift without Obj-C & Cocoa could be, and under what circumstances that might become a reality.
If Swift doesn't have to accommodate Objective-C as it currently does, it's reasonable to assume that system frameworks will be designed and built in ways that make the most of Swift's language features, just as Cocoa currently does with Objective-C.
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).
I agree with most of what you are saying. I have no problem with Objective-C as well. I never had a problem with Objective-C and I have done Objective-C for over 10 years now…
But I would like to mention that people seem to overestimate the work required to "port" a framework from one language to another. Take 280North as an example. A tiny company (funded by ycombinator) founded by 2 ex Apple employees. They have developed a JavaScript variant of Objective-C (called Objective-J) and reimplemented the most important parts of AppKit. It took them a couple of months but in the end it all worked out, many people used (and are still using it) Cappuccino (name of the framework) and 280North was bought by Motorola for something like $20.000.000. So two guys => 1 language, a couple of frameworks in a matter of months.
Also I am sure you are aware that every year Apple introduces a ton of new frameworks and deprecates some frameworks. It would only take a couple of releases to deprecate 80% of the frameworks used by most apps and introduce replacements for them.
Swift without a new set of frameworks makes little sense IMHO. So either Swift will dies - just like GC did or it won't and then we will see new frameworks written in Swift.
Talking about GC… When Apple introduced GC they told us that it was the latest and greatest shit. It was the future. When introducing GC they told us that "hey - we have ported Xcode to GC - look it is that easy.". So they had more apps using GC from day 1 than using Swift from day 1 (well the WWDC app written in Swift does not count…). Apple had to ship GC-capable versions of their frameworks from day 1. They were even more committed to GC than they are now to Swift so it would not surprise me at all to see Swift let go in a couple of years and buried deep.
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.
There is no reason not to use Swift, Swift can do all that Objective-C can do and more. The language, framework support and the compiler have reached 1.0, the only thing that keeps happening is an error message in Xcode that I can safely ignore and keep working. But projects written in Swift are safe for production.
The reason you could switch to Swift is that it is safer, less verbose (unless you interact with Objective-C) and more flexible. You can choose to use Swift in a way that you are just using Objective-C translated to Swift and ignore all the extras or you can choose to use all the extra goodies you get like map, reduce, currying, advanced switch case statements and more. These features aren't new but they are not common in a lower level language comparable to C++ and Objective-C.
Swift is comparable to Rust in that sense. Nobody needed Rust but Rust doesn't stop you from doing anything you could do before while it gives you a lot of extra goodies from higher level languages.
A lot of people tried Swift when it was in a beta and ran into problems with it and got frustrated. Then repeat those experiences all over the internet like it happened to them just yesterday. There's also a significant portion of the iOS development community that rejects AutoLayouts because it was too alien to them and the first iteration wasn't perfect.
Last but not least: you're not forced to use only Swift in any project. Of course it's easier to wrap C code in Objective-C and then use it with a bridge in your Swift project. I mix and match every day, I'm not going to rewrite perfectly sane Objective-C code because I'm doing a Swift project. Try to be pragmatic about it.
Truth is that Objective-C style libraries really do seem really cumbersome and verbose when you use it in much more lightweight Swift code.
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.
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?
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.
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...
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.
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)"
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.
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.
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 ...)
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.
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.
"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."
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
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 ;)
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.
When I saw how quickly playgrounds compile and run, this was my very first thought. The fact that Apple announced FTL compiling for javascript just prior to announcing swift makes me wonder wether Apple has plans to make swift the new lingua Franca.
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.
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.
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.
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?
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.
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) and expect Swift to only grow from here, even though Objective-C was my first love.
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.
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.
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...
[+] [-] jawngee|11 years ago|reply
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.
[+] [-] matttthompson|11 years ago|reply
If Swift doesn't have to accommodate Objective-C as it currently does, it's reasonable to assume that system frameworks will be designed and built in ways that make the most of Swift's language features, just as Cocoa currently does with Objective-C.
[+] [-] cageface|11 years ago|reply
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).
[+] [-] LinaLauneBaer|11 years ago|reply
But I would like to mention that people seem to overestimate the work required to "port" a framework from one language to another. Take 280North as an example. A tiny company (funded by ycombinator) founded by 2 ex Apple employees. They have developed a JavaScript variant of Objective-C (called Objective-J) and reimplemented the most important parts of AppKit. It took them a couple of months but in the end it all worked out, many people used (and are still using it) Cappuccino (name of the framework) and 280North was bought by Motorola for something like $20.000.000. So two guys => 1 language, a couple of frameworks in a matter of months.
Also I am sure you are aware that every year Apple introduces a ton of new frameworks and deprecates some frameworks. It would only take a couple of releases to deprecate 80% of the frameworks used by most apps and introduce replacements for them.
Swift without a new set of frameworks makes little sense IMHO. So either Swift will dies - just like GC did or it won't and then we will see new frameworks written in Swift.
Talking about GC… When Apple introduced GC they told us that it was the latest and greatest shit. It was the future. When introducing GC they told us that "hey - we have ported Xcode to GC - look it is that easy.". So they had more apps using GC from day 1 than using Swift from day 1 (well the WWDC app written in Swift does not count…). Apple had to ship GC-capable versions of their frameworks from day 1. They were even more committed to GC than they are now to Swift so it would not surprise me at all to see Swift let go in a couple of years and buried deep.
At the moment everything seems possible.
[+] [-] meesterdude|11 years ago|reply
[+] [-] dep_b|11 years ago|reply
The reason you could switch to Swift is that it is safer, less verbose (unless you interact with Objective-C) and more flexible. You can choose to use Swift in a way that you are just using Objective-C translated to Swift and ignore all the extras or you can choose to use all the extra goodies you get like map, reduce, currying, advanced switch case statements and more. These features aren't new but they are not common in a lower level language comparable to C++ and Objective-C.
Swift is comparable to Rust in that sense. Nobody needed Rust but Rust doesn't stop you from doing anything you could do before while it gives you a lot of extra goodies from higher level languages.
A lot of people tried Swift when it was in a beta and ran into problems with it and got frustrated. Then repeat those experiences all over the internet like it happened to them just yesterday. There's also a significant portion of the iOS development community that rejects AutoLayouts because it was too alien to them and the first iteration wasn't perfect.
Last but not least: you're not forced to use only Swift in any project. Of course it's easier to wrap C code in Objective-C and then use it with a bridge in your Swift project. I mix and match every day, I'm not going to rewrite perfectly sane Objective-C code because I'm doing a Swift project. Try to be pragmatic about it.
Truth is that Objective-C style libraries really do seem really cumbersome and verbose when you use it in much more lightweight Swift code.
[+] [-] fit2rule|11 years ago|reply
Me neither. Lua all the things. Because, this:
>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++.
[+] [-] gilgoomesh|11 years ago|reply
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|11 years ago|reply
[+] [-] matttthompson|11 years ago|reply
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.
[+] [-] CookWithMe|11 years ago|reply
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:
instead of: 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|11 years ago|reply
I'm using CoreData via Swift and find it mostly more enjoyable than Objective-C.
[+] [-] Normati|11 years ago|reply
"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|11 years ago|reply
[+] [-] richardwhiuk|11 years ago|reply
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.
[+] [-] marstall|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] e28eta|11 years ago|reply
[+] [-] philliphaydon|11 years ago|reply
Apple doubted JSON would be around?
[+] [-] tolmasky|11 years ago|reply
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
[+] [-] timthorn|11 years ago|reply
[+] [-] veb|11 years ago|reply
> 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?
[+] [-] masters3d|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] tempodox|11 years ago|reply
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|11 years ago|reply
Adding Swift to Safari would be an interesting development
[+] [-] rezistik|11 years ago|reply
Except with none of the market share.
[+] [-] tomelders|11 years ago|reply
[+] [-] kennyledet|11 years ago|reply
But wait, since when was Safari the only viable web browser anyway?
Disclaimer: I'm an Apple fanboy and rMBP user.
[+] [-] gurkendoktor|11 years ago|reply
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|11 years ago|reply
A good example is string interpolation. Swift makes it unnecessary to have things like `stringWithFormat` in framework level.
[+] [-] ZanyProgrammer|11 years ago|reply
[+] [-] bovermyer|11 years ago|reply
[+] [-] cportela|11 years ago|reply
[+] [-] michaeljbishop|11 years ago|reply
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|11 years ago|reply
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) and expect Swift to only grow from here, even though Objective-C was my first love.
[+] [-] lerno|11 years ago|reply
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.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] dirtyaura|11 years ago|reply
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.
[+] [-] naaaaak|11 years ago|reply
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...
[+] [-] unicornporn|11 years ago|reply
[deleted]
[+] [-] onedev|11 years ago|reply