How much is Apple really using Swift?

“Apple has been actively evangelizing the use of Swift since it was announced at WWDC in 2014,” Ryan Olson writes for Medium. “Swift has quickly gained popularity among many third party developers, but what about for Apple’s own code?”

“As of iOS 9.2, Calculator.app is the only place in the system that you’ll find any Swift,” Olson writes. “I expected to find at least a few other apps or frameworks that had incrementally adopted Swift for new code, but that doesn’t appear to be the case for now.”

“Calculator.app is actually almost ‘pure Swift’ with only 2 of its 22 classes written in Objective-C,” Olson writes. “The Apple Store app is also using Swift for its watch app. That’s about all the production Swift I could find from Apple on iOS.”

Read more in the full article here.

MacDailyNews Take: This cake needs some time to bake. iOS 10 will really begin to usher in the Swift era.

MacDailyNews Note: Obviously, today is Martin Luther King Day in the U.S. and the markets are closed. As usual on such trading holidays, we will have limited posting today.

SEE ALSO:
Apple’s open source Swift will open the door for HomeKit – December 16, 2015
Apple has hugely ambitious plans for open-sourced Swift, and hints on what’s coming to iOS – December 15, 2015
After Apple open sources it, IBM puts Swift programming in the cloud – December 4, 2015
Apple officially releases Swift programming language as open source – December 3, 2015
Apple’s open-sourced Swift programming language could change everything – November 25, 2015
Apple’s Swift programming language could soon infiltrate data centers – November 24, 2015
Developers band together to create Mandarin Chinese translation of Apple’s Swift programming language – August 6, 2015
Apple’s Swift breaks into top 20 in dev language survey; bad news for Microsoft’s Visual Basic – July 2, 2015
Apple’s Swift: The future of enterprise app development – June 10, 2015
Apple previews iOS 9 for iPhone, iPad and iPod touch – June 8, 2015
Apple prepares for major enterprise push by making Macs, iPhones, iPads easier for IT to support – June 2, 2015
Apple+IBM: Enterprise apps go wearable on Apple Watch – May 24, 2015
Apple’s iOS continues to dominate the enterprise with 72 percent of all device activations – May 11, 2015

24 Comments

      1. Apple abandoning projects is well know, yet Apple knows best where it wishes to play the puck. If Apple feels things are in decline or going sour or simply find a better solution – this type of Action merely expresses how well Apple is willing to Adapt. A great and successful company adapts to changes that are in-line with their goals. Not to defend Microsoft in anyway, yet they were once a grand and powerful company – yet their loses never had new and good solutions – change came for them and the dinosaur dug its grave.

    1. Why on earth does Apple require writing OS X or iOS; or any part of it in Swift? It makes no sense to me at all. I would imagine Apple write OS X and iOS APPS in Swift but not the OSes. In fact I would love Apple to bake OSes with ultimate secret development application and code unseen by any company out there – to better protect the platform. PERIOD.

      1. Why on earth does Apple require writing OS X or iOS; or any part of it in Swift?

        Because the most common errors in C, C++, and Objective-C that lead to crashes and security issues are just about impossible to write in Swift.

        -jcr

    2. I’d like to see WebKit rewritten with Swift, including the build processes, which currently use a weird mixture of languages.

      The Swift version of WebKit should be open-source, like the current framework.

    3. BOB: I think that might be a great idea, when Swift is capable of rewriting OS X!

      But the stodge and lumbering stoicism in coding is now infamous. Study the history of Microsoft Windows and you’ll be stunned at the ancient crapcode still embedded in the monster. Apple can be JUST as guilty. Occasionally I STILL run into ancient code inherited from Mac OS 9, gawd help us, that thinks there has to be a 32 character limit to file names. NOT KIDDING. Years back I ran into one of these, what can only be called ‘bugs’ of ancient inheritance and Apple themselves were utterly flummoxed. That’s how horribly bad code inheritance can be. Object oriented programming didn’t help stop this nightmare at all. It simply packaged the bad code, then no one bothered up upgrade the packages.

      With this in mind, think about artificial intelligence coding. Yeah, that’s gonna happen. Artificial insanity is far more likely. *clunk*clunk*clunk*

    1. In deed, and Swift already is in the top by users. There is a massive interest and many have several likes and dislikes about it. One man even has attempted to develop an OS with it. Yet, for Apple to do this – its rather silly. Swift is for the masses – to speed and better development of APPS not OS.

  1. Swift is still going through large transformations and is extremely early. It doesn’t make sense to use Swift to build anything extremely large or complex, especially something like an operating system, when basic structure and philosophy of the language is still in heavy discussion and design. Swift 3.0 will be the biggest leap towards solidifying the language and locking in the ABIs and basic culture of the language and its best use practices. Once that happens, Swift will begin to show itself in all corners of Apple software development. But we aren’t there yet, and I don’t expect Swift to be used for any big projects internally at Apple until it matures.

  2. They’ll use it in time. It’s a young language and they just open sourced it.

    It’s going to take a few years to happen, its a long term investment, not an overnight party.

    They likely won’t rewrite one of their OSes in it. Maybe it will be used for a future OS but I doubt they’ll rewrite OS-X in it just for the sake of doing it.

  3. They started to in El Capitan. See :

    http://daringfireball.net/thetalkshow/139/federighi-gruber-transcript From the Link :

    “FEDERIGHI: We have all types here within Apple. They start out with the “I love Objective-C. I don’t want to change” to “OK, maybe there’s something to this Swift thing” to “Let me give it a try” to “I love it.” We’ve gone through all the phases internally. You know, we’ve had some really great adoption by teams like … the team that does the Dock and the window management on OS X, implemented all their new features for El Capitan in Swift and started mass-converting all of their code, and say that they couldn’t imagine going back and that they’re more productive with it. Part of what our internal teams need to deal with, though, is that they’re working on, let’s say, the current version of Swift 2.0 while it’s not done yet. I mean, while it’s not even WWDC-level done yet, right? And they’re working on the interfaces in terms of our internal frameworks that haven’t been modernized for Swift. And so, they’ve got it rough. They’ve got to really love it to make that leap because they’re working on a very, very bleeding-edge environment when we use it internally. Thankfully, with Swift 2.0 now well out the door, that’s stabilized things a good bit and they’re really open to it.

    But there’s been just lot of feedback. And a lot of it has helped with the impedance, making sure the impedance between Objective-C and Swift is absolutely minimized because of course we have and will continue to have and continue to write more Objective-C code, and so the ability of Swift and Objective-C code to work together completely naturally is a huge focus. A bunch of things like generic collection, support for lightweight generics in Objective-C, were big pain points internally and something we fixed in the language, and is now great for all of our app developers externally. So, it’s been a not dissimilar road for us internally to what you see outside.

    But in terms of Swift and writing big apps, it’s certainly the case that when Swift 1.0 came out — heck, we didn’t support incremental compilation in the very first update. And so that was going to be a limiting factor for productivity for people who had big apps. A lot of that stuff has changed. And then in 2.0 having a good error-handling model, having the availability check so you could span API versions — these sorts of things. I think it really addressed the vast majority of pain points that we were experiencing, that I think the community was experiencing about writing larger apps. And so much about Swift is actually inherently better for building big apps because it handles modules and namespaces in a way more naturally than in Objective-C. It makes the API contracts a little more clear, the code more obtainable. So, we’re very comfortable.”

  4. Swift is probably being used in a lot more ways than can be seen than just an app. It’s also a systems software language, so it’s quite possible that the hardware drivers are being written in Swift.

    From my understanding as well, Swift does not support 32-bit. The transition to 64-bit on mobile will help out increase how quickly Apple adopts Swift on iOS when 4S and 5 support gets phased out.

    Sadly it will take the Mac a while as PCs need to be supported much longer.

    Remember, Swift is a language bet for the next 20 years. The transition to it is not going to be overnight, but relative to other languages, it’s adoption has been very fast.

  5. It’s a bit stunning how immature Swift is, even from the POV of coders within Apple. The Swift presentations by Apple have spun plenty of hype, but IRL it’s taking time to grow up. That’s one reason Apple made Swift open source. Apple literally want some help with it in order for it to live up to its hype.

    I have high hopes for it. But it really is still a baby with lots of promise yet to be proven.

  6. Swift is an application language. OS X and IOS are both based on Darwin, a C (basically) language project. TO maintain compatibility with the rest of the Darwin community they will not rewrite the base OS code. Swift will (should/might/could) appear in places like pages, numbers, and so forth. Many of these projects are really huge and introducing the new language is likely to be a slow process at best.

    1. Apple says it can be used for system programing. C is the problem. Though I love the language, pointers really make the language difficult. Way too many un-defines , and un-specifies in the language which lead to security holes. If swift is faster, no pointers, well at least not implement as C does it, then they may as well get on with implementing BSD in Swift. Plus they could dump some worthless outdated code when the rewrite BSD.

Reader Feedback

This site uses Akismet to reduce spam. Learn how your comment data is processed.