Even though sog35 comments are inflammatory I do think there is some truth to it. Tim's skill is logistics, and he is amazing at logistics, but usually what makes you good at logistics makes you not that good as a CEO. To be great logistically you have to have a healthy fear of risk. And your entire job is to mitigate that risk. But as CEO especially of a culture like apple it requires crossing the rubicon, burning the bridges kinda risk. And you do see that he has been tepid about all sorts of things. Like why he hasn't killed off certain products. Like why do they sell 6 different versions of the ipad (I'm not talking about customization like hard drive space but different versions). It's super confusing to the customer he could just simplify it small, medium, large. There are other examples were he should just risk it but seems to fear it to much.
Another example of not taking risks by Cook was continuing to sell 16GB iPhones. That is 100% based on being afraid of lower margins. Those kind of moves make Apple look like a short term thinking company instead of being visionary. Sure you make more profit selling 16GB phones but customer satisfaction suffers and services revenue suffers also (less space to buy stuff)
You sound like as if Cook takes all the decisions himself.
Well, Cook is the captain of the ship. All he does is steering the ship. It is up to his team (Ive - Federighi - Shiller - Angela - Shiller - Cue - etc. ) to deliver. Having said that. I agree that 2015 was a very unusual year for Apple:
iTunes, WTF
Apple Music
watch OS
iPad pro smart keyboard
And last, but not least, the infamous iPhone 6S battery case
The Macbook, watch, pencil are great products though, with a great future ahead. It is testament that Apple - the company - is not failing as you suggest. With Shiller stepping up to focus on the App ecosystem, I am looking forward to 2016.
This doesn't surprise me. Apps have history. Jumping to Swift requires jettisoning most of your app's history and starting new. I can see where that would be an expensive and destabilizing prospect for Apple. Any new apps going forward with them should be written with Swift, though. Otherwise, they're not eating their own dog food.
Any new projects, I start with Swift. Old projects remain in Objective-C. I can attest that the new app my company (I) wrote in Swift has the lowest number of recorded crashes per capita of any app produced by them. I would love to think that was all me, but I'm thinking a good portion of it is due to Swift's strict enforcement of optionals and other good coding practices.
Sog, you have obviously no clue what you're talking about here, so please confine your god damn rants to something that makes sense.
Polluting every thread with this kind of talk makes you look like an idiot even in threads where you have a point.
huh? This topic about the slow adoption to Swift is exactly my grip about Tim Cook. He is always too little too late. And Swift is another example.
You realize most programming languages take 10 years to stabilize right? They are on track for a stable ABI allowing higher adoption late in 2016. That is extremely fast progress. Apple is doing an excellent job reducing the pain for early adopters with migration tools while the language matures. Until the ABI is mature all Swift code needs to be kept up-to-date with the latest language spec and frameworks (APIs) shared between applications will not be possible.
As a developer I do understand the obstacles Apple is facing when moving
from Objective-C to Swift.
@cropr, as a new Dev who is learning Swift but does not know Objective-C, I'm interested in hearing about the shortcomings of Swift that more experienced developers like you see. It'd give me some situational awareness.
The problems affecting app developers are mostly surrounding the fragile ABI (meaning frameworks that are not bundled inside you're app will break across releases) and the fact the language changes every few months requiring a rewrite of your code (Xcode makes this easier with migration tools). Since the ABI is fragile you are forced to upgrade all of your code to any language changes before you can compile your program again. There are lesser issues such as porting Objective-C code that calls in to C++. Writing frameworks that are included with the operating system have more significant issues: no 32-bit runtime, the fragile ABI is more of a show stopper, and ABI breaking changes to the programming language will also cause issues with backwards compatibility. Now that Swift is open source we see that they are targeting Swift 3.0 that will be included with the next major releases of the operating system to work well for system frameworks by creating a stable ABI and making sure all programing language features that might break the ABI are perfected. Swift 4.0 (probably due out at the end of 2017) will probably focus on non-ABI breaking (basically adding features instead of changing the language) changes like new concurrency features that are much requested by developers.
So in 12months it could be a very different story?
Reading developer blogs and the like (plus my own amateur attempts) it seems one of the biggest sticking points has been dealing with the swift's type safeness and the abstract data blob. I wonder if Apple hit the same roadblocks internally with swift. It would seem like Apple could put some work into swift native data handling libraries like JSON, SQL and the like and it would have a real lift in swift use in shipping code.
The big question, IMO, is "Will Apple make FoundationDB APIs available to Apple Developers? Open Source Developers?
Swift probably will not be good for shell scripts until Swift 3.0 since they really need a stable ABI for frameworks they are calling in to. I personally think this is a direction Swift may be heading, but Apple has not announced anything.
Swift probably will not be good for servers until Swift 4.0, but expect people to make it work by wrapping C libraries such as the backed of node.js in the early days since there is a lot of enthusiasm in that space.
Handling somewhat dynamic types like JSON will work fine in Swift. At least as well or better then other languages. There are already some good third party libraries for JSON and SQL. Certainly Apple included frameworks are currently tailored for Objective-C.
FoundationDB has more to do with iCloud. I don't see that having much influence on Swift at this point. Potentially some features slated for Swift 4.0 could be driven by needs in the iCloud team. I understand that realm.io is proposing a way to allow model objects to utilize dynamic dispatch using some sort of Swift runtime plugin based on Swift integration with Objective-C dynamic dispatch (using dynamic keyword). Potentially other databases will use that system if it is approved.
Swift is a mash up at this point. It uses all the legacy Obj-C libraries. There are literally millions of lines of code that need to be rewritten before it becomes its own pure language. Obj-C may be theoretically obsolete but Swift is not really ready to replace it yet. Apple may be philosophically committed to it but full implementation is going to take quite some time.
Swift is a mash up at this point. It uses all the legacy Obj-C libraries. There are literally millions of lines of code that need to be rewritten before it becomes its own pure language. Obj-C may be theoretically obsolete but Swift is not really ready to replace it yet. Apple may be philosophically committed to it but full implementation is going to take quite some time.
Swift is already a "pure" language, but it was also designed to interoperate with Obj-C. I can write plenty of pure Swift programs, but apps on iOS run on top of an Obj-C code base.
All that said, we're already doing new apps in Swift. Older apps are still based in Obj-C, but will undoubtedly be converted to Swift once we reach unacceptable levels of technical debt. (One app still has code in it designed to work using iOS 5.)
So as far as we're concerned, Swift has already "replaced" Obj-C...
Swift is already a "pure" language, but it was also designed to interoperate with Obj-C. I can write plenty of pure Swift programs, but apps on iOS run on top of an Obj-C code base.
It is sort of like Apple's green sustainable electricity program. They produce a lot of solar power but for the most part they still depend on the old fashion grid. Sure they could theoretically run their data centers off of their renewable energy sources but for some reason they prefer to rely on power from the grid and diesel generators as back up and simply resell their solar back to the power company. Just like Swift, it is moving forward but not yet a complete replacement. It is still working on top of a legacy foundation.
Comments
Well, Cook is the captain of the ship. All he does is steering the ship. It is up to his team (Ive - Federighi - Shiller - Angela - Shiller - Cue - etc. ) to deliver. Having said that. I agree that 2015 was a very unusual year for Apple:
- iTunes, WTF
- Apple Music
- watch OS
- iPad pro smart keyboard
- And last, but not least, the infamous iPhone 6S battery case
The Macbook, watch, pencil are great products though, with a great future ahead. It is testament that Apple - the company - is not failing as you suggest. With Shiller stepping up to focus on the App ecosystem, I am looking forward to 2016.Swift probably will not be good for shell scripts until Swift 3.0 since they really need a stable ABI for frameworks they are calling in to. I personally think this is a direction Swift may be heading, but Apple has not announced anything.
Swift probably will not be good for servers until Swift 4.0, but expect people to make it work by wrapping C libraries such as the backed of node.js in the early days since there is a lot of enthusiasm in that space.
Handling somewhat dynamic types like JSON will work fine in Swift. At least as well or better then other languages. There are already some good third party libraries for JSON and SQL. Certainly Apple included frameworks are currently tailored for Objective-C.
FoundationDB has more to do with iCloud. I don't see that having much influence on Swift at this point. Potentially some features slated for Swift 4.0 could be driven by needs in the iCloud team. I understand that realm.io is proposing a way to allow model objects to utilize dynamic dispatch using some sort of Swift runtime plugin based on Swift integration with Objective-C dynamic dispatch (using dynamic keyword). Potentially other databases will use that system if it is approved.
Swift is already a "pure" language, but it was also designed to interoperate with Obj-C. I can write plenty of pure Swift programs, but apps on iOS run on top of an Obj-C code base.
All that said, we're already doing new apps in Swift. Older apps are still based in Obj-C, but will undoubtedly be converted to Swift once we reach unacceptable levels of technical debt. (One app still has code in it designed to work using iOS 5.)
So as far as we're concerned, Swift has already "replaced" Obj-C...