Is Apple Using Swift?
medium.com
medium.com
The big roadblock (especially for things like frameworks) is 32-bit support. There's no 32-bit runtime for Swift. When that requirement is lifted I'm certain we'll see a flood of Apple apps built with Swift. There was (and still is) a huge amount of enthusiasm for the language internally. Many teams were working with it and plenty of internal tools where built with it. So yes, Apple is absolutely using Swift.
The name comes from it being the only runtime for 32 bit OSX apps.
https://developer.apple.com/library/mac/documentation/Cocoa/...
2) http://stackoverflow.com/questions/24009876/how-can-use-cgfl...
https://developer.apple.com/swift/blog/?id=2
But I really haven't tried it myself so someone else who has may be able to help you.
You probably don't know/can't say, but is there going to be a 32-bit Mac runtime? Apple has spent zero resources improving the 32-bit ObjC runtime over the last decade, to the point where it's called the "legacy" runtime yet is still supported.
I expect a 32-bit Swift runtime would also require a modern ObjC runtime, but it seems rather unlike Apple to spend any resources now on 32-bit Mac (when they've decided not to for the last 9 years). I suspect that WWDC this June will be the beginning of the end for 32-bit Mac apps.
I'm curious about your use-case, actually. Presumably you're not targeting non-64-bit Macs. So are you using 32-bit for better memory use? In that case, maybe Apple should introduce a 32-bit-pointer-on-x64 ABI, like Linux's X32.
IIRC many teams within apple are using swift as much as they can, either for app/framework code, or test code. one example he gave was that the dock in El Capitan had been rewritten in swift. He also mentioned that the lack of 32 bit support for swift was a major pain point blocking more widespread adoption internally due to many frameworks still needing to support 32 bit macs.
Reading between the lines, it wouldn't surprise me if 32 bit support is dropped with the next version of OSX to allow more teams with Apple to start using no swift.
https://developer.apple.com/library/mac/documentation/Cocoa/...
Having said that, pretty much everyone developing for the Microsoft ecosystem (native) uses C#. That has been true for almost a decade now. I suspect the same will happen with Swift and Apple and rather rapidly because the Apple ecosystem doesn't have enterprise customers holding it back. Most of people commenting here seem to already know Objective-C. However, consider someone new to the platform. Would you spend 1 year learning iOS programming using Obj-C or learn it via Swift? Apart from Swift being a nicer language to learn, the reality is almost all tutorials/books etc have shifted to Swift. Good luck to the poor sap learning iOS programming via iOS 6 tutorials and Obj-C and migrating to iOS 9.
I think the Swift 1.0 to 2.0 journey was quite painful, pretty surprised that Apple made so many breaking changes with poor tools support, but I feel 2.0 is where it feels just about solid to build all new apps. Sure there will be changes, I mean Obj-C had ARC and blocks twenty years later! but that's the nature of software nowadays.
This will report the .NET runtime version for any CLR binary.
From Swift v3 on we should start seeing things going!
For larger apps, well, I have a Swift app that isn't really very big, probably still small but significantly bigger than a tutorial, and it keeps freezing Xcode. (Edit something in Interface Builder, switch to the ViewController class with IBOutlets in it, then switch back and forth between ViewControllers making edits. Each time it takes longer and longer until I just force-quit Xcode to avoid twiddling my thumbs for 5 minutes.) So I don't think Swift is ready for any app that isn't pretty small anyway.
I might be wrong, but I thought Swift was designed as an eventual replacement for Objective-C (with its seamless interoperability, and the fact that it uses the same runtime as Objective-C, it doesn't seem that far-fetched). If it is meant to be Objective-C's successor, then Apple should really be preaching by example at this point.
Oh no, it was meant to replace them. Win32 was going to be deprecated, all new stuff would be on native .NET APIs, there'd be a Windows Presentation Foundation and a Windows Filesystem and it'd all be great.
The thing is that Longhorn fell apart, and with it the dream of replacing Win32 died forever.
Now we have WinRT, but unlike the plans for Longhorn, WinRT actually sits on top of Win32.
WinRT however is definitely not a replacement for Win32. It's way too sandboxy (last time I checked, you couldn't even pull up a list of fonts installed on the host system using the WinRT APIs only).
Firstly, there is no question that it would generate bugs. Appkit and even iOS is old enough that you couldn't replace it completely without the behaviour changing. Even if it's fixing a weird behaviour, that would be a problem for many existing apps build on that framework.
Second of all, it would mean they wouldn't be moving forward with new features, which, basically nobody (customers even) wants.
I'm sure more and more new code will be Swift, and possibly non-framework apps can be re-written. But they won't start announcing a swap out in the next WWDC.
Swift is already production ready and Apple has plenty of examples, beyond that there's nothing to "prove".
It's worrying for Swift. If it really adds value compared to Objective-c then why is Apple so slow on jumping on the bandwagon? They need to show the way. Other companies usually talk with their fans through dev blog posts but Apple secrecy tradition and very tightly controlled communication does not help.
Everything surrounding Swift has been the most open Apple has been in a very long time
Edit: https://swift.org/blog (the current blog)
- What was challenging ?
- Lessons learned
- Performance measured before/after
- In general what was the gain ? Why should I bother except for the hype ?
In Yaron Minsky's "Effective ML" talk, he mentions the idea of "Make illegal states unrepresentable": https://vimeo.com/14313378
The combination of enums and non-optional variables allows you to get much closer to this ideal than you could with ObjC.
A great place to start would be the Functional Swift talks from 2014 and 2015: http://2014.funswiftconf.com/ http://2015.funswiftconf.com/
If you want to challenge yourself, try reading through the RxSwift codebase: https://github.com/ReactiveX/RxSwift
I understand not wanting to rewrite millions of lines of code but I feel like they should at least want to make a slow transition of at least many of their apps to Swift (since it can bind with Objective-C it's not like it has to be done all at once; it could be something where they spend a small percentage of time doing off and on). After my interview though I got the impression, at least from the developers I talked to, that they will probably never use Swift unless they have to.
Edit: I would like to point out, in case it's not obvious, that my case is purely anecdotal. Reading responses here and searching around Google is seems many inside Apple are excited about it which could very well be more than the people not excited about it. Still, I'd like to see some more platform support as it appears small at least to me looking from the outside.
However, Swift is invaluable in attracting new developers who are unlikely to take up Objective C.
e.g. -[NSBezierPath setLineDash:count:phase:] takes a C array in Objective-C, but an UnsafePointer<CGFloat> in Swift.
Apple needs new API interfaces for their new language, and that will take time.
https://github.com/apple/swift-evolution/blob/master/proposa...
At some point in the future I imagine we would also see native Swift APIs.
The hard part is using the frameworks and not getting annoyed of XCode slow downs, the language itself is very friendly.
Documentation is good too. Worked through the Stanford course which gives you a great introduction and a book about iOS design with Swift implementation.
Is there anything in particular you can point to, I'd love to take a look.
* Swift 3.0 goals[1] -- 3.0 is scheduled for late 2016 and it will bring a wealth of ABI and language stability improvements, and significant documentation improvements
* Commonly rejected changes[2] -- significant whitespace, "and" keyword vs && (et al), closure literals, and semicolon removal are not on the table and that doesn't seem to be changing anytime soon
Swift is great and all but it will probably not reach critical mass until 2018.
[1] https://github.com/apple/swift-evolution#development-major-v...
[2] https://github.com/apple/swift-evolution/blob/master/commonl...
https://medium.com/@Klehmann79/see-https-daringfireball-net-...
They aren't naive and know they need to balance end-user benefit with engineering's wishes for maintainability etc. Is the user going to see a vast difference in experience if they re-wrote the Settings.app? Swift is a language, not framework, so it doesn't offer the end-user anything worth caring about.
Swift will probably cost them more than it gains them in the immediate term, but the long-term is what Apple is all about, so I don't think they are concerned about this.
Where Swift has really gained traction is with bloggers and book authors. I past 3000 urls in my Swift Resources database over the weekend. I wrote this blog last night:
https://h4labs.wordpress.com/2016/01/18/3000-swift-urls/
Here's a direct link to the resources: http://www.h4labs.com/dev/ios/swift.html
However, getting it adopted in a big project with a dozen of engineers of various levels and a massive 300k LOC repo is a daunting task.
Even though it is a undoubtedly a better language, making such a switch is too frightening for the lead dev. Of course, Kotlin has the additional disadvantage of not being officially sponsored by Google on Android.
The problem is an unwillingness to switch to a new language ("we do just fine with java") coupled with the fact that ideally everyone in the team should get familiar with it.
Yeah, except they write 2-5 times more code in Java, than they would in Kotlin. I think it's unprofessional to reject a new language, that will make code smaller and easier to understand, just because somebody is afraid to step out of his comfort zone for a moment, and not because of some potential real problems.
I think you can justify anything with that stupid line of thinking: "I don't use for-loops, because a while-loop can do the same, and it's too hard for me to learn it." Sounds the same to me. Learning Kotlin is a must for any Android developer, unless he really likes to give handjobs to the Java compiler: "Oh, let my type the name of the type twice, even if it's quite long for clarity and you know it already from the right hand of the assignment. You want me to write 23 lines of boilerplate in a separate file for a POJO with 2 fields? Oh, you dirty boy!"
Pretty much. Older engineer. He remembers the transition from blackberry to Android and is not ready for another one. He almost advocates for the use of Vectors ...
Unfortunately he is also Lead Engineer, which makes matters complicated. Kotlin is far from the only subject where we butt heads. I also had to put his nose on all the leaks created by his atrocious 'architecture' in order to start working on a fix.
I don't think there is a good solution for that kind of problems other than throwing the towel and move to another company. I plan to emigrate anyway, so there is that.
There are true reasons to avoid Kotlin at the moment though :
-slower compilation (we have a huge codebase and dexing is already an issue).
-the whole team needs to move to it and since we are more than a dozen, it is a significant task.
-Kotlin does not support Android Lint, so common issues like using an API 21 method with minApiLvl = 17 can occur unnoticed.
Generally you can tell from the downloaded ipa files. Apple is also allowing devs to delete default apps on iOS now - meaning they can also be sourced from the app store and you can check their ipa.
I hadn't heard about this. Do you mean I can delete things like the Stocks app? If so, how?
That could be true, but what it's being used for is perhaps more important than the percentage. Not to underestimate the importance of a calculator, but it is known that Google uses Go in:
- dl.google.com
- Kubernetes
- Youtube's MySQL scaling infrastructure (Vitess)
- Google's mobile data compression proxy (Flywheel)
Of course, Go's first stable release was in 2012, so Swift still has some time to catch up ;).
Granted, the last I heard they had trouble scaling it up to hundreds of hosts, but there it is.
Currently, Swift is being hurt by incompatible changes between 1.x and 2.x. There are expected more incompatible changes between 2.x and 3.x.
If Apple had significant investment in Swift apps, they would not be making breaking changes so lightly. Because they don't, breaking changes are expected and why should be you the one, who is constantly rewriting the app you have?
TL;DR: it hurts the adoption of the language.
After 3.x, their won't be huge breaking changes thankfully.
Personally, only issue that bugged me was slower compilation time.
About significant investment, this is just how Apple is. They don't stop the train for anyone, it's get on or off. Same goes for SDK you compile against, certain features you must bake in etc.
Objective-C is 33 years old, I don't know for sure but I bet it wasn't that stable at the start!
You generally want to show dedication to a platform with sane means. Not by writing multi-million line codebases, and creating new bugs, cut-down features and delays in the process (a la FCPX, which was in the same language as 7, but still a total rewrite).
>If Apple had significant investment in Swift apps, they would not be making breaking changes so lightly.
And the language wouldn't have fixed its early mistakes and matured. Which is what they did with 2.0 and plan to do with 3.0 -- at which point they promise stability.
In general you want to stop making incompatible changes when you have finalized a good design and fixed all the major pain points from the early releases that the community brought forward.
Really, that's your take-away?
> However, there could be a very different story building for iOS 10. Since most of iOS is only dropped once per year, we’ll just have to wait and see in June.
AHHH! You almost get it.
Apple needs time to make the change (and they'll most likely never completely change over to all Swift) for most of the apps they decide to change. They want a nice fluid experience for their customers. Product cycles aren't short, iOS/OS X are at once per year, but that doesn't mean that some changes to them aren't planned out for much longer than a year.
the biggest pain I think is the error messages. some doesn't make sense. I also don't appreciate the ! and ?.
In my opinion, checking whether a variable is null or not is easier than using ? and ! everywhere.
Which is why you can do exactly that.
if let checked = blah { /* checked does not need ! or ? */ }Edit to add: And unless something has changed since I last tried it, you can also just shadow blah so that inside that scope you're referring to the unwrapped one:
if let blah = blah { /* use blah here, it's unwrapped */ }
I still don't understand the point of ! and ?
less is more, swift ought to know.
You seem to be insisting on using ! and then blaming the language for letting you shoot your foot off with it...
the example you gave is like the following c++ code:
XXX *object = null;
if ((object = anotherpointer) != NULL)
{ ... }
The point is, ! is only useful, when it can detect null pointers during compiling time. but it doesn't.
the way ! is used, as suggested by your example, is also doable in C++, it is just a habit thing.
in c++, with good habit, you won't have problem. in Swift with bad habit, you will have the same problem.
then what good is !,
! is there for the small number of cases where that's not possible. And it makes it much more obvious where you've got a potential problem, because the '!' is a literal code smell. You can't really do that with c++.
will it be a runtime error? like a memory access violation in c++?
what's the benefit of adding !? if it generates the same access violation runtime error?
let foo = bar!
If bar is nil, you'll get a runtime error "unexpectedly found nil when unwrapping bar"
in my opinion, the benefit of optionals in general is that it allows you to guarantee at compile time that certain variables (non optionals) will _never_ be nil, which enables all kinds of compiler optimizations.
guard let foo = optFoo { Swift.print("oops, this optional thing wasn't optional") }
Swift.print("now \(foo) is in scope and non-nil")
so I have this "member" in a class
class XXX: UIView
{
var member: BBB
init()
{
super.init()
self.member = BBB(self.frame)
}
if I do this, I got the error that self.member is not initialized before super.init
if I move it to before super.init, self.frame isn't available.
my solution to this chicken-egg thing is putting a ? after "member"
let member = BBB()
init()
{
super.init()
member.frame = self.frame
}
Note that since this is a UIView subclass, you're actually implementing init(frame:) and init?(coder:), not init(). I usually unify the two by declaring subviews as lets and initializing them in a private setup method.
extension MyViewController {
func myFirstSwiftFunc() -> Bool {
return true
}
} NSString *s = @"Swift is the future";
UIViewController *vc = [[UIViewController alloc] init];
NSArray *names = @[@"John", @"Paul", @"George", @"Ringo"];
let s = "Swift is the future"
let vc = UIViewController()
let names = ["John", "Paul", "George", "Ringo"] let s = "Swift is the future"
let s:String = "Swift is the future"
let s: String = "Swift is the future"
If you are interested in getting into Swift programming, don't let these article fool you into getting discouraged. This article is simply spreading Fear, Uncertainty and Doubt.
Of course Apple are using Swift, but they're not going to rewrite everything in it overnight. Heck, they probably aren't ever going to rewrite. Swift will only be used for new stuff.
...to RE-WRITE them in Swift.
Although Objective-C got nullable arguments, it still isn't as safe as Swift. You're always a null pointer away from a crash... or unexpected behaviour as calling shit on nil doesn't matter