The Old Joel on Software Forum: Part 3 (of 5)

Windows/Mac Development

I'm an experienced Windows Developer, I have a chance with a friend to develop a software package, after some analysis, it turns out that a large percentage (around 50%) of our potential customers use a Mac.

The application itself will be a fairly simple GUI (a few tabbed windows), access a local database and generate forms with information (in pdf format).

The question. What is the best way to approach this from the standpoint of cross platform development. What development tools should I plan on for Mac? What database? Should I go with something like Java and a browser client? or Should I just develop 2 separate GUI's specific for the target platform and abstract reuse (thru recompile) of common library code?

Suggestions appreciated.

Mike

MikeG
Tuesday, November 11, 2003

You should probably do whatever your potential mac market prefers.

They might, in a small business environment, prefer filemaker and java with the apple ides.

In a big business environment (like prepresses that haven't converted to windows yet) they'll probably have hybrid networks where macs have ODBC drivers (to access oracle/sql server with) and appropriate client tools to allow windows file share and printer share.

What does your software do? Tell us more! :-)

Li-fan Chen
Tuesday, November 11, 2003

I would consider building the app in Python, in that case. Either abstracting the UI to separate implementations for PC and Mac (preferred), or using a cross-platform widget set (uglier).

Phoenix
Tuesday, November 11, 2003

Here's another crucial question: what did you write your current software in? (the windows port).. What external software or commercial libraries do you have dependency on?
All of this limits or enables you depending on the situation.

Here are some ideas (that might be or might not acceptible):

http://sourceforge.net/projects/tclpro

If you have been scripting, the open source scripting world has a language called tcl that's still doing pretty well. They have a open sourced commercial quality compiler call tclpro that is capable of creating windows, linux, *nix, and mac osx executables. If you are forced to support MAC OS 9 I dunno what you'll have to do, code obfusciation might still be possible but would probably be sorta half-assed. Otherwise it compiles to everything.

I believe you can get Python and Perl bytecode interpreters for all these platforms. You don't have to distribute the raw source.

I don't know if Microsoft or Borland has any clones of their tools in the mac osx space. There's RealBasic to substitute Visual Basic.

If I don't make any sense it's because I have managed to install Windows in millions of all the possible wrong ways in the last 2 weeks. Very pissed and very sleepy.

Li-fan Chen
Tuesday, November 11, 2003

Ignore Windows and focus 100% Mac. Seriously.

* There's more competition on Windows, which means that your marketing costs will be higher.

* Windows dev tools are more expensive.

* I'd guess that MacOS X has a higher growth rate than Windows, but I don't have any data to back this up (anyone?).

* Mac buyers have more money and don't mind shelling it out for decent products. Being Mac-only may further endear your product to them.

Bacially, 50% of your customers are going to be more expensive to acquire, so concentrate on the cheaper half first. Also, it'll be more expensive to maintain two codebases.

The downsides to this strategy are the cost of buying a Mac for development and the learning curve. As ever, the cheaper option should be obvious.

Paul Sharples
Tuesday, November 11, 2003

Mac folks have Virtual PC, if they really really want, they can run your software just fine.

Li-fan Chen
Tuesday, November 11, 2003

Good point! But with MS' purchase, how much longer can vendors rely on this?

Paul Sharples
Tuesday, November 11, 2003

http://webperso.easyconnect.fr/bdesgraupes/tcl.html

Li-fan Chen
Tuesday, November 11, 2003

SWT deserves a good, hard look, especially if you're proficient in Java. It supports Mac OS X (but not OS 9), Windows, GTK, Motif, and a few others. See http://www.eclipse.org for more information.

Rob Warner
Tuesday, November 11, 2003

I've noticed more and more ISVs using Qt for this kind of situation. Can't comment from experience.

Eric Sink
Tuesday, November 11, 2003

If the front end isn't terribly complicated you may be better off using the Cocoa Frameworks and building a new interface. Mac users are typically a bit fanatical when it comes to a good Mac-ish interface (while this can be had with Java it can also be very difficult to achieve in a satisfactory manner).

I highly suggest separating the front end from the back end and developing it in Cocoa. If you know Java you can actually write to the Cocoa frameworks using Java (rather than Objective-C). Additionally you can write the code in C and just use Objective-C for the interface calls. Its a pretty flexible system.

For your database, you aren't limited to Filemaker (and I certainly wouldn't use it). What are you using on the Windows side? All Macs running OS X have MySQL preinstalled. I don't think its turned on, but you can certainly write code to do that, build the database you require and load it with data.

Best of luck. Its always nice to see programmers actually thinking beyond the overall marketshare to consider their potential market.

Lou
Tuesday, November 11, 2003

Thanks for all the comments.

We currently do not have the application developed, just in the process of defining the requirements. The app is aimed at a medical profession and would be a niche product. We are looking to bump-out/displace a (soon-to-be) competitor (we have identified problems with their software, the need for new features and clearly better support). It just so happens that this group of medical professionals have a disproportianately high number of Macs and since it is a niche market- we really don't want to limit our already smaill market (not to mention give our competitor an advantage, since they support both).

I know exactly how I would develop this product in the Windows world, my problem is the Mac world and making sure that I have a final application that is easy to maintain/support in both worlds.

The other consideration is a web package but since we will be working with sensitive data, we prefer not to get involved with all the privacy/legal issues by using our servers to store the data and since our clients are generally small practioners it would be cost prohibitive (from hardware and maintenance standpoints) to build the infrastracture at each office. Basically our clients will manage their own data, in accordance with their own policies and we will have nothing to do with that info other than get it to the proper forms/reports.

Thanks again for the suggestions and comments.

Mike

MikeG
Tuesday, November 11, 2003

First of all, I wouldn't recommend expecting Mac users to shell out for VPC just to run your app. Secondly, VPC will not run on a G5 any time soon. From http://www.macnn.com/news/20804&startNumber=10 : "Virtual PC relies on a feature of the G3/G4 processors called 'pseudo little-endian mode' for increased performance when emulating a Pentium processor.... Because the new G5 processor does not support this feature, large portions of the VPC for Mac program must be rewritten..." According to accounts I read elsewhere, this was a really key feature (as in "made the whole thing possible", not just "increased performance") so it might take ages for a new version to come out.

brian
Tuesday, November 11, 2003

I think you should take a look at RealBasic. Never used it, but it seems to be perfect for your needs.

http://www.realbasic.com

Ricardo Antunes da Costa
Tuesday, November 11, 2003

"All Macs running OS X have MySQL preinstalled."

Wrong. I've got 10.2.8 on my desktop and 10.3.1 on my laptop and MySQL is not installed on either. (According to both the Finder's 'find' and UNIX's 'locate' after `/sudo /usr/libexec/locate.updatedb`) I've been using OS X since 10.0.3. OS X has *never* come with MySQL.

That's not to say that MySQL doesn't install easily and run fine on OS X. I've been doing that since 10.1 thanks to Marc Liyanage: http://www.entropy.ch/software/MacOSX/

brian
Tuesday, November 11, 2003

RealBasic allows to create 2 different executables, one for mac and one for windows from the same base code

Anon
Tuesday, November 11, 2003

RealBasic (which does include its own linked database engine) might meet your needs, as long as those needs don't involve use of any particularly fancy controls (I disregarded it almost immediately for lack of prebuilt charts, though you could probably hack your own if you were so inclined). (= It does seem to have some better OOP features than, say, Visual Basic, though.

Sam Livingston-Gray
Tuesday, November 11, 2003

Realbasic works really well. As far as the charts go, I created some myself within a couple of hours.

There is also supposed to be a version that compiles for Linux soon.

mac
Tuesday, November 11, 2003

Four good choices, depending on your language preference:

1. JAVA - use Java + SWT, compiled with GCJ
2. C++ - use GCC + wxWindows
3. Python - use wxPython
4. Basic - use RealBasic

I prefer #2, since wxWindows is stable and extremely MFC-like, and I don't have to worry about releasing source code or byte code (that can be decompiled).

If you're used to VB, then go for the RealBasic solution.

If you're a Java geek, then #1 is the best way to go, since Swing is a POS, AOT compilation beats JIT compilation, and you really don't want people to decompiling your bytecode anyway.

For #3, the best GUI for Python is wxPython (based on wxWindows), since TK is a piece of crap.

D. Veloper
Tuesday, November 11, 2003

what about the following schema

1) your products installs a small web server locally (on some port like 123456)
2) Web server serves out web pages dynamically (DHTML UI) - cross platform UI (just have to care about differen browsers, ouch).

3) The same code (similar code) can later be used as a WEB version of the product.
4) Profit.

Michael Moser
Tuesday, November 11, 2003

Good, except you might have a "slight" problem attaching to "port 123456" *snicker*

Nick Burns, Your Company Computer Guy
Tuesday, November 11, 2003

another vote for realbasic, Im using it for close to 50% of my developing (90% now of my x-plat development).

Its _very_ good in lots of ways.

FullNameRequired
Tuesday, November 11, 2003

Could the application be web based?

Ben Richardson
Tuesday, November 11, 2003

If you use Java you could go for two approaches:

i) Develop a web-based solution. By developing the application with Java you could use something like FOP - http://xml.apache.org/fop - to generate PDFs (assuming it meets your requirements). With this option you're open to the widest array of clients, but may have to sacrifice usability, speed, etc.

ii) Develop a desktop-based solution. There are a number of databases written in Java. I know that HSQLDB can be packaged as a .jar file and I would assume that others like McKoi can also, this makes distributing a database easy - i.e. you don't have to rely on clients setting their own databases up. Some notes about this: I'm not sure if HSQLDB is production-quality (although it seems to be distributed with almost everything), if you're using any JDK > 1.2 your users will need to run OS X (rather than classic).

Walter Rumsby
Tuesday, November 11, 2003

hi. i have done what you described. for the medical industry as well. :)

don't use WX PYTHON, it seems good in theory but in practice it is not so good.

what you want to do is just use the built in dev tools with osx to create the forms. then hook them up to postgresql or mysql. osx can easily produce pdfs. the hardest part is going to be writing the installer. it is more work two maintain 2 distinct codebases (OSX, Windows) but the end result is a much better product. the cross-platform ideas (java/wxPython) seem interesting until you actually try them. it just ends up producing software that seems sort of clunky on both platforms.

good luck!

wormser
Tuesday, November 11, 2003

Walter's web-based solution sounds interesting. You might consider writing the app as a web server with the interface in HTML. Or you may be able to write it entirely in a web-scripting language like PHP. This might not satisfy all of your interactivity needs, but it could be easier than writing a cross-platform GUI.

Dan Maas
Tuesday, November 11, 2003

Actually the point about OS X and PDFs is extremely valid and relevant. And one I forget.

Given this I would probably develop a Coca-based Mac desktop application. Longhorn's vector-based layout will offer similar features for Windows (eventually :)).

Walter Rumsby
Tuesday, November 11, 2003

You should definitely consider REALbasic, especially if your GUI needs are fairly simple. RB has conditional compilation to allow to have specific code for each platform. And the GUI controls that are included look great on each platform. It can connect to just about any database.

You might want to subscribe to the RB mailing lists to get more feedback from that community.
http://support.realsoftware.com/listmanager/

Also, check out REALbasic Developer Magazine (disclaimer: I'm a columnist).
http://www.rbdeveloper.com

-- Paul

Paul Lefebvre
Tuesday, November 11, 2003

"There is also supposed to be a version that compiles for Linux soon."

This could be the solution to the Linux RAD problem that Kylix wasn't.

Jim Rankin
Tuesday, November 11, 2003

Jim,

I think the problem Klyx was that it was a solution to a non-existent problem.

There's just not enough demand for desktop apps on Linux (compared to Windows). So, Klylix offered minor benefits, IMHO.

I've not used Kylix, but I've used Delphi a bit and thus considered (then diregarded) Kylix.

Entrepreneur
Tuesday, November 11, 2003

Paul wrote:

" There's more competition on Windows, which means that your marketing costs will be higher."

Marketing costs will be the same whether he has a Mac or Windows version.

Although, I agree that Mac users may be more accustomed to paying more for software. So, while COSTS may not be higher for Windows-customer sales, REVENUE may be higher from Mac customers.

CHEAPER TO GIVE VIRTUAL PC AWAY
BTW, though, we have a 18 windows-only products (98% of our customers are on windows). We just GIVE Virtual PC away free with any purchase of $400 or more. It's much cheaper than us writing for dual platform or rewriting our apps.

Entrepreneur
Tuesday, November 11, 2003

"It's much cheaper than us writing for dual platform or rewriting our apps."

also much less successful.
Unless your market is a captive audience, there is virtually no chance whatsoever of getting the average mac user to boot into windows everytime they want to run an application.

<g> If we wanted to do that, we'd have purchased a windows machine already.

FullNameRequired
Tuesday, November 11, 2003

RealBASIC is definitely the solution to this problem. We've used it to develop prototype thick client applications to enrich our previously browser-based software, with no negative issues to report.

If your application is internet-centric you may want to think about the new Flash stuff for rich internet applications. I'm seeing more and more comment about this stuff, and starting to think it might be worth some R&D time.

But if your application is local, I don't think there is any viable alternative for professional cross-platform commercial application development.

HeWhoMustBeConfused
Tuesday, November 11, 2003

Here are some options for you:
- CPLAT: http://www.ksoft.net/cp_home.htm C++ for Windows/Mac (9,X)/Linux. $50/developer, $300 for a site license
- Qt: http://www.trolltech.com C++ for Windows/Mac OS X/Linux. $1-3k depending on options.
- WxWindows: wxwindows.org for C++, free. Windows/Mac (9,X)/Linux
- Java
- Realbasic ($99-$640 per platform)
- <favorite scripting language here>
- Mozilla & XUL provide a cross-platform, XML and Javascript application development platform. Link in your own specialized code to get the specifics to work.

One issue that'll come up is adherence to the Aqua guidelines for OS X. Most of the cross platform solutions above draw some their own controls, even when native controls are available. These same libraries also produce apps that just don't look right.

Try running an app or two from each and see which one looks best for the stuff you're trying to do. Watch the fonts used. You'll probably be able to tweak the libraries as needed to get the look & feel just right, just be prepared to do the work.

Java's still sluggish. Realbasic's, well, Basic. Qt does do some of its own drawing, but I believe it comes with source, so you can fix the trouble spots. Qt also sells a platform-independant database access library. If you're still looking around for databases, try sleepycat.com.

Depending on your needs, you could write frontends for each platform. If you're just using common controls, it need not be too hard. Apple's Carbon and Cocoa are both quite good on their own. Carbon's HIView and Carbon Events provide essentially all the features a C++ framework has, only it's built in and C-based. It's the best choice if you expect speed to be an issue (or, like me, just prefer C++ because it's the best damn language out there).

Cocoa's Objective-C based, and is best suited for apps that mostly uses common controls, etc.

Finally, if you really want a C++ framework for OS X, you can get Codewarrior, which includes PowerPlant X. It's really new (for better or worse), and works mostly as a thin wrapper around Carbon.

As for dev environments, Codewarrior for Mac can target both mac and windows. And there's always GCC. I'd recommend looking into a single compiler for all your targets, just to save the headache of 'compiler porting.'

H. Lally Singh
Wednesday, November 12, 2003

Oh yeah, and to answer your question about whether or not you want two GUIs or a cross-platform environment, I'd recommend two.

It sounds like the GUI's simple enough that it'd save you time to write two in the (significantly better) native tools than any cross-platform solution. A quick Cocoa frontend in OS X and God-knows-what in Win32 (sorry, I don't develop for it anymore, keeps making me vomit) interfacing to the 'meat' of your app in C++ (you can interface Objective-C to C++ simply through the 'Objective-C++' compiler) sounds about right. More importantly, the UI does a lot of the selling work for you, and additional effort spent here may as well be charged to your marketing dept :-)

Where is most of the code going to be (ui, db, etc)? Make your decisions around that first. Next, do a sketch of your UI on paper, and look at what's necessary to implement that UI in each of the choices you've got. Compare the costs of each to the fidelity of the UI (many cross platform systems take the 'suckiest policy for each platform' approach, and lead to terrible user experience).

To make up for all the ranting, here's a link to a list of PDF rendering libraries:
http://www.planetpdf.com/mainpage.asp?WebPageID=450

H. Lally Singh
Wednesday, November 12, 2003

Use RealBasic if you want to develop only one GUI. But it will be the lowest common denominator.

If you can, develop two seperate UIs. Here I can only second the use of Cocoa on Mac OS X. It is great and works like a dream.

Keep in mind though, that your target audience might be still running Mac OS 9 or earlier. That rules out Cocoa and you are left with RealBasic.

Kerreg
Wednesday, November 12, 2003

"Use RealBasic if you want to develop only one GUI. But it will be the lowest common denominator."

actually, thats not true. <g> Im not a rb zealot, I promise.

RB is a compiled langauge, not an interpreted one, and it provides native gui widgets for all platforms, and it _does_ provide platform specific features where they exist...this lets you target each platform as specifically as you wish..._or_ you can provide a single gui across all of them, the choice is entirely up to you :)

FullNameRequired
Wednesday, November 12, 2003

I recommend using Python. Even if you don't use the cross-platform wxPython GUI library, you can still create the 90% core code in Python and the 10% platform-specific code in C++ (if you really want to). wxPython uses native GUI widgets, so your app doesn't look too alien:

http://www.wxpython.org/screenshots.php

Since you already have a competitor, a safe dynamic language like Python might be a HUGE benefit, reducing bugs and development time. If your competitor is slogging away with some buggy C++ code, you can deliver your product faster and more often. Get your product in your customers hands first and respond to their problems and requests quickly

Paul Graham's "Beating the Averages" makes the case of programming language as a business advantage. He uses Lisp, but Python will give you 99% of the same advantages. :-)

http://www.paulgraham.com/paulgraham/avg.html

Good luck!

runtime
Wednesday, November 12, 2003

"If your application is internet-centric you may want to think about the new Flash stuff for rich internet applications. I'm seeing more and more comment about this stuff, and starting to think it might be worth some R&D time."

Just make sure not to get carried away with doing Cool Stuff In Flash just because you can. I recently returned a Sony Net MiniDisc player in part because its software was complete crap. Interface was written in Flash and admittedly was kinda neat to look at, but slow to switch modes (because it had to animate everything; give me a tab control any day) and confusing (as in, I kept forgetting how to transfer files to the player).

Sam Livingston-Gray
Thursday, November 13, 2003