I think that if you look at my posts on this topic you will find that we have not been promising a native version in "the next release". Most have been vague but say that we don't currently have a plan to release a native Mac version. By that, I mean that it is not assigned to a specific release nor is the work scheduled.
When we first did the X11 version for the Mac, it was a very natural decision. We were already using X11 on 5 other platforms, so it didn't take a lot to get it working for the Mac. At that point, we fully expected to have a native version within a release or two later. Unfortunately, the amount of work necessary was more than we could handle and still make progress in other key areas.
We would definitely like to release a native Mac version. We are still looking into ways to make this happen. Trust me when I say that no one outside of SlickEdit can appreciate the level of work that will take. SlickEdit, the product, is over 20 years old and has a lot of custom code to optimize its performance and our ability to code on multiple platforms.
As discussed before, there are two main ways to go: 1) hand code new platform code for the Mac, or 2) use a cross-platform library. Both have advantages and disadvantages. Hand coding the new interface may (not sure) take less time but the effort only benefits the Mac platform. Using a cross-platform library will also allow us to improve our look on Linux as well as Mac. But using a cross-platform library puts us at the mercy of a third party. If we use QT, what happens if they go through another version change like they did from 3 to 4, where the whole API got overhauled? If we use QT, will we still be able to use our form editor and Slick-C API for interacting with the GUI?
As Tyrathect points out, being native is just one needed improvement. We are working to improve the Xcode support, but that is a challenge in its own right. And, yes, we need to do some work on the Objective-C support. This, too, is not simple. Objective-C is the oddball of the C family of languages and isn't broadly used on any other platform. Our language support lumps the c-like languages together, and we have to be careful that enhancements for Objective-C don't mess up our C/C++ support, which is our bread and butter (maybe we should be saying "cheeseburger and fries" by now
. We have similar challenges with C#.
And I will ask the revenue question: if we make all those changes, can we sell enough copies at $300 to pay for the work? When all that work is finished, we're still competing with Xcode, which is free, and some other editors that cost considerably less than $300. Lowering the price just increases the number of licenses we need to sell to reach break-even, which is a concern in a niche market.
If there was an obvious solution to all of these issues, we would already have released a native Mac version. Instead, these are hard choices that come with major costs and risks. So, we're still looking into the best course of action. I'm sorry that it has taken this long, particularly since some of our customers, like Tyrathect, have switched to other editors.
I don't know if this kind of explanation is the TLC you were looking for, Tyrathect, but it's all I've got right now. I gave you a hero point for the most concise list of functional issues in the Mac version.