State of the Union/Frustration

已完成

Dear AppCode Team,

I want to you know that I'm one of your biggest supporters and have been a loyal customer since 2002. I'm grateful for all of the thought and attention to detail that has gone into your products. I have written a lot of code with many versions of both IntelliJ and AppCode.

In my early iOS development days, I recall sending you an email begging you to consider building a tool so that I wouldn't have to use Xcode anymore. I was delighted when I received a reply indicating that this was already in progress. I have been using AppCode since the very first EAP build. It made obj-c development enjoyable rather than a painful chore. I think I might not be developing iOS software if AppCode hadn't come along when it did - you had set the bar so high with IntelliJ that there was no going back for me.

Thus our relationship remained as it had for many years where I couldn't help but promote your tools. AppCode was the only sensible way to write obj-c code. To me it seemed that the only way anyone would be happy with Xcode is if they had never experienced what an editor is supposed to be and do. Admittedly, java apps are kind of ugly and have non-standard UX etc, and AppCode isn't perfect, but I was always able to overlook any of these surface level shortcomings because there was always so much depth.

Initial Swift support was very basic and I assumed that this was just the first of many wonderful steps toward your plan to take over the world (I would have followed you!). I was excited just thinking of how great Swift development would end up being and waited with bated breath for every build, every release. For so long now I've been waiting for Swift support to be what it could/should be. 

I keep supporting and paying for updates and I even keep telling colleagues that "it's coming", but I'm still waiting. I see that your plans are to continue working on Swift support, but I'm losing hope. Today I saw the announcement of a new EAP build with the sentence starting with "This update brings one of the long-awaited Swift code editing features - ". I got really excited reading that and was wondering "Which one? There are so! many long-awaited Swift features". I can tell you that I wasn't thinking of "code folding of declarations".

This moves me from frustration to somewhere closer to anger. Who cares about code folding!? Also, who honestly uses AppCode for a UI Designer!? I don't care about small improvements to C++ right now. I don't need better Podfile support. Build after build I see stuff like this. I'm happy to see that you're fixing Swift issues etc, but there's no magic. Where's the magic?

I'm saying all of this because I care. I really care. I want this product to be as good as it was (and what it should be). I use to promote AppCode within our (large) iOS development team, but I can't do that anymore. I feel like you've lost your way. In my opinion, your house is on fire and you need to sort out your priorities. It's an emergency. Figure out how to deliver the magic as soon as possible or risk losing the battle. 

God speed!

Michael Beauregard

 

0
Avatar
Permanently deleted user
正式评论

Thanks everybody for all your comments and for your support. Three month later - and we have:

  • Swift SourceKit inspections with quick-fixes. Same as in Xcode
  • Improved Rename for the mixed code and new Introduce Variable for Swift
  • Parameter placeholders for Swift functions
  • Live Templates for Swift
  • New documentation features for generating comments in Objective-C

and more other features in AppCode 2016.2 EAP. Hope, we can now call it good old JB magic )

 

I just want to say that I have moved back to appCode from Xcode for most of my Swift development. I am using the EAP, and yes there are some warts, but the completions are finally in a pretty decent state aside from the performance issues in the latest build, and they have built out the internal infrastructure to add all the code insight and language IDE features that we have come to love. I feel they are just on the cusp of really being an awesome Swift tool, so I have jumped back onboard and made a real effort to start using the IDE and report issues on the tracker so they get resolved.

I suggest that if you really want to see appCode's Swift support improve you get involved yourself.

Since I have started using appCode again as my primary editor for Swift, I have been wanting to develop a plugin to enhance the Swift support myself - to fill in the features that I personally miss.

I already have a few things implemented and I am trying to figure out what else I want to include before I release it. I am also waiting to see what happens in the next sprint or two on the JetBrains side, because so many major language features are currently listed as in progress and scheduled for either the current or upcoming sprint (i can't tell what their sprint schedule is).

Swift is a moving target, but just looking at the way the IDE understands the Swift code now vs. last year, I can see that the infrastructure is there and that it is just a matter of time until we see the features we have all come to know and love from JetBrains IDE's.

1

Well, I'm new to the community and I just finished my 30 day trial of AppCode. As the "new guy" on the block, I hope you'll allow me to weigh in.

I think it is a good product, but yes, it does lack some features I would have expected to be there. That being said, I'm not inclined to make a purchase NOW but will very likely do so in the future. What is stopping me? The license. Allow me to explain...

If I buy this software outright for a year, I get a perpetual license back to the version available on the day of my purchase, in other words, 3.3.X. 3.3.X is nowhere near the competition's products. Do I think it will get there? Sure. As a developer I know great code doesn't happen overnight and I am sure there is a team of programmers banging away on their keyboards trying to get things done.

Until that happens though, I'm not sure I can make the plunge. And believe me, I *want* to give you my cash for a great IDE. 

Please get there soon.

 

0
Avatar
Permanently deleted user

Michael, 

I'm really sorry that some words from the latest post about new code editing feature for Swift make you fell this way. And we understand, that some of the Swift features can be much more important from your perspective. Let me explain some changes you've mentioned:

>Who cares about code folding!?

It's not the main direction of our work. But we cannot say that nobody cares because of the number of users in our support stating that they strongly need this feature. And we did not spend many efforts on this tasks, because we were able to implement it very quickly - so, we just implemented it, we did not spend significant time on it. But we made the IDE experience better on the way to bigger changes. 

>Also, who honestly uses AppCode for a UI Designer!?

Here I did not get you, because there were no changes in any of EAP builds about UI designer. We stopped working on it just because language support tasks for now are more important for us. 

>I don't care about small improvements to C++ right now.

There were about 80 tickets, as I remember, covered by the changes we've mentioned. It was a massive overhaul of C++ parser made to address issues that are really important for C++ programmers. But the main thing is that AppCode team did not spend its efforts to implement them, because all these changes came from the CLion team. We share the same codebase with the CLion for C++, and we receive these changes without significant efforts. The same situation is for platform changes, because AppCode is built on the top of Intellij Platform and any change made in platform usually will be automatically available in other IDEs. 

>I don't need better Podfile support.

Again, efforts here were not significant. Changes that were made address keywords that can be used by the Swift programmers - and not implementing this task will not speed up more important tasks. If we have a choice between "make the feature without influence for more important tasks that require more time and that we cannot roll-out for now" or "postpone this feature and not make it, but not speed up any other tasks" - we usually implement it. 

>I'm happy to see that you're fixing Swift issues etc, but there's no magic. Where's the magic?

Some information about magic mentioned in the roadmap. First, all these tasks cannot be more parallelized comparing to how we work for now. They are made by the dedicated members of our team who work 90% on this tasks. For now we cannot speed up them, because all these tasks are really too complex. Good news:

1. Showing warnings and errors in editor is close to internal testing. 

2. Huge amount of mixed code improvements is already in internal testing. All these improvements are made for better parsing/resolve between Objective-C-Swift code and will allow Rename to work in 2 languages much more better. 

3. Tasks that we need to implement Swift refactoring are also close to internal testing. 

In short, we are close to show some magic, but we need to test it internally, then we need to test it during EAP period to be sure that these changes will work correctly. We thought that we will be able to deliver it in 3.4 - for now we understand that dye to the amount of changes we made it will not be possible in the current release. 

If I did not get you right we the changes you expect - please, share your thoughts and I will try to give the relevant information to you. 

0

Stansislav,

Thanks for the reply. I'm glad to hear that we can expect some of the good old JB magic in EAP soon. My frustration is mostly based upon the fact that we've waited for so long for Swift support features, features that represent the majority of the value expected from any product based on the IDEA platform. 

I believe the UI Designer was a misguided use of your amazing talent and felt like another case of being distracted from the core value of the product. But perhaps it was a bit unfair to heap that into this argument since I realize development on the UI designer has since been halted. Also, I'm aware that certain recent improvements are inherited from CLion and IDEA platform, but any distraction at all from the critical Swift support features after having been waiting for so long can understandably be perceived as continued lack of focus.

I've continued to pay my subscription fees based on the assumption that the necessary Swift support features are imminent, but have so far been let down. Although I have enough experience with your past products to know how good this product should be, new customers likely won't have as much patience. I'm glad to hear that Swift development seems to be moving again.

Michael

 

0
Avatar
Permanently deleted user

Guys, 

Thank you for supporting us and sharing your thoughts. It's really important and it's really valuable for us. 

And in any case, if everybody is ready to write some plugin/integration - please, contact me at stanislav.dombrovsky [at] jetbrains.com and I will connect you with the development team, so we will be able to help at any stage. 

0

Jon, I haven't stopped using AppCode. I've used it full time since the very first EAP in 2011. My rant above was the result waiting (and paying) so long without the usual language support I've come to love (and expect) from the awesome JetBrains products over the years. I'm glad we finally see lots of Swift support features are coming. I'm relieved that I don't have to consider switching to Xcode any time soon.

BTW, although it's not Swift related I already wrote a plugin that improves the scheme/device selector:

https://github.com/mjbeauregard/appcode-scheme-selector

Stanislav, I'd love to have/write a proper warning and error renderer plugin, but after putting some effort into doing this I couldn't find any related APIs to tap into. Let me know if you believe a third party plugin can get access to the necessary info (build output).

 

 

0

I just thought I would show you the state of my plugin.

 

And

Not a whole lot of features, but it is a start. Anyone wanting to become a contributor, please let me know.

https://github.com/sylvanaar/appCode-Swift-Extensions 

 

0

The first image was my implementation of a feature request I made:

OC-13332 Provide Semantic Coloring Options for Optionals

The second, was a bit of low hanging fruit, the read/write access detector I implemented just to see if I could add functionality to the Swift plugin.

I don't want to hijack the thread, so, I'll leave it at that.

0

I too have a growing amount of problems with AppCode in many areas, not just Swift. The instability and the recurring cpu-usage problem are driving me nuts (and yes, I have tried a lot to fix this). When the fan of my Macbook kicks in, my colleagues say "ah, he started AppCode again".

After using AppCode unto  80% of the time since the first beta, I meanwhile only use it like 20% because of all of the problems with it. I really like the concept, but when I look at Android Studio (which work fine for me), I get the feeling that AppCode has been dropped.

I hope this is not the case.

0

AppCode Team,

I'm really grateful to see so much progress in the last few months. Thank you so much for all of your hard work - it's really coming together now! 

I'm happy to start getting back into the mode where I make Xcode users jealous while screensharing with screenhero. Keep it coming!

Cheers,

Michael

0

请先登录再写评论。