AppCode 3.3.2 Release Candidate

AppCode 3.3.2 Release Candidate (build 143.1183) is available for download. The patch update is also available if you are using previous 3.3.2 EAP build.  Since this build is RC for minor update, it requires an active license (alternatively use the 30-day free evaluation).

This build delivers one of the important features for Swift debugger – support for watches and expression evaluation.

evaluate_expression@2x

Now you can view values of variables added to Watches tool window, evaluate Swift expressions using Evaluate expression… action (Alt+F8) and benefit from code completion for both cases during debugging your Swift projects.

The list of other fixes and improvements can be found here. Feel free to share your feedback in the comments section below and submit feature requests and problems to our tracker.

Develop with pleasure,
The AppCode Team

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

16 Responses to AppCode 3.3.2 Release Candidate

  1. Frank says:

    Thank you!

  2. Stewart says:

    Fantastic!!!

  3. Stewart says:

    Seems like Evaluate Expression for Swift still needs improvement.

    Evaluating a TableViewController, drilling down to a label shows:
    “value is not of a pointer type”

    Instead of the actual object.

  4. AppCode says:

    Apple open sourced Swift, will you make AppCode available on linux ?

    • Stanislav Dombrovsky says:

      Not in the near future. Anyway, feel free to upvote https://youtrack.jetbrains.com/issue/OC-12853

      • AppCode says:

        That’s not a move that should come from us

        You should decide if it’s a good idea or no, as a buisness you should take initiative to be up to date with current technologies

        I expected from you to say, “Yes we will, in the near future, since the language now supports linux it’s a normal move” :/

        You have EAP for this, don’t wait for official release to decide if you should work on it or no.. or other people will take the lead

        Well everything i say is only personal opinion

        • Stanislav Dombrovsky says:

          That’s not a move that should come from us
          You should decide if it’s a good idea or no, as a buisness you should take initiative to be up to date with current technologies

          In fact, the most of our decisions are based on our users’ feedback, so we do not force you to decide – we just looking on who is really interested in some feature. Making decisions based just on our thoughts is a wrong way in my opinion.

          I expected from you to say, “Yes we will, in the near future, since the language now supports linux it’s a normal move” :/
          You have EAP for this, don’t wait for official release to decide if you should work on it or no.. or other people will take the lead

          We are limited with resources and we need to focus on features that most of our users expect. For now all our users are OSX/iOS developers, they expect features described in our roadmap to be implemented in time and finally it’s completely not clear how many Linux developers will prefer Swift in the near future.

          Building separate IDE version for Linux requires a lot of efforts – like changing project model (no Xcode), integrating toolchains that were just out-sourced, changing debugger structure etc. It’s not that simple like creating one more EAP build.

          • AppCode says:

            Thanks for your detailed reply, i can understand, lets hope it will be a reality then, Swift is a really nice language

  5. Hey guys any ETA on when parsing/indexing libraries is going to be supported?

    With the limitation of 3rd parties libraries not being parsed/indexed by the IDE it makes the current state of Swift pretty unusable for any real-life project. Most mobile projects these days have tens of libraries that developers need to leverage, everywhere from promise frameworks to networking to filtering (ie: SINQ) to logging libraries – some of which are used on a regular basis and not just in isolated areas of the codebase.

    AppCode doesn’t seem to currently parse these libraries (Cocoapods integration) and doesn’t provide any completion on them, while Xcode does. This makes it very difficult/impossible to work within AppCode without having to switch back & forth to Xcode constantly even while writing a simple method.

    Any ETA on when this functionality is going to be supported?

    • Stanislav Dombrovsky says:

      I’ve just tried to do the following:

      1. Create Swift project in AppCode from scratch with build build 143.1183
      2. Create Podsfile and add pod ‘SINQ’ together with use_frameworks! etc
      3. import SINQ

      and completion for function names for example works for me. Are using Swift frameworks from Swift project, or you are using Swift frameworks from Objective-C project? Or some other variant? I’m asking because issues with resolving Swift symbols from Objective-C code still exist and I want to understand if you experience some issue we do not know about. So, any additional details/small test project will help us a lot.

      • Thanks for the prompt reply Stanislav. I have tried using AppCode with 3 separate projects (2 of them mix Obj-C & Swift and the present one pure Swift). I don’t remember having either of them have any auto-completion/parsing work for any 3rd party libraries from Swift code.

        Please let me know if there are any switches/toggles/setup that I should try. I thought this was simply an unsupported scenario since I’ve never seen it work yet.

        Here is our current Podfile:

        platform :ios, “9.0”
        use_frameworks!

        # networking
        pod ‘Alamofire’, ‘~> 3.1.1’
        # continuations
        pod ‘Bolts/Tasks’, ‘~> 1.4.0’
        # presentation
        # pod ‘Oil’, ‘~> 0.1.0’ # SWITCH TO THIS ONCE LIBRARY IS OUT OF RAPID DEVELOPMENT
        pod ‘Oil’, :path => ‘~/Documents/Libraries/Oil/iOS’
        pod ‘AlamofireImage’, ‘~> 2.0’
        pod ‘Observables-Swift’, :path => ‘~/Projects/_LIBRARIES/iOS/Observables-Swift-FORK’
        pod ‘SINQ’, ‘~> 0.5.0’
        pod ‘BrightFutures’
        pod ‘SwiftDate’, ‘~> 2.0’

  6. Ibrahima Ciss says:

    Nice features. I’ve just bought a licence for my day to day iOS Development.
    The thing is am on a project currently and coding in Xcode is very hard, really poor experience.
    But my project require some dependency through CocoaPods and when I import the classes in my ViewController, some errors are thrown because Appcode can’t resolve the imported classes and am unable to work with the IDE right now with that project while Xcode works just fine with CocoaPods classes.
    I hope that now Swift is Open Source, some improvements to the IDE can be applied quickly.

    • Stanislav Dombrovsky says:

      Can you please submit a ticket to our tracker and give us some more details (short code example that does not work for you, or some small test project that will help us to reproduce the issue, or just a screenshot of the code piece that does not work for you)? Just to understand which issues are you exactly experience and fix it.

Leave a Reply

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