AppCode 3.2 Release Candidate

AppCode 3.2 Release Candidate (build 141.2455) is out today!

A few days left before the official release of AppCode 3.2, and we really appreciate your feedback at this stage. If you find any bug at all, please file an issue in our tracker. The build is available for download on our confluence page. Please note that to use AppCode 3.2 RC you need to have an active license (or start a 30-day trial period). To see the list of the issues fixed in this build, please go to the tracker.

As you may have already noticed, AppCode 3.2 officially supports Xcode 6.4 on OS X 10.10 and Xcode 6.2 on OS 10.9.

The one question you may all be asking though is, what about Xcode 7.0 and Swift 2.0?

Short answer – some parts are already in development, others will be started soon after the AppCode 3.2 release. But we believe you also deserve a longer and more detailed answer as to why.

In June 2015 at their WWDC, Apple announced a few surprises. Amongst these were Swift 2.0 support, generics in Objective-C and a few other things that could impact our roadmap. At the time we were working on Xcode 6.4 and Swift 1.2, mostly addressing resolve issues (especially for mixed scenarios where Objective-C and Swift code are used) and also trying to bring as many smart features to Swift as we had planned, such as override/implement code generation features, improved navigation, quick documentation with inferred types and debugger support for Swift, amongst other things. These were all planned and most, if not all, were based on users feedback.

With the announcement, we had a tough choice: continue with our plans or drastically change direction and focus on Xcode 7.0 and Swift 2.0.

After many back and forths, we decided to:

  • Finish our current work on Swift smart features in AppCode 3.2 for an August release.
  • Start work on Swift 2.0 and new Xcode 7 features support for the next release, with EAP starting approximately in September.

Which brings us to this announcement and the reason why we currently can’t offer support for Xcode 7 and Swift 2.0.

Good news though is that we’re now already working on support for Xcode 7, and in fact it started before the estimated time. You can see the subtasks left in the following ticket in our tracker. In addition you can find information about our Swift 2.0 and Objective-C generics support progress.

Stay tuned not to miss the updates!

Develop with pleasure,
The AppCode Team

This entry was posted in Announcement and tagged , , . Bookmark the permalink.

25 Responses to AppCode 3.2 Release Candidate

  1. Tropper says:

    I love AppCode and without AppCode I would probably refuse to do any iOS development at all.

    But sometimes I wonder if you can keep up developing AppCode without support from Apple. It always seems to me like an uphill battle. And while Google was smart and joined forces, I find it really annoying that Apple thinks Xcode is great product.

    Xcode is great if you are new to the party, your dev-teams is a one-man-show and your app contains two views. After that Xcode gets fucking annoying very quickly.

    Sorry for the rant, just my 2 cents.

    • Ian says:

      To be fair, they were doing a more than excellent job until Swift was announced – it’s obviously been a hard year since then, and I’m only very reluctantly using Xcode for Swift development. Scouts honour, I’ll switch back to AppCode when solid Swift 2.0 support arrives.

  2. Frank says:

    Thanks for the feedback, does this mean AppCode will be incompatible with Xcode 7/iOS 9?

    • Anastasia Kazakova says:

      AppCode 3.2 won’t support Swift 2.0 and Objective-C generics, that means that code will be parsed incorrectly in many cases. To get it work with Xcode 7 (and thus iOS9) wait till AppCode next version EAP, planned for September.

      • Don Clore says:

        Can you elaborate on how Swift 2.0 will be ‘parsed incorrectly’? Most importantly to me, will the debugger be able to display local variables and class members, and do inspections properly? I can understand that this might be contingent on proper parsing of Swift, but…just asking for an explicit detailed explanation of what will work and what will not. To date, I’ve been unable to use AppCode with Swift 1.2 for these reasons. Xcode 6.4 itself is none too whippy with Swift support; auto-complete is imperfect, and the debugger…sometimes displays things correctly, and sometimes not. AppCode is so much nicer than Xcode in so many ways (I get that it’s designed to supplement, not replace,Xcode), but…at this juncture….it feels like an Obj-C only tool (and frankly, Xcode itself seems pretty wobbly on Swift).

        I look forward to a future of Swift development, but it’s astonishing to me the dev community has been willing to embrace it so wholeheartedly given that it seems so imperfectly baked, to date (here’s hoping Xcode 7 / Swift 2 and the next release of AppCode changes that).

        • Anastasia Kazakova says:

          Find the list, what’s not supported in Swift 2.0 here: The subtasks issues includes the things missing currently for Swift 2.0 support (like for example assignment keyword in operators, defer statement, protocol extensions and some more).

          Debugger will be able to display some things, but there can be problems. Haven’t checked it much for Swift 2.0 code. By the way, AppCode 3.1 was really unable to debug Swift at all – that’s true, with AppCode 3.2 you should be able to debug at least Swift 1.2.

      • Frank says:

        Thanks for the feedback and for all your hard work

      • Rodrigo says:


        Any updates in regards to xCode 7.0 support? Is now October. Thank you in advance

  3. Ian says:

    Can’t wait for the solid Swift support which I know is coming, go go Team AppCode!

  4. Marcel Bradea says:

    Thanks a lot for the update and for being transparent about the decisions. Obviously building in support for a new, evolving, and significantly different/innovative language is a hard thing to do – and we appreciate the openness and keeping the community engaged.

    Keep up the fantastic work guys!

  5. macdevign says:

    Sometimes I wonder if AppCode’s future could be better suit as the best code development platform that complements rather than trying to be a replacement for Xcode, endlessly matching its capabilities. In the course of doing so, Appcode endups continue in the pursue of playing catch-up with quick pace of XCode’s innovation. One particular area is the UI Designer that is currently for IOS, with Mac OS in the pipeline. Can AppCode leave this part to XCode for what it does best , and use precious engineering resources to focus on the language and editing support instead ? My two cents of opinion.

    • Anastasia Kazakova says:

      Thanks. Actually that’s exactly what we are doing currently. UI Designer was moved to an optional plugin recently. And we are completely focused on editing experience. Still we have to catch up Xcode when new language versions arrive.

  6. Stewart says:

    Reading the plans for Swift 2.0 – AppCode will be getting Swift 2.0 / XCode 7 support in September, starting with an EAP? Swift 1.2 support will be complete for AppCode 3.2 release, with Swift 2.0 support coming shortly afterwards?

    Is this correct?


  7. Hendrik says:

    Any chance of prioritizing fixing the Objective-C support with Xcode 7 in an early EAP build? I would assume that updating the Objective-C parser with support for generics and new annotations might be an easier task then adding Swift 2.0 support? And I believe there are still a lot of us users out there who work on Objective-C projects.
    Being unable to use AppCode while working on our iOS 9 updates is pretty painful.

    • Anastasia Kazakova says:

      Sure, Objective-C generics are already in development. We do hope to finish them before the first EAP.

Leave a Reply to Frank Cancel reply

Your email address will not be published. Required fields are marked *