#Appcode code#
Still, JetBrains eventually added more code manipulation. So when a new language feature came, AppCode users often had to wait. In a race to keep up, you are always going to be behind. AppCode’s support for refactoring Swift was bare-bones to start with, but they were in a race adding language changes, and couldn’t afford to add refactoring features. New language features (with new syntax) started flying in. I told my coworkers, “You can come back now, it handles Swift just fine.” But they didn’t come back. It became possible to use for real projects again. Even as they did, Apple kept issuing changes to improve the syntax with special transformation rules, which AppCode had to add (after the fact).īut over several releases, AppCode improved in both performance and reliability. So this was another problem that JetBrains had to solve. From a coder’s perspective, trusted Objective-C features became worse. AppCode features suffered when they crossed this language boundary, because a good IDE answers these basic questions:Īcross the language boundary, the answers were sometimes incomplete - and thus wrong. We also needed cross-language support: Swift calling Objective-C, and Objective-C calling Swift. AppCode’s usability suffered, and my coworkers who had been using AppCode… well, they stopped.Īnd this wasn’t just support for a single language. So they had to catch up, adding basic Swift support. JetBrains, the makers of AppCode, was suddenly left with an IDE that didn’t work for modern Apple development. This new programming language was type-strict, with a lot more syntax. That’s because compared to Xcode, its support for automated refactoring was overpowering. Though AppCode users were a small minority, some of my coworkers used it at least occasionally. You can still build old Objective-C projects today, with no changes. A big shift to Objective-C 2.0 happened in 2007. Remember, Objective-C dates back to the early 1980s. Remember pre-Swift days? Objective-C was the tool for working with almost everything in the Apple ecosystem.
But I think SwiftUI struck the final blow. They will provide bare-bones updates for compatibility and security through the end of 2023. And with the addition of Inline refactorings, my Swift coding accelerated even more.īut as JetBrains announced their latest release of AppCode, they dropped a bomb: this is also their final release. There are very few tasks (such as changing project settings) for which I prefer Xcode. If you’ve seen any of my live coding, you know that AppCode is my preferred IDE for Swift.
0 kommentar(er)
