Alternatives to Artistic Style for Mac, Linux, Windows, Web, Self-Hosted and more. Filter by license to discover only free or Open Source alternatives. This list contains a total of 4 apps similar to Artistic Style. The direct replacement for Visual Studio on the Mac is Xcode but that is for proper programming languages such as C, C++, Objective-C, Python and Ruby. If you are looking for a decent website editor then Smultron gets my vote.
I find it surprising that there are so many people bashing Objective-C here in the comments. I have been programming in Objective-C for living since the iPhone SDK came public and I came to love both the language and the libraries. I think that many people who despise Objective-C syntax are simply not programming long enough in the language to overcome the initial knee-jerk reaction. Mostly the issue seems to be the message passing syntax, which I find very readable and self-documenting. What else should matter if not this? Then there’s comments about speed. I have written two action games for the first-generation iPhones and I have never encountered a performance problem caused by the runtime.
Over 99% of the time I could stick to high-level code without resorting to C to gain speed. That says a lot about performance for regular applications. Block syntax could be better, I can’t use closures with such ease as in Perl (for example). But this is one of the things that have to do with Objective-C being a relatively thin layer atop of C. And that I see as a huge win, because you can very easily and naturally mix higher-level Objective-C code with plain C APIs that are very common on most systems. And if you want some lower-level bit-twiddling trickery for performance reasons, you are free to go. For me, C is a very elegant language and Objective-C takes out most of its rough corners.
Saying that Objective-C could be replaced by something “smarter” like Lisp or Haskell is simply ignoring the reality. Objective-C has very low language complexity, both the building blocks and their interactions are simple and there are few surprises. This is a huge advantage both for the newcomers and for programmers that deal with the stack most of their working hours. The manual memory management first seemed like a chore to me after coming to Objective-C from Java, but the rules are dead simple and after a few weeks you don’t think about the memory management any more. Yes, Objective-C is not hip. It’s a pragmatic and reasonably expressive language that gets the job done.
I don’t think that replacing it would serve any real purpose – and that’s a very good reason to survive. Most of the silliness about Objective is (I think) based on an unwillingness to admit that GUI's written in one's favorite scripting language or Java are still too slow. I think Obj C add just the right amount of sugar to plain C for GUI and OOP, while its cousin C has WAY too much sugar (insulin shock!); both of these are screamingly fast after compilation.
So saying 'I would rather write it in Ruby/Python/Perl/Lua/Java/blah/blah/blah' is just ridiculous, at least with today's tech. Sure - I would rather write an SS7 switch in Bash, but that just doesn't matter. Oh - and the fact that small minded programmers freak out when something is different (brackets, as an OP says, or 0 versus 1 indexing, etc) (Note - if you want to max programmer speed (in Lines of Code) for GUI's, you want to use a language even uncooler than Obj C: Tcl/Tk.). Obj-C survives b/c it is the only real way to write iPhone and iPad apps, plain and simple (ignoring Appcelerator and PhoneGap for the moment). If people had options, it is likely they would use the alternatives. Look at Linux.
The 'official' language will always be C, but there are toolkits for building GTK apps in Python, Vala, Mono and other even more obscure languages. Some pretty big apps have been written in each and people will continue to use those as long as they are viable options. If, however, someone big enough and with enough clout basically said 'only native C/GTK apps will be accepted on our platform', you would see people migrate to that toolchain. It is simple economics.
Apple has the clout (imo, unfortunately) to do that and have done it with Obj-C. They basically killed Java, which was an option up until I think 2 years ago. I can see Apple's perspective, supporting two toolkits is expensive and takes time, resource, energy and focus. In their mind, what benefit to they gain from supporting multiple toolkits?
They know they are popular enough that the developers will take up Obj-C when Java was dropped. Sure there will be grumbling and moaning, but Apple DOESN'T CARE ABOUT DEVELOPERS except that they make apps to attract the users.
I'm not saying what Apple did is right or wrong, but it does make sense from a strategic point of view. However, there is practically no merit to Obj-c on it's own. There are more compelling alternatives at nearly every turn, but NOT if you want to play in the iphone and ipad ecosystem. Are you seriously suggesting it would be better for everyone if developers wrote desktop apps for OSX in Java?! Apple didn't kill Java, Sun did. It was Sun who decided Java apps had to look different (in that special, ugly java kind of way), that they required 5+ seconds to start etc. Java could have been good for desktop apps if done right, but it wasn't and as a result there's very few desktop Java applications (and even fewer good ones).
Java was also an awkward fit for Cocoa, lacking the dynamic ability required. Java has it's place, and being a language for desktop apps is not it.
Objective-C's niche: it's the core of two popular operating systems. A lot of strange programming languages survive because of inertia. Emacs Lisp exists because Emacs was written by Lisp hackers. It survives because Emacs ships with a few million lines of Lisp. Replacing it would take hundreds of man-years.
Objective-C survives for the same reason; Cocoa was expensive to write and rewriting it would serve no purpose. So it remains. Is anyone using Objective-C for some reason other than writing OS X or iOS apps? No, but I'd love to hear about it. I see a lot of c devs complaining about how after 20 years they still haven't found a common ground on how to properly use c 1, its complicated memory management or its poor support for strings 2, things that are taken for granted with objc and Core Foundation. On one side I see an incredible amount of developers dealing with high amounts of complexity with C, and on the other hand this low-level dynamic language with a powerful 3 open-source standard library 4 that is sadly only commonly used to build Cocoa apps.
I'd love to hear about objc+CF for things like game development on other platforms than iOS or OSX, or an explanation to why it's not happening. I really really don't mean to instigate a flame war here - I'd just love to hear more about this topic. 1 2 3 4.
Your references don't support the points that you are trying to make. 1 is just a link to Google's C style guide, a specific guide that makes sense for the very large C projects inside Google.
Projects should create their own guides based on their requirements. The common ground is already there, you can read about it in C Coding Standards by Sutter and Alexandrescu. 2 is someone wondering whether they should replace C with a mostly-C-compatible language for Firefox. First of all, they are complaining about memory safety, not management which plagues Obj-C just as much or even more, given the fact that it doesn't improve over C's safety like C does.
Second of all, there are several libraries that can talk to the STL and effectively solve the UTF8 problem. 3 This can easily be done by the STL, which besides having an open source implementations is also an ISO standard.
I can't tell if you're saying that examples are not enough to back my points or if those examples just don't back my points at all. If it's the latter: 1 is an example that illustrates the complexity of C. Show me a style guide or debates about how to use the core of the language in objc.
2 is an example of someone unsatisfied with memory management and string support in c. There are tons of those out there.
Show me one for objc. Admittedly memory management is a matter of taste, but I retain/release/autorelease quite simple to use and I haven't found anything quite on a par with that mechanism in c. 3 what do you mean 'it can easily be done'? There's nothing being done there, the author is just observing how the implementation of arrays changes based on the size of the dataset; it's an example of the details behind CF. Are you saying STL automatically optimizes as well?.
Syntax sucks: I think Objective-C is actually pretty beautiful. Maybe I'm crazy. NSInvocation should serve the same purpose in most cases. I find the block syntax atrocious if compared to Lisp lambdas. It's not that bad.
What Are Alternatives To Objective-c For Mac
Blocks are objects, so you're creating an object, with all the same predictable retain/release semantics. Maybe a few gotchas if you're not reading the documentation and realize you should avoid retain loops. Hardly different from Java, only it's easier to miss it in Java, because you never release, anywhere. The lack of namespaces seems silly to me: NSThis, NSThat. It isn't that Obj. C is a bad language, it's just it doesn't feel like a more modern language, and yet it gets used because of the possibility of $$$.
I do understand that you can come to love a language after a period of using (and understanding) it. And I do think a systems-level language should be used for apps on mobile devices, but we don't have to continue to be mired in implementation details that were an artifact of a language from the seventies. I need to play with it more to get a better feel for it. Based on the comments, seems like most people's objections of Objective-C are really objections about C: header files, manual memory management, function pointers, strong type system, too low level, no native string object, etc. I grew up with C, so learning Objective-C took maybe 10 minutes because it's basically C with some extra syntax for OOP.
In general, one only encounters the 'strange' syntax when dealing with methods. I personally love the method syntax because it's basically self documenting. Which leads me to wonder, how many programmers both on HN and in general know C? I'm too young to already be a dinosaur in this industry.
Where did all the C programmers go? Seems like programmers nowadays started learning how to code with Java or Ruby/Python and expect all other languages to be just as high level. Objective-C is low level, which makes it harder, but doesn't make it suck.
As a language, I think Objective-C is a fine one, but I must admit that it is a 'dinosaur'. The real problem is OOP paradigm. Remember, back in the late 70s and early 80s, OOP was new and exciting and C was the dominant language. People were trying to figure out what OOP should look like and how to make C more OO. NextStep (Apple) just happened to bet on the wrong horse. Obj-C went with Smalltalk syntax, while the rest of the world went with C syntax and ultimately the Java style syntax we know and love today. Seems like some developers can't wrap their heads around a non-Java syntax for OOP.
All that said, Objective-C survives only because Apple hasn't chosen another language to replace it for Mac and iOS programming. Obj-C went with Smalltalk syntax, while the rest of the world went with C syntax and ultimately the Java style syntax we know and love today. It's more than just a syntactic difference.
Objective-C implements true message passing which is not the same as 'method calling'. You can send messages to a nil object, or have an object dynamically respond at runtime to a message it didn't declare at compile time etc. Some seem to think the brackets are just some kind of whimsy, but it's important that sending a message is not to be confused with calling a function.
Why it survives in a world of alternatives? There are no alternatives if you want to distribute on the most popular mobile platform.
Personally, I really dislike Obj-C, but since I want to create apps on the iPhone I have no choice. Unfortunately, making a good business decision sometimes means going against your personal feelings. I think that's how a lot of other people approached it too. If the iOS platform changed overnight to Lisp, we would see articles titled 'Why Lisp survives in a world of alternatives'. I've been using objective-c since 2001, when I made the switch from BeOS to Mac OS X.
It's not horrible. I don't have any real problems with it. But I think its replacement is long overdue. Given that Apple has a long history of ditching huge swaths of its technology in favor of more modern alternatives, no matter if their userbase screams bloody murder or not, I'm surprised it hasn't happened already. This would be a good project for those billions they've got sitting in the bank.
I think it would be great if they would anoint some successor as their new systems language, then port Cocoa to it. Programmers could use either objective-c or the new systems language for a few years, just as we used to decide between Cocoa and Carbon.
Then objective-c could gradually fade into the past. John Siracusa wrote about this very aptly 5 years ago: Avoiding Copland 2010 Then he revisited it 10 months in 2010: And then he talked about it 2 weeks ago in the Hypercritical Podcast: Abstract: new language and new API go hand in hand. A memory managed combo trades execution speed for faster program creation.
Was already needed 5 years ago. The recent garbage collection additions don't cut it. Microsoft started working on their successor (.net) 10 years ago and now it's starting to look good.
Apple gained some leeway when the iPhone happened. With ever improving CPUs on mobile devices, Apple still risks losing ground down the line. Great podcast episode, I highly recommend it. You could also argue that, given the current success of iOS and Mac, Cocoa isn't a significant hinderance to Apple's platform's success. (Not to say I wouldn't mind some significant advancements in Apple's preferred runtime, but there's strong evidence that the current runtime is actually quite suitable. If, as you say,.NET is only now starting to look good after a decade's worth of work, perhaps that wasn't the wisest investment on MS's part. Siracusa's been beating this drum for years and, like many of his crusades, I struggle to see how Apple suffers from not following his advice.).
It's fine to push for a better language, but so far you seem to be saying we should do it just because the current language is too old. What are specific things that are wrong with the language Objective-C 2.0 (and not just Cocoa, which is an API; and not just Mac OS X or iOS, which are platforms)? Why should Objective-C not just evolve into something a bit more interesting?
And when considering any alternative, what are the most costly considerations for any developer, including Apple? The size of a code base is a significant factor. The fact that established code already works (new code may add bugs) is a significant factor. The wealth of knowledge already accumulated by programmers is a significant factor. A new language is very unlikely to win a war in those areas, so it would almost have to solve some other problem that is still costing developers a lot because they're using today's languages. Good question! I can think of a lot of reasons why Apple should switch to a more modern systems programming language.
We have all read pg's essays where he extols the virtues of Lisp, compared to other languages. His primary argument, as best as I can tell, is you can write programs with far less code than in other languages. Such an advantage would be a big win for the platform, and we may come to a time when Apple is forced to do it, because everybody else has, and they risk being left behind. Objective-C is becoming a weird frankenlanguage.
It already was, arguably: a thin layer of smalltalk-like OO sitting on top of C. Just recently, Apple added blocks, which are like continuations in other languages. Maybe that's a good thing, but I think it would be a better thing if we went with a language that had those types of concepts from the beginning. It has been mentioned elsewhere in this thread that Microsoft has already had their platform-two-dot-oh epiphany, which was.Net: managed languages with automatic garbage collection, and so on. If this evolves into a big win for programmers, Apple will be forced to follow suit. The biggest argument I can think of for Apple not to try a new systems language is that their cash cow right now is the iOS platform.
Doing this now would no doubt cause serious memory and CPU pressure on small devices which can't afford it. So knowing Apple, their likely answer to that would be to come out with a new generation of devices that are no longer compatible with objc, which you have to rewrite everything for. I agree with the potential in those 3 things, but consider. Saving even an hour writing something as a few terse lines means nothing if in 6 months you need days to decipher and debug it. The code has to remain clear somehow.
About the only acceptable use of a clever one-liner is when it provably reduces the runtime of the generated machine code by a significant amount.and even then, the hour you saved not writing code had better be spent writing a block of comments to explain your one-liner. Yes, Objective-C is weird. But put yourself in the seat of a language parser; it's already a very difficult problem to ensure that some languages parse correctly and unambiguously.
If you introduce new syntax that is 'weird', it's actually safer than doing something that may cause subtle incompatibilities with all the code that's been compiled a certain way for decades. And that code has proven the 'weird' language is practical, whereas a brand new language (no matter how perfectly designed it seems to be) may actually have parser corner cases that have not been ironed out yet.
Garbage collection is a benefit in many situations, but Apple has managed to create a very responsive phone where mere milliseconds are just perceptible enough to make a user think 'my iPhone feels fast, and this other phone feels slow'. Right now, performance matters most, and manual memory management is an edge for Apple. It's important to make programmers happy, but not as important as it is to sell things to users. It has been mentioned elsewhere in this thread that Microsoft has already had their platform-two-dot-oh epiphany, which was.Net: managed languages with automatic garbage collection, and so on. If this evolves into a big win for programmers, Apple will be forced to follow suit. Timing is everything.
That epiphany has not yet lead to what it promised originally: a consumer OS in managed code, with major applications in C#. I do not think that will happen soon, either.
= Apple will probably be fine with a OS written in C with some added functionality, especially if they manage to build one or more managed environments on top of it. That way, companies can build their in-house stuff in managed languages, while the core stuff remains finely tuned C. I do not think that is the most beautiful solution, but it may well be the pragmatic approach that wins the race. They didn't actually try to 'replace' objective-c with java, though. It was just an alternative. In the early days of Mac OS X, many programmers were seduced by it, but they complained loud and long about having to learn this weird new language that had practically no adoption outside Apple.
My guess is that Apple decided to give them java to quell the complaining. It wasn't adopted widely, so that was that. What they should be replacing objective-c with is something that looks more like, say, Python. The big push for Java was with WebObjects and Apple's half-hearted push into enterprise systems. Initially Apple's version of Java (they wanted tight integration with Cocoa) was always a couple of revisions behind Sun's so that was always a source of frsutration with developers. With the new focus on consumer devices the enterprise space was left to wither and Java with it. Anything that is going to replace Objective-C must be at least as fast - Apples really cares about the customer experience not the developer experience.
I am very far from an expert at Mac OS X system internals, but I don't think objective-c is all that ingrained in the kernel. You write device drivers in a restricted subset of C, as one example. Userspace Mac and iOS programs have to link to an obj-c runtime library, but it's not much more onerous than linking to, say, libc or libc. The big hit would be that, yes, there are gigabytes of objective-c frameworks installed, which would presumably have to be replicated in the new language.
But I could see Apple finding a way to sidestep that issue. Maybe the new systems language and objc could both compile down to similar binaries. Painful or not, it's going to have to happen sooner or later.
Objective-c is, in my opinion, the most outdated thing in Apple's technology stack. There will come a time when it is as big an albatross around their neck as Mac OS 9 was, which they waited far too long to replace. Obj-C, at least in the last few generations of mobile hardware, is a competitive advantage for Apple. It makes it easy to write fast, low-level code in C, and then to move transparently up to a much higher level of abstraction for non-critical code.
With the relatively underpowered processors of today's mobile devices, this kind of control is important. However, Obj-C completely falls on its face for anything of real algorithmic complexity.
Working with complex, nested data structures and more sophisticated algorithms is very awkward, and manual memory management only clouds things further. In the longer run this may become a liability for Apple. The kinds of algorithms you can express very cleanly in a functional language, like Haskell, for example, are a lot more awkward when you have to worry about managing memory at each intermediate step. Look at all the monkeying around you have to do with block declarations etc. For typical Obj-C code, where you're just gluing together bits of the Cocoa API, I agree that Obj-C's memory management isn't too bad. When you're trying to work at a higher level of abstraction, it's a distraction.
Writing complex algorithms in Obj-C is a pain because of it's incredibly clumsy syntax for collections and the manual coercion of elemental types back and forth to objects. Look at an implementation of a neural net or something as simple as k-means clustering in Obj-C, then C, then Scala or Haskell to see how poor Obj-C is for this kind of thing. For example, imagine how much worse this would be in Obj-C: Admittedly, Scala is particularly nice for this kind of thing, and Java is no better than Obj-C, but even C gives you much better tools for abstracting this kind of code. Thank you, that’s helpful.
The algorithm is a bit above my head to rewrite in Objective-C on Sunday, but from my superficial understanding of it the Objective-C version wouldn’t be really ugly. Yes, it would be wordier and clumsier, but tolerably so (for me). After all, it’s precisely these things where functional languages shine.
I seldom find I have to monkey around with block. Manual boxing/unboxing sucks, yes. It can be alleviated by a simple macro where this really matters, but I can see such and argument is like pouring petrol into the fire when compared to functional languages:) Now I understand what was meant by “sophisticated algorithms”. Yes, Objective-C is not perfect for those – first class collections are a great convenience here.
But I certainly do not see that as a future “liability for Apple” or a huge drawback for the language ecosystem. It’s a niche. I have never understood what is so difficult about Cocoa/ObjC's memory management.
In very very complex projects, it can be like counting blackjack cards, but I've honestly never remembered my retain count for any object hitting over 5, and if it has, I've probably been doing something wrong. Most of the time it will never go above 2. All you do is add or subtract one from a number making sure you're never in the negative.
At least we don't have to declare how much memory to alloc and dealloc manually. I'm not even getting that from the link. To me, the link only shows that I can download The Haskell Platform for my Mac.
The only thing there related to XCode is that one needs to have it installed as a prerequisite for running the haskell platform's installer. This is no surprise because the installer wants to have the 'unix development support' package available (it contains gcc, header files, misc command line tools in locations where run-of-the-mill Makefiles can find them.) and it's just incidental that one needs to run the XCode installer in order to get these basic unix amenities on the system. This makes the following situations possible: 1) You want to add a convenience method to someone else's object (a quick search of my own posts reveals that about a dozens of my own posts involve adding convenience methods to Cocoa classes, e.g. Safely fetching an NSManagedObject by URI). 2) You want to change the behavior of a class you didn't (and can't) allocate because it is created by someone else (this is how Key-Value Observing is implemented in Cocoa).
3) You want to treat objects generically and handle potential differences with runtime introspection. 4) You want to substitute an object of a completely different class to the expected class (this is used in Cocoa by NSProxy to turn a regular object into a distributed object). One can do all of the above with the Go language. In addition, one could also write a reasonably performant compiler in it.
(Also JIT dynamic language VMs are good enough now, that I've seen dynamic language parser/compiler implementations perform as well as a naively written Lex/YACC C implementation. And yes, companies paid money for the latter!). Ok, that's simply not true. On Mac OS X, you're welcome to use any language and runtime you wish for your application.
Hell, if you want to use a non-Objective-C language and still present a native experience, use PyObjC, RubyCocoa, MacRuby, or any other language that shims into the Objective-C runtime and get access to all of Apple's Cocoa frameworks in the language of your choice. The same is possible on iOS as well, with the (significant) condition that Apple must first explicitly approve your use of a non-Objective-C runtime before your app can be posted to the App Store. But in direct response to your post, Obj-C has a rather level playing field on OS X and still survives vs. The alternatives.
it's not officially supported by Apple MacRuby is an Apple project. PyObjC isn't, but ships in Mac OS X.
That's rather officially supported. it binds to Cocoa (and if you're lucky it's even up to date and doesn't have that many bugs) Not true. MacRuby is a prime example of a language that taps directly into the Objective-C runtime, eliminating the need for a bridge. And PyObjC is a great example of a mature bridge – it's been around and robust since the NeXT era.
you can't use it on iOS. you can't get a job doing X instead of Obj-C because almost everyone just uses Obj-C, the Apple supported language You can't get jobs programming Ruby, Python, C#, Lua or any other language? Those projects, even macruby are not officially supported - there is not even documentation on apple.com. Who would use it as their main dev platform, knowing that apple has the tendency to ban 3rd party platforms.
Obj-c is practically not used outside OSX - there is just no evidence that, when given the choice, developers would prefer objC. Open source developers seem to root for python, ruby etc, but certainly not for objc, unless they have to deal with OSX. GNUStep is not an active project, with practically zero applications, while there are lots of quality apps in c frameworks, python, ruby etc.
I dont believe OSX developers are just different people who happen to love objc over everything else. Ignoring the disputable claims that it's unpopular or has a slow learning curve (you can describe Objective-C's additions to C in a single page), there's no evidence to claim that Objective-C is about customer lock-in, especially when you can use so many alternatives including the Apple-funded MacRuby.
Apple uses Objective-C because they have a lot of code written in it, and it has served them very well. IOS is the most popular mobile platform for third-party development. The dynamic nature of the language has enabled the implementation of some useful features like key-value-observing, while the ability to drop to C retains the flexibility of system-level programming. Even the memory management criticism is overblown.
You merely have to follow an easy list of four ownership rules. That's if you're not using the garbage collector that came out four years ago with Leopard. If you follow those 'easy rules,' how do you handle race conditions between weak references held to avoid retain cycles and the execution of those weak reference's -dealloc methods? There's nothing to stop the weak reference's -dealloc from racing with messages to that weak reference. Or, how do you handle the fact that -dealloc can be called on whatever thread calls the last -release, even if you make an effort to only send messages to an object on the main thread (Which will trigger implicit retain/release unless you're incredibly careful).
Almost all of the GCD examples out there are subtly broken because of this. As for GC, I look forward to actually being able to use it on iOS. This is a hack, not a general purpose solution, as it requires modifying the class, and and still must be done carefully to avoid accidental retain/release.
Calling retain/release from a background thread will happen simply by using blocks, gcd, or performSelector: APIs, as designed, to attempt to schedule execution on the main thread. Avoiding the issue requires exquisite care, unless you actually want to modify every single class that you may access an instance of from a background thread (such as GCD). As to the first point, it applies in a NON-GC environment, where you hold weak references to delegates a(nd deregister them in dealloc.).
A long time after this question, ' playing' with vim, I wanted ObjC support, especially with taglist plugin. I found that question, then digged a bit, and here is a not so dirty solution:. An ObjectiveC parser, it is not released (yet?). You can easily install it on OSX via homebrew: $ brew install ctags -HEAD. Note that when using ctags,.m is treated as Matlab and.h is treated as C. To override, use: $ ctags -langmap=ObjectiveC.m.h.
Then I added something like this to my.vimrc for taglist support: let tlistobjcsettings = 'ObjectiveC;P:protocols;i:interfaces;types(.)' add any type interests you from that list: ctags -list-kinds=all ObjectiveC i class interface I class implementation p Protocol m Object's method c Class' method v Global variable F Object field f A function p A property t A type alias s A type structure e An enumeration M A preprocessor macro I hope that will help someone! There is an option to use ctags for objective-c. You can use etags in ctags mode. Etags derived from ctags some time ago, and in its source code ctags compatible tags will be generated by defining a certain macro switch. In fact the man page in Mac Os already documents etags and ctags in the same page.
It states that objective-c is supported in ctags. You should be able to generate a tag file using the following command: ctags -l objc.mh Unfortunately the ctags program in Mac OS behaves not as documented since Apple messed it up. I however managed to install this kind of ctags using Ubuntu Linux and it works great!!! There you have to install the emacs22-bin-common package. So under Mac OS all you have to do is to compile this package for yourself.
Download the corresponding source package e.g. From the Debian server. exctract it and change to the source directory. run./configure.
configure returns with an error because it cannot find lispref. I deleted all targets in varible configfiles in the created file config.status despite the ones with lib-src. run./config.status. cd lib-src. make.
Copy ctags e.g. To /usr/local/bin and change permissions. sudo cp ctags /usr/local/bin. chmod a+rx /usr/local/bin/ctags You are done. Happy tagging!!! If I am not wrong: Latest ctags by now parsing the @property keyword incorrectly, which could cause that all the words after @property in the source code are parsed to be properties, leading to a mess in file tags. I have to recompile ctags by commenting all of the property keyword processing in ObjC.c as a workaround.
Even though, it only helps to get a little better for reading source code in the Taglist. It still can't jump (e.g. To the implementation methods with parameters) correctly. I also tried this, but unfortunately this can't jump at all.
Summary: there seems no ctags for ObjC as workable as for C/C.