AppCode starts 3.2 EAP with hot mix of Swift support improvements and new platform features

Anastasia Kazakova

Hi everyone,

With summer right here, we couldn’t wait any longer. The Early Access Program for AppCode 3.2 has launched!

It’s been six months since we released AppCode 3.1, which was mostly dedicated to Swift. Our top priority hasn’t changed, but there are quite a few other things on the plate, too! Read on to learn what’s inside AppCode 3.2 EAP and download the first build from our confluence page.
splashAppCode_Tascalate

Mixing languages

We delivered basic Swift support in June 2014, soon after WWDC 2014. We then took a big step forward in October 2014 with AppCode 3.1 EAP, offering deeper Swift support. Since v3.1, AppCode supports resolving Swift symbols in Objective-C code. We’ve grown up and can now resolve in the opposite direction, too: Objective-C symbols in Swift code.

What does that mean from a practical point of view? Benefit from code completion, navigation, Find Usages and Rename refactoring now throughout your whole codebase, no matter what programming language you are using: Objective-C, Swift, C or C++. Some limitations and issues are still there, we’ll share them below and continue our work in that direction in the next EAP builds.

As far as Objective-C symbols are now resolved in Swift code, completion for Objective-C code in Swift is available and shows the corresponding Swift type:
objc_in_swift_completion_blog

Go to declaration (⌘B) / definitions (⌥⌘B) as usual jumps to the symbol declaration/definition for all mixed cases (Objective-C symbols in Swift, and vice versa), while Find Usages (⌥F7) lists all usages of the current symbol. However, Find Usages for Swift methods used in Objective-C code is not ready yet.

The Rename refactoring automatically corrects all references in the code for you, even those found in comments, strings and non-code files:
refactor_rename_blog
Feel free to rename Objective-C or Swift classes, no matter where you use them. As for methods, Objective-C methods used in Swift rename invokes change signature refactoring, while Swift methods in Objective-C code rename is still in development.

In case you feel lost in main Swift features supported in this AppCode EAP, check this table. It gives a short list of main features like Completion, Find Usages, Rename refactoring and some navigation features as applied to Swift and mixed Objective-C and Swift code.

Interpolation of Swift strings

String interpolation is a nice feature that is used to combine strings in Swift. AppCode now highlights the symbols used in such strings and helps you complete symbol names:
string_interpolation_blog
And of course, when you Rename, all symbol usages will be corrected automatically by AppCode for you.

Navigation in Swift

The left-hand gutter can be very helpful while navigating through the code. If a function overrides / implements or is overridden / implemented by some function, it is marked with an icon in the editor gutter:
gutter_navigation_blog
Previously this worked in Objective-C, C and C++ code, and is now available in Swift. From now on, navigate to the derived class more easily:
subclass_navigation
This also works while navigating from Swift to Objective-C super/inherited methods and classes.

Show usages for the declaration

As you know, navigating to the declaration/definition is easy with AppCode. You just use special icons in the left-hand gutter to jump to the declaration of a symbol (⌘B) or its definition (⌥⌘B). And now, if standing on a declaration, Go to declaration serves as Show usages:
find_usages_on_declaration_blog

VCS improvements

Sometimes the default side-by-side diff view is not very easy to use. The more compact one-side view is here to help, showing the difference between revisions on one page:
Oneside_view_blog
If you switch between files, the viewer remembers your caret position in the file.

The Log viewer for Git and Mercurial now can filter by repository. For better clarity, each repository is indicated with its own color. Commits by the current user are now highlighted.

Synchronous HTML tag editing

If you need to edit HTML and XML code in AppCode, this new feature makes it easier. Edit any tag in your code, and AppCode will fix the corresponding opening/closing tag for you. It’s on by default, but can be switched off in Preferences/Settings | Editor | General | Smart Keys. Watch this small demo to see how this works.

Distraction-free mode

If you prefer minimalism, a brand-new Distraction-Free mode is now available in AppCode. Toolbars, tool windows and editor tabs are all hidden, the code is center-aligned on your screen, and now nothing prevents you from pure coding. To turn it on, click View | Enter Distraction Free Mode.

Other notable changes

A long list of fixes and improvements can be found in our tracker. Here are a few worth mentioning:

  • The File Structure view in Swift now has an option to show inherited members.
  • The performance of Swift editor has improved greatly. If you are developing in Swift regularly, please check it and report any problems you may find.
  • We’ve also fixed the problem with build locations – AppCode now respects the output directories hierarchy specified in the target build settings (some more changes are on the way).
  • Thanks to CLion, our newest member in the IntelliJ-based family of IDEs, many goodies for C and C++ code borrowed from CLion are included in AppCode as well.

UI Designer moved into plugin

As you probably know, AppCode has had its own built-in UI Designer since v3.0. We’ve put quite a lot of effort in it. However, because of our focus on supporting Swift language, we are currently unable to give UI Designer features the attention they deserve. We understand that you are missing many important features such as support for Xcode 6 universal storyboard format. We’ve decided to set the default UI tool to Xcode’s Interface Builder, and to make our UI Designer an optional plugin instead, which you can install from our plugin repository. From now on, when the plugin is not installed, .xib and .storyboard files are automatically opened in Xcode, while AppCode provides you the xml representation. If you would like to open these files in UI Designer by default, install the plugin, and AppCode will behave the same way as it does in v3.1.
Our plans for the UI Designer plugin are undecided. We will be focusing primarily on Swift, smart editor support, refactorings and other features that make AppCode unique to our users. We may prioritize UI Designer in the future, but cannot promise anything concrete. Thanks for your understanding and continued support of AppCode.

OS X and Xcode supported versions

One more important thing to mention here – the supported OS X/Xcode versions have changed a bit. For OS X 10.9 use Xcode 6.2 in AppCode, and for OS X 10.10, please, select Xcode 6.3+.

Build with custom JDK

You probably know that we do recommend Apple JDK 1.6 because of the critical issues with JDK 1.7 and JDK 1.8. But with the update to OS X 10.10, users have noticed a very annoying graphics glitches. Recently we’ve started our work on a custom build of JDK 1.8 with fixes by the JetBrains team. Finally we have a new distribution package targeting those OS X Yosemite users who experience graphical glitches with Apple JDK! If you’re already used to JDK 1.8, you can try this as well. Some font anti-aliasing problems have been addressed there. Please note this non-default option may contain some issues and performance problems. As this is still a work in progress, we – as always – greatly appreciate your feedback, comments and issue reports here.

This is just the beginning for AppCode 3.2, and we’ve got lots more interesting features coming! Check this EAP build, follow the updates and report any problems found to our tracker. Your feedback is more than welcome!

P.S. In line with our code-naming tradition, this version is code-named Tascalate. Tascalate is a Mexican drink made from a mixture of chocolate, ground pine nuts, achiote, vanilla and sugar. How do you feel about this one? On the practical side, it’s another tag in our blog to find information on specific AppCode versions: Just search for Tascalate to find posts about v3.2.

Develop with pleasure,
The AppCode Team

Comments below can no longer be edited.

66 Responses to AppCode starts 3.2 EAP with hot mix of Swift support improvements and new platform features

  1. Tomas says:

    June 3, 2015

    How is it with support nullable/nonnull for Objective-C in EAP? In latest stable build it breaks auto completion.

  2. AppCode 3.2 доступна для загрузки в рамках программы раннего доступа | Cocoa Developers Club says:

    June 4, 2015

    […] Все подробности в официальном пресс-релизе компании. […]

  3. Raphael says:

    June 4, 2015

    Thanks for the EAP!
    Actually the IDE runs very slow. It takes pretty long until the auto complete dialog pops up. And even writing code lags.. The 3.1 release runs fine.
    Do you have an idea what I can do?

    Thank you!

    • Anastasia Kazakova says:

      June 4, 2015

      Is it Swift or Objective-C code? Are you trying build with default JDK or our custom one?

      • Raphael says:

        June 4, 2015

        With Swift code and with the bundled custom JDK. I’m going to try the other one now!

        • Anastasia Kazakova says:

          June 4, 2015

          Yes, please, try with default JDK then.

      • Raphael says:

        June 4, 2015

        Yea, the build with default JDK seems to run faster!

        Great to have ObjC support now.
        Looking forward for the next releases!

        Thank you,
        Raphael

        • Anastasia Kazakova says:

          June 4, 2015

          Thanks for letting us know!

    • Matt says:

      June 4, 2015

      After trying both yesterday and today, the version without the bundled JDK 1.8 seems to run faster than the one with. Which are you running?

      • Anastasia Kazakova says:

        June 4, 2015

        Actually we are currently aware of some performance problems with custom JDK and working on them now. They are not stably reproducible in every environment, but looks like you are among those who met them. Will try to update the JDK with the next EAP build.

        • Matt says:

          June 4, 2015

          I’m actually seeing faster response times with 3.2 (without bundled JDK) over 3.1, I think because more stuff is parallelized. With 3.1 AppCode would only max out a single thread, but now it seems to be using more than one thread for doing work. Good job!

          • Bill A says:

            June 4, 2015

            Agreed – I switched from the custom JDK to the non-bundled DMG and AppCode is significantly more responsive.

  4. Petr says:

    June 4, 2015

    Hooray! Jetbrains, I love you! 🙂

  5. Bill A says:

    June 4, 2015

    Great to hear. According to the announcement, I thought that AppCode would be able to resolve my Swift symbols in Objective-C code. However, all references to project Swift symbols in my Objective-C code are underlined red, and AppCode appears to be unable to find the auto generated “Project-Swift.h” header.

    Here are the problems I ran into:

    https://youtrack.jetbrains.com/issue/OC-12003
    https://youtrack.jetbrains.com/issue/OC-12004

    • Anastasia Kazakova says:

      June 4, 2015

      There are some issues like https://youtrack.jetbrains.com/issue/OC-10865 and https://youtrack.jetbrains.com/issue/OC-11921. Could you try to clean and re-build the project? Will it help?

      • Bill A says:

        June 4, 2015

        I did try that. I tried clearing the caches and restarting. Unfortunately, no luck.

        I can reproduce with a new project, too:

        1. Create an Objective-C project in Xcode.
        2. Create a Swift class called “MyClass” that inherits from NSObject and has at least one property.
        3. Create an Objective-C class that imports “ProjectName-Swift.h” and have one of its methods create an instance of MyClass and access a property on this instance.
        4. Compile successfully in Xcode and confirm that there are no warnings or errors.
        5. Open in AppCode.
        6. The “MyClass” symbol as well as the property symbol will highlight red and won’t resolve. Cmd-clicking into “ProjectName-Swift.h” will take you to an empty file.

        • Bill A says:

          June 4, 2015

          Whoa, I got it to work! The problem is that I was importing “ProjectName-Swift.h” instead of . Although this works in Xcode, it doesn’t in AppCode. I will file a bug for this specific issue, but after making this change, cleaning the project, invalidating caches, restarting and rebuilding, Objective C-to-Swift resolution looks like it’s finally working.

          This is great!

          • Bill A says:

            June 4, 2015

            Reported as OC-12010

          • Anastasia Kazakova says:

            June 5, 2015

            We already saw that happened once. Interesting. Thanks for investigating!

          • kremens says:

            June 9, 2015

            @Bill A., your comment says:

            “The problem is that I was importing “ProjectName-Swift.h” instead of . ”

            Instead of what?

            As I understand it, you need to import ProjectName-Swift.h… to use a swift library from objective-c.

            It would be great if you could clarify, as I’d like to get this working too…

            • Anastasia Kazakova says:

              June 9, 2015

              Use “<" style for the import

          • Frank says:

            June 9, 2015

            I’m seeing similar problems, I haven’t been able to resolve Swift classes in Obj-C using either #import style.

  6. Antoni says:

    June 5, 2015

    Great to see a progress 🙂
    There are though some issues that would be great if addressed, as AppCode experience with Swift is still very sub-par compared with ObjC:

    – autocomplete for ObjC classes (or ObjC derived classes) shows suggestions sorted alphabetically, with flattened hierarchy. For ObjC AppCode works much smarter, suggesting methods from top level class first – which of course makes much more sense. In general AppCode (and other IntelliJ) products have very smart ways of sorting suggestions, which is completely missing in this case

    Would be also great if user defined functions would get more priority over build in functions and constructs – currently when I press Cmd-Space in a new line I just get a lots of gibberish

    – AppCode will suggest non-static methods and properties when used in static context (eg. UIView. will show all possible methods and properties, not only class methods)

    – there’s no easy way to determine a type of variable/constant. Eg. I write let x = functionX() – I can only click on functionX to go to it’s definition. (In XCode you get this information from “Quick Help”)
    Some ideas – add a shortcut that would display some popup / mouse over popup / some smart way to show inline (something like you do with debugging) derived type

    – I type in UIView.animate – AppCode shows me different methods to choose from. I choose duration, animation – but I only get UIView.animateWithDuration()
    Then I can press Cmd+P and see again all different possibilities, but no real support with filling in parameters. No support to auto declare a closure (adding animations in ObjC is a breeze with AppCode, 2 keystrokes and I have the method call and block ready)

    – compilation errors are still not displayed in editor (I need to build a project, and check them from messages view, even after compilations I don’t see problems in editor)

    – as code is not checked in real time in any way, of course all nice features like create missing method etc. are not available as well

    – implement/override still not working

    Probably there are more issues, it’s just a quick list of things I’ve checked for.
    Please AppCode, make it at least not worse than XCode 😉

    • Anastasia Kazakova says:

      June 5, 2015

      Thank you for the detailed feedback.

      – implement/override still not working
      Is not yet implemented: https://youtrack.jetbrains.com/issue/OC-11299. We’ll announce for sure, when it’s done.

      – compilation errors are still not displayed in editor (I need to build a project, and check them from messages view, even after compilations I don’t see problems in editor)
      – as code is not checked in real time in any way, of course all nice features like create missing method etc. are not available as well
      We haven’t yet worked on this. There is some top level ticket you can find here: https://youtrack.jetbrains.com/issue/OC-10892

      – compilation errors are still not displayed in editor (I need to build a project, and check them from messages view, even after compilations I don’t see problems in editor)
      – as code is not checked in real time in any way, of course all nice features like create missing method etc. are not available as well
      Yes, it will come later with inspections and intention actions for Swift: https://youtrack.jetbrains.com/issue/OC-10892

      – there’s no easy way to determine a type of variable/constant.
      It’s actually a part of Quick Documentation feature, not implemented for Swift yet – https://youtrack.jetbrains.com/issue/OC-11352.

      AppCode now shows the parameter info, as you’ve noticed. I suppose the assistance you mean here is parameter placeholders: https://youtrack.jetbrains.com/issue/OC-11226

      We also have plans for code generation in Swift: https://youtrack.jetbrains.com/issue/OC-11230. And completion sorting in Swift is here: https://youtrack.jetbrains.com/issue/OC-11137

      We’ll do our best to cover as much as we can before the 3.2 release, but the resources are limited, so sorry in advance if we won’t be able to get smth ready before it.

      • Antoni says:

        June 18, 2015

        Btw. when we are talking about bugs/changes, some issues from previous versions of AppCode :

        – when I have in a method for example [super viewDidLoad], clicking on it will show me a popup with all possible implementations of viewDidLoad in the app – but AppCode knows exactly which one it should be, as there’s this small blue arrow next to method name that works properly

        – I have a declaration: __weak __typeof(self) weakSelf = self; AppCode will treat weakSelf as id type and is not able to give any suggestions

        – .xcassets with subfolders will display nothing when expanded (and still Universal 3x is treated as some wrong entry)

        Feature that would be really cool to have:
        – some way to mark my own methods to be treated in similar way as some special methods from Cocoa. For example, lets say I have method – showImageNamed:(NSString *) imageName – I’d love to mark it (it would probably need to be saved in some metadata) so that AppCode would suggest me image names in the same way it does for “UIImage imageNamed:”

        Same would be nice for target: selector: pair etc.

  7. Barney says:

    June 5, 2015

    “We’ll do our best to cover as much as we can before the 3.2 release, but the resources are limited…”

    I hope you get more resources because AppCode was, and is close to again being, a wonderful product. But it’s clear you guys are short on resources. It’s taken a full year to get this far, and while a lot of fantastic progress has been made, essential functionality is still missing (like seeing errors in-line as you type). Apple will undoubtedly announce lots of new Swift and Xcode features on Monday, so it seems like it’s going to be difficult for you to catch up, given the current pace. I’m also worried that lots of people are not going to upgrade AppCode this year due to these problems, and I really hope JetBrains does not see a decline in AppCode profits and decide to reduce investment. I hope you guys get more resources in order to continue and advance beyond the brilliant work you have done so far.

    • Terence says:

      June 8, 2015

      Agreed. I am starting to regret this years renewal. I am yearning to use AppCode as it makes iOS development so much better. But since I have switched to Swift development I find myself spending more and more time back in Xcode.

      Can’t wait for the updates so I can escape Xcode again! Please keep pushing forwards as I know myself and many other developers think you do an outstanding job!

      • Anastasia Kazakova says:

        June 8, 2015

        Thanks for you support! Your words inspire us for more.

      • Raphael says:

        June 8, 2015

        Same here! Could have been my words Terence and Barney.

        I really wish that AppCode becomes as good for Swift as it was for Objective-C!

        • Frank says:

          June 9, 2015

          I second this, as both a Java and iOS engineer I spend all day in both IntelliJ and AppCode. Switching back to xcode for swift support sounds like a nightmare.

          • Tony M says:

            June 17, 2015

            Unfortunately I’d have to agree. I understand that trying to support Swift in its infancy is tough but you have a product that people are buying and renewing. You guys need more resources. Period. I don’t regret my renewal mostly because I support Jetbrains but also because I’m curious to see how AppCode as a product can evolve. For me AppCode is unusable. So for now, I’ll keep working in Xcode and open AppCode once a day to see if by miracle you guys have resolved my swift issues and not blundered resources building stupid Storyboard Editors. Sorry I’m a bit passive aggressive 😉

            • Anastasia Kazakova says:

              June 17, 2015

              What are the most annoying issues preventing you from using AppCode?

      • Craig says:

        June 13, 2015

        I love AppCode and I have faith that given continuing resources, it will evolve to be as powerful with Swift as everyone expects from JetBrains. It’s fantastic with Objective-C, and I can’t wait until it catches up with Swift.

        It offers a lot of functionality that I frankly never expect to see from Xcode, and I’m happy to renew every year to help ensure it can get there – even if I can’t use it as much as I’d like in the meantime for Swift work.

        • Anastasia Kazakova says:

          June 14, 2015

          Thank you for such kind words and your support! We really appreciate it.

    • Antoni says:

      June 9, 2015

      Well, let’s hope that with Swift being OpenSource, it will get some more love and attention from JetBrains 🙂

  8. AppCode starts 3.2 EAP with hot mix of Swift support improvements and new platform features | Dinesh Ram Kali. says:

    June 5, 2015

    […] via AppCode starts 3.2 EAP with hot mix of Swift support improvements and new platform features | JetBra…. […]

  9. Soulstorm says:

    June 7, 2015

    Great to see a new update in the works.

    However, even with this update, as with AppCode 3.1, it seems that AppCode is incapable of autocompleting / regognizing code installed with cocoapods, even in the simplest of Swift projects. I was hoping that this problem would be resolved by now in this build.

    Example:

    Create a single-view iOS Swift project, then use the following Podfile

    platform :ios, '8.0'
    use_frameworks!

    pod 'Alamofire'

    Open the .xcworkspace . Go to any file, import Alamofire, and notice that whatever method you call, Appcode cannot autocomplete or recognise it. Even command-clicking on the ‘import’ doesn’t work. Native frameworks (like Core Data) work.

    Xcode works flawlessly in this respect, which makes me think it’s probably a problem with AppCode. It’s really a showstopper for me, and the only reason I switched over to Xcode when developing for Swift.

    For Objective C, however, I don’t even open Xcode anymore, I use AppCode.

    Keep up the good work!

    • Anastasia Kazakova says:

      June 8, 2015

      Thanks. It’s even more general task, that we haven’t yet implemented – https://youtrack.jetbrains.com/issue/OC-11962. Hope to have it soon.

      Thank you for your support!

      • Torstein Skulbru says:

        June 10, 2015

        This really needs to be implemented. its the only reason why neither I or my team uses AppCode for Swift development.

        PLEASE have this included in 3.2

  10. Alex says:

    June 9, 2015

    As an avid and long time user of JetBrains product (intellij), I am a little bit disappointed in the direction taken by appcode team in regards to the ui builder. Yes, I am a beginner in iOS development, and yes, I start my journey with swift.
    I understand that experienced user probably won’t do interface design in story board, but that’s a different problem.
    Maybe once I have enough experience with iOS Dev, I won’t need storyboard anymore, and do ui Dev purely in code. But that will take a long time – and by that time, I might be too ‘attached’ to xcode. Anyway, that’s my 2c. For now, with deepest regret, I am sticking to xcode.

    • Anastasia Kazakova says:

      June 9, 2015

      We are sorry to disappoint you. But how about using AppCode for code editing, generation, refactoring and switching to Xcode for IB? Does this look acceptable for you? You’ll need Xcode for some other tasks as well, like uploading the app to App Store, etc.

      • Alex says:

        June 10, 2015

        Hi,

        Thanks for your prompt response. Unfortunately no. That would be counter productive. Editing UI happens a lot, especially for one man team. Using xcode just for uploading to iTunes connect is fine. But for UI dev ?Constant switching between different apps is just inefficient.

        Regards

        Alex

      • Raphael says:

        June 10, 2015

        Actually I like the idea of focussing on code editing only in AppCode. Apple does a great job at Interface Builder but sucks at the editor. I think it would be a waste of time building a separate Interface Builder when there is a good one.

        You have to switch to Xcode anyway when it comes to compiler settings and all that stuff.. so I think switching to Xcode is OK for editing storyboards.

        I would rather see the team focussing on Swift support! 😉

        • Juraj says:

          June 10, 2015

          I absolutely agree with Raphael that Apple does a great job at IB but their ObjC / Swift editor is only better notepad 🙂 Focussing on alternative UI designer is wasting of time and resources.

          I have done just about 10 apps with Xcode+AppCode but switching between them was never counter productive for me. Moreover when sync between changes in Xcode and AppCode was always flawless (how do you do it, Anastasia 🙂

          Swift support in AppCode, comparable with ObjC, is the only reason why I’m still waiting with renewal.

          Thanks for outstanding work, JetBrains!

        • Frank says:

          June 12, 2015

          I agree as well, I appreciate the effort your team put into building IB into AppCode but I found myself editing storyboards/nibs in Xcode. As long as code to storyboard refactoring still works from AppCode I’m totally ok with switching to Xcode for IB

      • Stewart says:

        June 10, 2015

        I always thought adding UI builder to AppCode was a bad idea.
        Its a moving target and changes regularly. IMO AppCode should be about coding – this is where AppCode excels. Leave the UI Builder to XCode.

        UI Builder is a resource sink. JetBrains are better off focusing on Coding aspect.

        AppCode is falling behind – its extremely disappointing to see – 1 year later and still poor support for Swift.

        I suppose CLion didn’t help AppCode – I got the impression resources were pulled on to CLion from AppCode.

        • Thomas Condon says:

          June 10, 2015

          I completely agree with Stewart. With all that is being introduced at WWDC, Keeping AppCode’s focus on coding make the most sense to me.

        • Antoni says:

          June 11, 2015

          What I think would be the best solution (but I’m not sure if it’s even possible) is if AppCode was a plugin to XCode (in same way as Resharper works with VisualStudio), instead of separate product (or best if it was both) – but I guess it’s not possible 🙁

          • Anastasia Kazakova says:

            June 11, 2015

            Unfortunately, it’s not possible. We were considering this option.

  11. Mellie says:

    June 10, 2015

    Hey there, You’ve done a fantastic job. I will definitely digg it and in my opinion suggest to my friends. I’m confident they’ll be benefited from this web site.

  12. Lee says:

    June 10, 2015

    Build fails immediately with the following error with xcode7-beta

    Error:/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can’t open file: /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.0.sdk/usr/lib/libresolv.dylib (No such file or directory)

    • Anastasia Kazakova says:

      June 10, 2015

      We are aware of the problem with Xcode 7b problem: https://youtrack.jetbrains.com/issue/OC-12027. This maybe the same. We’ll publish the new update as soon as we fix this.

      • Lee says:

        June 10, 2015

        I can’t view the page but sorry for the false alarm I actually have the same build error on xcode 7 as well.

        • Anastasia Kazakova says:

          June 10, 2015

          Sorry, changed the access level for the ticket. Available now. We’ll fix it and test with Xcode 7b.

          • Lee says:

            June 10, 2015

            OK thanks,

            I’m having another issue not sure if it’s related. My device no longer shows up in the device list on appcode. It’s there in xcode but not in appcode.

          • Lee says:

            June 10, 2015

            In fact none of my hardware devices show up in appcode after I installed xcode7 b1.

            xcode shows the device but appcode just shows “iOS Device” as the device.

  13. Adhi Ravishankar says:

    June 11, 2015

    I remember seeing somewhere that AppCode had a lot of its resources taken by CLion, which I must admit is a great addition to an already fantastic lineup. But now, that CLion has reached its 1.0 release, will there be a devotion of resources to AppCode once again to get it back on track? Because Apple has already released Swift 2.0 and I would hate to see AppCode in a cycle of trying to constantly get back on track.

    • Adhi Ravishankar says:

      June 11, 2015

      Also, will Swift 2.0 be supported? If not now, but in time for its fall release?

    • Anastasia Kazakova says:

      June 11, 2015

      AppCode and CLion has now two nearly separated teams. So CLion doesn’t affect AppCode too much.
      We are working on bringing more intellisense for Swift to AppCode to help you with refactorings, code generation, and more.

      Swift 2.0 of course is in our roadmap as well (https://youtrack.jetbrains.com/issue/OC-12029). But we are going first to finish with some smart features.

  14. Chris Hatton says:

    June 12, 2015

    Huge love and thanks from the Bluedot team… AppCode makes our lives better! Thanks for your dedication to the updates. Can’t wait to start using the new Swift features.

    • Anastasia Kazakova says:

      June 13, 2015

      Thanks!

Subscribe

Subscribe to product updates