macOS Alternative to Objective-C and AppleScript ?

[/dev/toaster]

I am a developer who normally works in PHP, and I have recently found a few simple apps I wanted to write. However, I want them to be actual applications instead of a webpage.

Here is the problem I am facing ... I tried to read up on objective-C and found it to be very ugly. I have done some basic development in C and C++ in the past, and I am fine with those.

Applescript also seems ugly to me, and not really what I am looking for.

Basically, is there a way to use C++ (C# would be even better) with Xcode ? Is there another IDE out there that will help me with UI design, compiling the app on OSX and with a widget set that will make it look native ?

As always any help is appreciated

 

[kpua]

I hope you don't write off Objective-C just because you think it is "ugly". In doing so, you're missing out on a great programming environment.

I'll admit it, Objective-C isn't the most modern language in the world, but it holds its own, and ObjC-2.0 is going to make it even nicer to use. The real win with using Objective-C however is Cocoa. I don't know of a better desktop application programming environment out there. With its philosophy of making "simple things simple and complex things possible", there's almost nothing you can't do without it--and you can get it done in the fraction of the time you would spend in another environment. So please, reconsider Objective-C and try to get past it's somewhat foreign exterior. It'll grow and you. I promise.

If you absolutely detest ObjC but still want to use Cocoa, you have the option of using Objective-C++ which allows you to mix ObjC and C++. That means you can write almost everything in C++ and use Objective-C just to call into Cocoa. There are also ruby and python bindings out there if you prefer scripting.

And then there's Carbon, which is another popular option. I can't say anythign up or down about it, since I've never used it, but a signifcant portion of it is legacy code.

If that's not good enough for you, then you can resort to using some other third-party framework, but frankly, it's not going to look or feel as good as a Cocoa app does on OSX.

Oh, and Applescript just isn't the way to go for desktop applications, IMHO. It has its uses, but they're fairly limited.

 

[Alloye]

I tried to read up on objective-C and found it to be very ugly.

I used to share this opinion. Now I code C#/.Net professionally and Objective-C/Cocoa for fun. I much prefer Objective-C/Cocoa.

But to answer your question, OS X does have a traditional C-based API called Carbon. It may be your best bet if you're married to C and/or C++. Just be prepared for a rather steep learning curve.

On the other hand, I really think you will do yourself a disservice by not giving Objective-C/Cocoa a serious look. I admit it doesn't make a lot of sense at first, but it really is a fantastic framework once you wrap your mind around it.

Finally, if Objective-C really isn't your thing, there are some Cocoa bridges out there that support other languages. RubyCocoa and PyObjC come to mind, both of which will be included as part of Leopard.

 

[Eraserhead]

Given that for better or for worse most carbon frameworks aren't going 64 bit I think Cocoa/Obj C is really the future of development on the Mac.

 

[Soulstorm]

It always was, it's just that only now this has become clear.

Actually, I recommend sticking with Cocoa and ObjC. It really is a great programming environment, and not difficult at all, once you learn the basics. If you know a little about OOP and C++, you can learn ObjC in a matter of days.

 

[brianus]

I am a developer who normally works in PHP, and I have recently found a few simple apps I wanted to write. However, I want them to be actual applications instead of a webpage.

Here is the problem I am facing ... I tried to read up on objective-C and found it to be very ugly. I have done some basic development in C and C++ in the past, and I am fine with those.

Applescript also seems ugly to me, and not really what I am looking for.

Basically, is there a way to use C++ (C# would be even better) with Xcode ? Is there another IDE out there that will help me with UI design, compiling the app on OSX and with a widget set that will make it look native ?

As always any help is appreciated

In addition to the Python and Ruby bindings there's also CamelBones, which allows you to write Cocoa apps in Perl. If you're coming from a C/PHP background, syntactically it should be pretty familiar to you; the downside (besides not being updated all that frequently) is you still have to be able to read and understand Cocoa documentation and the whole Obj-C system underlying it.

There are of course also 3rd party 'cross-platform' C++ UI kits that work on OS X like Qt (unfortunate name - no relation to QuickTime) and wxWidgets, but I think they use Carbon, and I don't know that there's any nice drag-and-drop UI designer for them like there is for Cocoa.

 

[bronxbomber92]

I'd also suggest Obj-C and Cocoa (or a bridge like RubyCocoa or PyObj). But, wxWidgets is a very capable cross-platform GUI toolkit.

 

[/dev/toaster]

Cross platform isn't much of an issue for me, I pretend that Windows doesn't exist.

Can you recommend any good books that are more entry level, but give good examples ? (Not those silly hello world, but more real world examples)

 

[davidlt]

I am in the same place as you. Objective-C (1.0 version or just the one we use now) isn't that nice to write program. JAVA isn't the way, it won't have new features from Leopard, Apple is cutting it from new features in the future.

Ruby and Python, I had the same idea, but they would be completely open source. I had never seen compiled versions of those two, but as I remember you can compile Python to exe in Windows. That's too open for programs I would like to write.

Right now I am still playing with C#/.NET. Yes it's possible to write programs using C#/.NET, XCode and Cocoa. You need Mono + Cocoa# and one more package (XCode plugin). It works as it should be (almost), easy and nice, but I can't understand some other things, how to work with Cocoa. It's not well documented thing, that's the problem with it.

I would suggest you to wait for Leopard, which will bring Objective-C 2.0 which will look at lot better, it will remind C++ to you. And that's the only way if you want to write really Mac OS X programs.

 

[Eraserhead]

I am in the same place as you. Objective-C (1.0 version or just the one we use now) isn't that nice to write program.

Hmm I really like it, it makes thinks really easy, especially when you combine it with the nice Cocoa features like bindings, (I believe) delegates and CoreData.

 

[Krevnik]

Hmm I really like it, it makes thinks really easy, especially when you combine it with the nice Cocoa features like bindings, (I believe) delegates and CoreData.

Oh god, Bindings + CoreData = Rapid Prototype of a UI in an afternoon. It is practically god-like how rapidly you get a full code stack from object model to UI, and how easy it is to start ripping out the default bindings and controllers with custom code to get more advanced behavior.

There are a couple huge hurdles though, the first one is that in Apple's framework, you connect components (custom or pre-built) together to get your UI+Controller behavior. This is a completely foreign concept compared to .NET and others. The fact that your little object that provides drag behavior for a specific table is just a lego block of sorts that you connect up, instead of programmatically doing everything tends to make people spend more time than they need to.

The second big hurdle is CoreData. The documentation could be better, and XCode lacks some nice things that make building shell classes for a managed object easier... but that will change.

 

[/dev/toaster]

I am in the same place as you. Objective-C (1.0 version or just the one we use now) isn't that nice to write program. JAVA isn't the way, it won't have new features from Leopard, Apple is cutting it from new features in the future.

Ruby and Python, I had the same idea, but they would be completely open source. I had never seen compiled versions of those two, but as I remember you can compile Python to exe in Windows. That's too open for programs I would like to write.

Right now I am still playing with C#/.NET. Yes it's possible to write programs using C#/.NET, XCode and Cocoa. You need Mono + Cocoa# and one more package (XCode plugin). It works as it should be (almost), easy and nice, but I can't understand some other things, how to work with Cocoa. It's not well documented thing, that's the problem with it.

I would suggest you to wait for Leopard, which will bring Objective-C 2.0 which will look at lot better, it will remind C++ to you. And that's the only way if you want to write really Mac OS X programs.

I avoid Java like the plague ... far too slow for me. I tried Java 2 years ago, and swore I would never try it again

Doesn't seem like C# + Cocoa isn't ready for development. Kind of sad, because C# is actually a really nice language.

Are there any books on Objective-C 2.0 ? We have a few machines in the office with Leopard (Actually using it right now). I could play around with it during off hours until its released.

Oh god, Bindings + CoreData = Rapid Prototype of a UI in an afternoon. It is practically god-like how rapidly you get a full code stack from object model to UI, and how easy it is to start ripping out the default bindings and controllers with custom code to get more advanced behavior.

There are a couple huge hurdles though, the first one is that in Apple's framework, you connect components (custom or pre-built) together to get your UI+Controller behavior. This is a completely foreign concept compared to .NET and others. The fact that your little object that provides drag behavior for a specific table is just a lego block of sorts that you connect up, instead of programmatically doing everything tends to make people spend more time than they need to.

The second big hurdle is CoreData. The documentation could be better, and XCode lacks some nice things that make building shell classes for a managed object easier... but that will change.

The last development I did besides PHP was with Kylix. Borland has (imo) the best IDE out there. Put a button on a form, double click and it creates all the code for the event. I love that idea and its strange more IDEs don't do it. Kylix would have been really really sweet on a Mac

Not a fan of .NET, like I said before I avoid MS these days.

 

[Krevnik]

Are there any books on Objective-C 2.0 ? We have a few machines in the office with Leopard (Actually using it right now). I could play around with it during off hours until its released.

Leopard is still under NDA, so no, there aren't. Apple does have guides on what is new in Objective-C 2.0 and how to use it with their Leopard docs for those with seed access. It mostly boils down to garbage collection and properties though as talked about at WWDC's keynote.

The last development I did besides PHP was with Kylix. Borland has (imo) the best IDE out there. Put a button on a form, double click and it creates all the code for the event. I love that idea and its strange more IDEs don't do it. Kylix would have been really really sweet on a Mac

Not a fan of .NET, like I said before I avoid MS these days.

Interface Builder and Cocoa go a bit beyond this. Forms/Windows are pure data. Controllers that you setup for windows/components are loaded from the file (you don't create the instance programmatically, but you do still need to write the behavior obviously). In Interface builder, you put the button on the form, and you can link its action to any controller object in IB, and any method designated as an IBAction on that object (which you can autogenerate the stub for an IBAction from Interface Builder). So when you make your document window, you just wire up all the controllers it needs in the IB file, and it will handle all the loading, setting variables to link objects together (if they reference each other), and will call the right methods without any autogenerated or shim code needed.

Because of this, you can do some more advanced things, like using Apple-provided controller objects to pull from a CoreData context. Let's say I was using CoreData for a cookbook, and I wanted to display all the recipies in a table view. I can use Apple's array controller in IB, tell it to pull all 'Recipie' objects from the CoreData context, and bam, that controller will have an auto-updating array of all the Recipies in my CoreData DB. I then create the table view with a single column, telling it to bind to the array controller, getting the string value from the array of objects' "recipieName" field. Now, not only do I now have a table view with all my Recipie names listed, but I can directly edit the names using the table view for free, and it will update my CoreData DB with the new values as they are edited.

No code written, yet I have a full code stack from my data file to my UI. No autogenerated code, either. IMO, having to autogenerate code is the one thing that drives me nuts about .NET's WYSIWIG form designers. You can get the code into bad states that the form designers will choke on.

 

[bronxbomber92]

Python + Cocoa can be put into an .app. Using py2app.

 

[davidlt]

Python + Cocoa can be put into an .app. Using py2app.

Thanks for this information, anything about Ruby2app? I am starting to move to RoR now, so what would be a bit better choice.

There is some information about Objectve-C 2.0:
http://en.wikipedia.org/wiki/Objective-C

For Ruby:
RubyScript2Exe (Link: http://www.erikveen.dds.nl/rubyscript2exe/index.html#1.0.0)
Works the for Windows/Linux and Mac. In app it also includes stripped Ruby version, that allows to run your programs on every machine, including those who don't have pre-installed Ruby. (Great!)

Right now Python and Ruby looks for me the best choice then. I still would be waiting for Objective-C 2.0, but Ruby and Python is really easy language or at least it should be.

 

[HiRez]

Oh god, Bindings + CoreData = Rapid Prototype of a UI in an afternoon. It is practically god-like how rapidly you get a full code stack from object model to UI, and how easy it is to start ripping out the default bindings and controllers with custom code to get more advanced behavior.

There are a couple huge hurdles though, the first one is that in Apple's framework, you connect components (custom or pre-built) together to get your UI+Controller behavior. This is a completely foreign concept compared to .NET and others. The fact that your little object that provides drag behavior for a specific table is just a lego block of sorts that you connect up, instead of programmatically doing everything tends to make people spend more time than they need to.

The second big hurdle is CoreData. The documentation could be better, and XCode lacks some nice things that make building shell classes for a managed object easier... but that will change.

The third big hurdle is when you want to do anything that isn't "Cocoaized" yet...like most of QuickTime, CoreAudio, port access, etc. When you have to start dipping into Carbon and dealing with cruft like Pascal strings, things can get ugly. But overall, Cocoa is awesome (and Objective-C is too, while having its quirks). I wouldn't do Mac development any other way, at least not right now.

 

[whooleytoo]

I do think Xcode and Interface Builder could be far more integrated. They work well together when you can put your interface together then let IB generate the source files for you with outlets and actions in place.

It's when you need to go back and make changes or additions it starts getting messy, as you either need to manually drag the header file into IB for the changes in code to be noticed by IB, or you need to do a code merge for your changes in IB to be noticed in Xcode, which isn't easy.

 

[Eraserhead]

Personally I do the changes in XCode and use "Read AppController.h" in IB, which works fine.

 

[whooleytoo]

Personally I do the changes in XCode and use "Read AppController.h" in IB, which works fine.

Which is fair enough, and works fine.

It just means you don't get the benefit of Xcode/IB creating the code for you, which it can; and it's a manual step which wouldn't be at all necessary in a more integrated tool.