• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Mac Development Tools Recommendations

Air is a dumb suggestion for someone that seem to want to target some niche on a specific platform. How is it going to interact with any native APIs? Through some proxy written in a lower-level language? What's the point? Might as well write a normal program and just use whatever GUI editor is available (Interface Builder or whatever it's called in Xcode.)

You want the user to have the best possible experience, so you use whatever native tools are available. That pretty much means Obj-C and C++, although I suppose the first step should be to find out which languages the APIs in question support.

As for Mono, I don't know. Not only would you have to redistribute it, but you might end up running into problems with incomplete classes (particularly .Windows and anything GUI-related, at least it's not very mature on Linux) and the lack of P/Invoke.
 
The opening post gave no description of what the application IS. I'm assuming generic business app that runs on 'any' Mac, and DOES NOT need extra-magic API hooks.

Most people aren't PAYING to have gee-whiz alternate interfaces to disk utilities written. There are already mountains of MP3 players and things to talk to your 'iPod'.

What 'Native APIs' would you want hooks into for a 'normal' application that someone would normally pay to have developed?

The EXTRA MAGIC pop up a dialog and run a menu API?

The super-fantastic query a DB functions?

The awe-inspiring super-native connect-a-socket?

The ultra-top-secret printer?

The unbelievably amazing native play-an-MP3 function?

I mean, really. There isn't a special Macintosh-only coffee brewing attachment. Most of the commonest things an application needs are covered by the interpreted languages.

User runs app. App presents UI. User does stuff.

The end-user isn't all that impressed by whether it's 'native' or 'interpreted'. Just that it WORKS.

UI, a little graphics, printing, network, DB and file operations, any modern interpreted environment will handle it just fine, and work on ANY platform.

Video playback, animation, intermixed sound events done trivially, fonts embedded in the app, Flash/Flex/AIR does it better.

And you can embed the Flash player in a native app and talk to it via a loopback socket connection to deal with 'native' code all you like. Encapsulated and behind a socket-based interface that will be very portable, even if the back-end needs a rewrite if you're going to port it to another platform.
 
Of course it IS a helpful answer. It's an option.
We thank you for explaining the option, though I am afraid we are most likely going to reject it, for the time being.

All I'm saying is, jumping in and coding Native isn't the only answer. It may be the only thing your client WANTS, or is COMPATIBLE WITH, but that's a different story.
It is the best answer, for now. Perhaps this will be different for future applications, (which might be designed, from the ground, up, to be platform independent).

This is NOT a web app. This will be a desktop app.

Apple themselves recommend Eclipse. So does Adobe (Flex Builder).
http://developer.apple.com/tools/eclipse.html
Eclipse ain't bad. XCode seems too much of a mismatched jumble of tools, for some reason.

Mono is semi-viable if you want to use C# on Macs.
Tempting. But, we need confidence that we can support these things, to big clients and such. "semi-viable" is not going to cut it, right now.

Air is a dumb suggestion for someone that seem to want to target some niche on a specific platform. How is it going to interact with any native APIs? Through some proxy written in a lower-level language? What's the point? Might as well write a normal program and just use whatever GUI editor is available (Interface Builder or whatever it's called in Xcode.)
Well put.

The opening post gave no description of what the application IS. I'm assuming generic business app that runs on 'any' Mac, and DOES NOT need extra-magic API hooks.
I do not think the exact nature of this application is really relevant. I was merely asking which development environments are the closest to the Microsoft Visual Studio experience, for the Mac.

This would be a specialized application, for specific client needs, that connects our existing database system with specialized hardware, some of which might be video industry related, but not your typical consumer stuff.

And, I might not even have too many further details, myself, until next year, anyway.
 
Oh, then go for Eclipse. It's a 'mixed bag' no matter what you get besides something direct from Apple, and that'll probably be a bit pricey and idiosyncratic, and quite possibly built on Eclipse, anyway.

Not that Visual Studio isn't pricey and idiosyncratic. Just the idiosyncrasies you're used to. :)

I quit Visual Studio cold turkey when all of my licensed versions quit working with Vista. Then I quit Windows, too. OK, not quite cold turkey. I'd been doing console, embedded and server apps long enough over the years that the GNU tools were just as easy. So instead of running Linux in a virtual machine under Windows, I just occasionally run Windows apps in a virtual machine under Linux. At least those that don't have native Linux equivalents and don't run under WINE.

Vim, gcc, gdb, a makefile and the command line svn client work just fine for me.
 
Of course it IS a helpful answer. It's an option.
No it's not. If I ask for directions on the best way to get to Dublin, telling me I should really be going to Paris is not helpful.

As I said, you don't like AIR?
I haven't said that. All I have done is express scepticism that AIR is a good platform for developing Mac OS X applications.

Use Java. Unless you're going to jump into a big, immersive 3D environment or operate elaborate animation, Java will do the job OK.
Well it does a job. I've used some great Java applications on OS X But they tend to be just a little bit clunky in terms of the user interface. That doesn't bother me but I'm an atypical computer user.

All I'm saying is, jumping in and coding Native isn't the only answer. It may be the only thing your client WANTS, or is COMPATIBLE WITH, but that's a different story.
No, that's not all you're saying. You need to reread your posts because you've actually come out quite hostile against native development in at least one post. Granted, you have been sorely provoked by some ignorant remarks about Flash and Flex.

If you have F.U.D. about AIR, you should be pissing your pants if someone wants to use a cross-platform C/C++ library.
Objective-C can integrate quite happily with libraries written in C or C++ or libraries that respect the C ABI. The only part of a Mac (or Windows or Gnome or KDE) app that needs to be native is the UI.

If I were to *personally* target MAC right now, I'd just make a web app or use AIR. Yes, of course I'd TEST it on the Mac, but I wouldn't have to deliberately TARGET the Mac or (shudder) USE a Mac.
Using AIR or a web app is not targeting the Mac. Since you seem to have such an aversion to using the Mac, it's probably best that you stay away from it.

If you are already locked into some technology and don't have choices, then asking about 'development tools' is a silly question.
Of course it's not a silly question. If you are new to the platform and you don't know what the dev tool for that platform are, then you gain some value from having the question answered.

For an IDE, I like jEdit as an editor, and it will run on the Mac. So will Eclipse, which is a full-blown universal IDE with integrated debugging, a zillion plugins and enough bells and whistles to leave you permanently confused. I personally like command line tools, even gdb. Eclipse is maybe a little off the deep end with GUI features for my taste. Either one will host/build Java applications very nicely. Either one will host/build C/C++ applications or Python applications, or all manner of web scripting languages as well.
If you are going to develop Mac OS X apps you need something that will support Objective-C. You also need something that will help you build the NIB files (the NIB file is roughly equivalent to Win32 resource files but is far more sophisticated). I don't think Eclipse can support that. I think the best option for native Mac applications is Xcode.


Apple themselves recommend Eclipse. So does Adobe (Flex Builder).
http://developer.apple.com/tools/eclipse.html
For Java dev.

The days where it MATTERS what OS you are developing and running on are already behind us.
The OS maybe not, but the user interface, yes that does matter. People who use Macs all day expect their applications to look like Mac applications. People who use Windows all day expect their apps to look like Windows apps.

There is no difference whatsoever to a user with a decent network connection between a well-written 'rich' web application that loads from the company network or internet in an interpreted environment and a native one that you install on every machine that connects to a network/internet server.
There is a difference. It's the user interface.

Oh and as far as Flash on Linux and Flash on an Intel Mac, they're essentially the same build. POSIX OS underneath. Minimal dinking to get along with the MAC GUI front-end instead of X/GNOME/KDE. Flash has its own rendering primitives. The core of it works identically, so I'd be supremely confident that something I developed exclusively under Linux would work on a Mac, and shocked if any issues came up.
You claimed your apps would work on Windows too. Are you backing down on that one? I'd still like to see you get your Flex application running on the standard Windows build at the bank I currently work in. I guarantee it won't work.
 
Last edited:
This is NOT a web app. This will be a desktop app.

Eclipse ain't bad. XCode seems too much of a mismatched jumble of tools, for some reason.
If you are planning on developing native Mac OS X applications, Xcode is really your only viable option. I don't know where you got the idea it is a mismatched jumble of tools from, because that is false. It's actually a nicely integrated IDE.

I do not think the exact nature of this application is really relevant. I was merely asking which development environments are the closest to the Microsoft Visual Studio experience, for the Mac.
The answer to that specific question is Xcode. If I was developing Java I wouldn't use it, I'd go with Eclipse, but then I wouldn't use Visual Studio for Java either.
 
If your only tool is a hammer, every problem is going to look like a nail. Anyone who seriously suggests AIR or Flash (or even Silverlight) for serious desktop applications, especially where native APIs are involved, and performance is an issue, should consider expanding their horizons. Learn about more tools, so you know when to use the right tool for the right job.

I don't know where you got the idea it is a mismatched jumble of tools from, because that is false. It's actually a nicely integrated IDE.
I'm sure it is. I guess it's just a different mentality. I've only done some "Hello World" stuff with it, so far, and I found it a bit odd how many different windows one had to interface with, just to do that. Eclipse seems more productive, for some reason, so far. Though, I've hardly done much Mac coding with it, yet, either.
 
I have quite a large collection of 'hammers'. I've been programming in C since before a lot of other programmers were even born, and assembly before that.

I just happen to favor the awesome, universal power hammer that self-feeds nails from an large clip, needs no effort to pound three inch spikes or tiny trim nails, never harms surrounding wood, and keeps my thumb out of harm's way.

Let's just say, I have a plethora of useless old hammers. I'd be about as likely to take up a Mac/OSX hammer as I would be to pick up my old Atari 800 development kit hammer. Jesus, I can still program 6502 opcodes in my head to make the apple speaker go 'beep'.

a0 00 a2 00 e8 e0 ff d0 fd ad 30 c0 c0 ff d0 f3 60

I may misremember an opcode or have the branching off by one, but I'm not going to track down an Apple ][ emulator and test/debug it.

The one thing that has remained a constant, has been the platform rarely remained the same. Tool up to make a game or two, and the next project ends up being for a different platform, and the other one never comes up again because it's 'history'. Apple, Commodore, Atari 800, Atari ST, DOS, Windows 3.x, Windows 95, DirectX, Palm, Gameboy/GBC/AGB/DS, N64, PS, and some obscure embedded chipsets for 'TV Games' and the NUON.

I don't have ONE hammer. I have a big, useless sack of hammers. I've programmed and shipped games on more platforms than most people have written applications.

It's just a different way of looking at the development process, and you'll eventually come around to this point of view. I don't need to debate it. I'm right, and sooner or later you will agree. Or turn to landscaping or whatever it is you do after you burn out and swear you'll never touch another computer.

Write it once, it runs on all of them. Forever. Even unforeseeable new platforms added in the future, like the PS3 web browser, with Flash 9. I'm not backing down on my Flash/Flex code working under Windows or even the PS3 at all. Why would I? They work all the time, every day, thousands and tens of thousands of times a day. Pass QA without a hiccup. You may as well ask if I'm going to back down on an assertion about sunrise coming in the morning.

The OS-dependent days are done, and that makes me happy. You can burn yourself out fighting it, or accept it and adapt before you are crushed under the wheels of the technology bus.
 
I do agree that there is usually no good reason to be programming in a low-level language. No real reason to spend all that effort making a user interface using the native C APIs in Windows when you have managed languages like C# and the Visual Studio editors available.

I suspect AIR works well for many scenarios too, but come on, you know perfectly well that there are also many different scenarios where something as high-level as AIR just won't cut it and you do need (part of) your program to be native. You say you write games, but you know it's not a serious competitor to Direct3D for writing 3D games. It's also not suited for writing software that has to talk to hardware that isn't part of a "standard PC" (ie printer, keyboard, disks, etc). What do I do in AIR if I want to, say, use my TV card? I suspect I couldn't, unless AIR can use COM and whatever the Mac equivalent is. The original post did say that he might be doing that kind of thing in the future.

As for Xcode seeming messy and involving lots of very loosely connected windows, I think that's just the Mac way. You just need some time to get used to it. Containing everything inside a single window is just not how the Mac does it.
 
Aw shucks. I appreciate the gesture, but I am afraid it was not a very original statement. I think it might even qualify as an old cliche, but I guess you never heard it before. So, maybe I should just shut up about it, and pretend it is mine.

Or be a solipsistic autosycophant and nominate it your own self!!

Say it loud, and say it proud!

Or as Tom Lehrer said it:

"Plagiarize…"
 
As for Xcode seeming messy and involving lots of very loosely connected windows, I think that's just the Mac way. You just need some time to get used to it. Containing everything inside a single window is just not how the Mac does it.

There is some value in considering the [gag] interface before the engine.

For one, it can help to define the scope of the project, and inhibit "feature creep".

Most of all, it is good systems analysis. The purpose of the software is to facilitate the needs of the user. It's the people that matter, not the code.

ETA

Suites that include multiple editors include multiple windows under Mac OS; no more, no less. Please, do not conflate the platform with the application.
 
Last edited:
I don't have ONE hammer. I have a big, useless sack of hammers. I've programmed and shipped games on more platforms than most people have written applications.
I can see how someone interested in developing multi-platform games would benefit from platform-independent frameworks. I might even consider using AIR, or something like it, for some games I might slap together, in the future.

But, my near-future potential Mac development needs are different.
 
I suspect AIR works well for many scenarios too, but come on, you know perfectly well that there are also many different scenarios where something as high-level as AIR just won't cut it and you do need (part of) your program to be native. You say you write games, but you know it's not a serious competitor to Direct3D for writing 3D games. It's also not suited for writing software that has to talk to hardware that isn't part of a "standard PC" (ie printer, keyboard, disks, etc). What do I do in AIR if I want to, say, use my TV card? I suspect I couldn't, unless AIR can use COM and whatever the Mac equivalent is. The original post did say that he might be doing that kind of thing in the future.

I did mention system integration being an exception in a previous post.

No, you're not going to write the best new 3D of all time in Flash. Though Flash 10 does have 'more' 3D and finally uses some native 3D capabilities. The nice thing about the 'casual gaming' market is people have suitably low expectations that you can comfortably exceed with a little effort.

If your TV card is NTSC, it will stop working in February. You could just about finish an app just in time for that if you start developing it now.

Or you could use the video streaming built into Flash to get your TV off the web without an extra piece of hardware dangling off your PC/Notebook. Most TV content is streaming off the web already in varying degrees, so use the network and built-in video support that youtube and other online video services use flash for to grab your TV content off the web. It will certainly work better than the off-the-air TV I get since a neighbor somewhere has some sort of UHF band device chirping at 1 second intervals and literally jamming 3/4 of my digital channels.

TV on ANY PC without a dedicated hardware card. Versus a hardware card you have to design, manufacture and sell through in order to ship your software. You could be on the server-end of that business model, selling advertising or subscriptions to get money from ANY of the billion or so PCs out there, rather than the thousands that might have that particular device.

Even better, you get free 'DVR'-like service, because many shows have archives of episodes to watch. Which reminds me, I missed South Park.
http://www.southparkstudios.com/episodes/
 
Most of all, it is good systems analysis. The purpose of the software is to facilitate the needs of the user. It's the people that matter, not the code.
That's an excellent point. That's why cross platform applications are often not the way to go. A Macintosh user expects the user interface to conform to certain conventions and will often complain if it doesn't.

Cross platform frameworks are great for developers because it saves them a lot of porting work at the expense of a worse experience for the user. Sometimes the trade off is acceptable because economics dictate the alternative is no application at all, but sometimes it seems like the developers are sticking two fingers up at the users. For some reason Lotus Notes has just leapt into my mind.
 
The OS-dependent days are done, and that makes me happy. You can burn yourself out fighting it, or accept it and adapt before you are crushed under the wheels of the technology bus.

This statement can only come from someone that doesn't have to adhere to user interface standards (IE a game coder).

Cross-platform applications will ALLWAYS suffer from one thing: The buttons and other controls will be placed wrong on at least one platform.

Think that doesn't matter? Well.. Try to get that "Designed for Windows" badge sometime. You have to follow the Windows Interface Guidelines.

When you're done with that, try to get the same code to adhere to the Apple Human Interface Guidelines.

Guess what. Consistency of UI matters. A lot. The users on the different platforms expect the program to have buttons and other controls placed the same way as other programs on their computer. Otherwise they will hate your program.

That's why OS specific programs will never die.
 
This statement can only come from someone that doesn't have to adhere to user interface standards (IE a game coder).

Cross-platform applications will ALLWAYS suffer from one thing: The buttons and other controls will be placed wrong on at least one platform.

Think that doesn't matter? Well.. Try to get that "Designed for Windows" badge sometime. You have to follow the Windows Interface Guidelines.

When you're done with that, try to get the same code to adhere to the Apple Human Interface Guidelines.

Guess what. Consistency of UI matters. A lot. The users on the different platforms expect the program to have buttons and other controls placed the same way as other programs on their computer. Otherwise they will hate your program.

That's why OS specific programs will never die.

Or rather abstraction from the GUI, for the purpose of the engine, and the attention to the GUI, for the purpose of the utility of the application, shall never die.
 
Incidentally, and totally coincidentally, we got a client who DID use Flash as a principal platform for a chat/video application. But, NOW he wants to get rid of the whole freakin' thing, and replace it with "Industry Standard" application platforms! Heh.

ETA: I don't think it has anything to do with the GUI. I think he simply realized that his code was much more mangled than necessary, for what he wants to do.
 
Last edited:
Think that doesn't matter? Well.. Try to get that "Designed for Windows" badge sometime. You have to follow the Windows Interface Guidelines.

When you're done with that, try to get the same code to adhere to the Apple Human Interface Guidelines.

To get either of those badges, you'll ALSO have to code native to that platform.

In other words, a JAVA app that behaves perfectly according to Microsoft's or Apple's conflicting, arbitrary UI standards does not get the badge. To get the badge, it more or less has to be an exclusive one-off implementation of the UI.

So you sort of missed the whole point of the argument. Microsoft and Apple can kiss my pale, hairy, white ass.

I code to universal UI 'standards', thank you very much. Nobody ever has trouble playing my games, not even very young kids or very old people. If the mouse or pointing device is not a completely alien thing, nobody has any trouble using my software. How much better 'interface standard' could you want?

What passes for a UI provided by Microsoft and Apple is a clunky, antique piece of crap. You've given support to people before. How many 'normal' people who ask you for help actually know how to use the desktop/file system to find their files? NOBODY. You can sit down and spend a whole day showing them how, and the next time they call, they'll ask the same questions.

Wowbagger, I suspect if they have the same crew work on a 'Native' application as wrote the Flash code, it would STILL be a hopeless mess. You can't blame a language/platform for the incompetence of its users, or C/C++/Windows/Mac/etc. should've been thrown out a very long time ago.
 

Back
Top Bottom