AppCode 2017.1 Roadmap

Posted on by Stanislav Dombrovsky

Hi everyone,

Today we are ready to share our future plans for the AppCode 2017.1.

Based on our users feedback, we’ve decided to dedicate this release to refining AppCode. The main focus will be parsing and resolution correctness for Objective-C, Swift and mixed code, together with performance optimizations and Xcode support tasks.

Please note this is a preliminary plan, so not all features listed below may be included in AppCode 2017.1.

We are going to work on the following areas:

  • Swift:
    • Swift 3 and upcoming Swift 3.x support tasks
    • Resolution improvements (subtasks in OC-13714)
    • Performance issues (OC-11727, memory optimization)
    • Override/implement improvements (such as OC-14562 and OC-14414)
  • Objective-C and mixed code:
    • __auto_type support (OC-14428)
    • Completion performance
    • Navigation performance (such as OC-14449 and OC-12810)
    • Resolve issues related to Swift 3 support
    • Refactoring issues (such as OC-12219)
  • Xcode 8.x support tasks (OC-13906, OC-14170)
  • Navigation improvements for projects with multiple targets (OC-9050 and related)

We are planning to open 2017.1 EAP at the end of January. If you have any suggestions or questions, feel free to share them in the comments below.

Comments below can no longer be edited.

11 Responses to AppCode 2017.1 Roadmap

  1. javaguy44 says:

    December 22, 2016

    The ability to Run/Debug Extensions please! This is an extremely limiting feature of AppCode now, especially as Apple keeps pushing Extensions as a core component of App Architecture.

    It is REALLY REALLY REALLY annoying to have to jump into XCode to Run/Debug an Extension 🙁 And this is purely “code” related which is AppCode’s supposed sweetspot; nothing to do with XIB

    https://youtrack.jetbrains.com/issue/OC-10697
    https://youtrack.jetbrains.com/issue/OC-11410

    • Anne says:

      December 22, 2016

      +1

      • Ivan Gaydamakin says:

        December 22, 2016

        +1. I very wanna press CMD+R and start fast build in xcode.

        Always i code in appcode and build from xcode (because faster).

      • Marcel Bradea says:

        January 9, 2017

        AppCode team: can you guys illuminate us as to why this is not possible today and whether there are large things blocking this from happening (ie: is this something we could likely see shortly in the future or not).

        Extensions ARE a big deal for iOS 10 and would be fantastic to be able to develop them (ie: debug) with AppCode.

        • Stanislav Dombrovsky says:

          January 10, 2017

          See the answer here.

  2. Florent Pillet says:

    December 22, 2016

    Love how AppCode has become usable to write Swift code day-to-day. Now … besides the obvious missing bits of Swift 3 support, I guess it would be a good time to start supporting the wonderful refactoring features that are the hallmark of Jetbrains IDEs!

    Congrats to the team, keep up the great work!

  3. Vitor Hugo Schwaab says:

    December 26, 2016

    There’s no denying that Jetbrains IDEs’ are the best.
    The lots of resources, live templates and refactoring, it’s simply awesome.
    As a IntelliJ afficcionado and being mostly a Java/Android, it hurt’s when I have to develop something for iOS, mostly because of the lack of a awesome IDE as Android Studio is for Android and IntelliJ for Java, PHP Storm for PHP, etc.
    I do hope AppCode get’s better and better, to the point that I won’t need XCode anymore.

  4. Hadi says:

    December 28, 2016

    It would be great to fix the SourceKit integration so that errors show up in the editor more reliably, and more quickly. Are there any plans to migrate to your own code analyser (not sure what to call it – the thing that finds errors in the code)? Now that parsing and resolution etc. is pretty good, maybe this will soon be possible and the SourceKit integration can get ditched?

    • Stanislav Dombrovsky says:

      January 12, 2017

      It would be great to fix the SourceKit integration so that errors show up in the editor more reliably, and more quickly.

      In fact, 2016.3 includes a lot of performance fixes for SourceKit integration. Have you tried it?

      Are there any plans to migrate to your own code analyser (not sure what to call it – the thing that finds errors in the code)? Now that parsing and resolution etc. is pretty good, maybe this will soon be possible and the SourceKit integration can get ditched?

      It’s still a huge task, because of the frequent language changes. As soon as there will be less changes, will can consider it, but from our perspective having SourceKit as a built-in linter tool doesn’t hurt in any case.

  5. Ubaldo Cotta says:

    December 29, 2016

    I’ll really appreciate the “Remote Host” option, since now we can develop web services with Xcode/Swift using a framework like perfect.org or vapor.
    It makes necessary to upload the sources to the server, exactly like I do with CLion or IntelliJ.

  6. Mark Grubner says:

    December 30, 2016

    AppCode is definitely getting better and better with each release – thanks for the great work!

    I have full understanding for the amount of work it must be to keep up with the pace at which Apple is adding new features to the languages. It must be a bit of a nightmare actually.

    I would be really happy if the 1st priority for AppCode is to be able to display entire codebases (whether mixed ObjC/Swift, pure Swift or pure ObjC) without any red code analysis errors. I still have these in all of my ObjC files that import my Swift umbrella header for example.

    In Swift I have the habit of implementing protocols in separate extensions in the same file and these show up in the structure view with the class name only. A small improvement suggestion: append the name of the protocol that is implemented to the class name so that it is easy to see in the structure view.

    Code generation needs a lot of work in Swift when consuming ObjC. For example, create a class A in ObjC that inherits from a class that inherits from UIView. Now create a class in Swift that inherits from A and press Ctrl->O and I would expect to be able to override the functions and properties of UIView as well as the protocols and functions in class A, but it doesn’t show me them. I also get no code completion help in overriding UIView in this class. There are a lot of other examples but I guess you guys are aware of these limitations?

    Code completion is still very funky in Swift. Type “NSLayoutConstraint.in” and type Ctrl->space and I should be able to implement the init function, but it is not even listed. There are a lot of examples of missing stuff here – I hope these get fixed.

    So for me it is a lot of small things that are hampering me and cause me to have to switch to Xcode.

    I look forward to staying in AppCode 😉

Subscribe

Subscribe to product updates