How to develop for Mac and PC
May 26, 2006 1:39 PM Subscribe
How do I get a cross platform (Mac/PC) application developed?
I've previously written an application using the scripting language of a cross platform database program. For various reasons it's getting difficult to continue down that path so now I'm thinking of raising some money to hire some 'real' programmers to do it right. What I can see right away as a problem is the market for this application is about 60%/40% Windows/Mac and I don't want to ignore either platform. So what do I do--develop it for one OS and port it to the other? Should I use something like Java? Any advice on this specific issue as well as on the other pitfalls that doubtless await me will be most appreciated.
I've previously written an application using the scripting language of a cross platform database program. For various reasons it's getting difficult to continue down that path so now I'm thinking of raising some money to hire some 'real' programmers to do it right. What I can see right away as a problem is the market for this application is about 60%/40% Windows/Mac and I don't want to ignore either platform. So what do I do--develop it for one OS and port it to the other? Should I use something like Java? Any advice on this specific issue as well as on the other pitfalls that doubtless await me will be most appreciated.
In engineering, the devil is always in the details. There really isn't any way to advise you based on such a general description of the problem. I can think of a dozen approaches but without knowing what you're really trying to do and what the market expects I couldn't begin to consider which of those dozen would be the right one.
I would suggest that the way to begin is to actually hire a senior programmer and ask him (her) what you should do in order to make it cross-platform.
And you should also consider the question of whether it's really worth trying to address both markets. Will it cost you more than you'd make in return? And will the concessions you'd have to make to portability negatively affect the perceived value by customers in terms of features, performance, ease of use? (Remember that portability may be an advantage to you as a vendor but it doesn't mean anything to 99% of your customers.)
posted by Steven C. Den Beste at 2:01 PM on May 26, 2006
I would suggest that the way to begin is to actually hire a senior programmer and ask him (her) what you should do in order to make it cross-platform.
And you should also consider the question of whether it's really worth trying to address both markets. Will it cost you more than you'd make in return? And will the concessions you'd have to make to portability negatively affect the perceived value by customers in terms of features, performance, ease of use? (Remember that portability may be an advantage to you as a vendor but it doesn't mean anything to 99% of your customers.)
posted by Steven C. Den Beste at 2:01 PM on May 26, 2006
You could have one core team that does the central aspect of your product, and then two small teams dedicated to maintaining the front-end, making sure it is what users of that platform expect, etc.
The initial planning for such a division is critical. The core product needs to be a nice and generic piece of code relevant to both teams. but at the same time this core should not re-invent things that are already done for you in one (or both) of the target platforms.
posted by clord at 2:38 PM on May 26, 2006
The initial planning for such a division is critical. The core product needs to be a nice and generic piece of code relevant to both teams. but at the same time this core should not re-invent things that are already done for you in one (or both) of the target platforms.
posted by clord at 2:38 PM on May 26, 2006
Consider developing your app as a hosted web application. That way it works on any platform with a reasonable web browser and network access.
posted by StarForce5 at 2:47 PM on May 26, 2006
posted by StarForce5 at 2:47 PM on May 26, 2006
the wxWindows platform is exceptionally keen for this purpose.
posted by boo_radley at 2:52 PM on May 26, 2006
posted by boo_radley at 2:52 PM on May 26, 2006
In order of opensource-ness to commercial-ness, wxWindows/gcc, Java (although there is still platform-specific stuff to worry about), Qt/MSVC or Qt/gcc (Qt includes an entire build environment).
Depending on the app, I might be interested. Drop me an email.
posted by devilsbrigade at 4:09 PM on May 26, 2006
Depending on the app, I might be interested. Drop me an email.
posted by devilsbrigade at 4:09 PM on May 26, 2006
So what do I do--develop it for one OS and port it to the other?
There are only a few apps that could reasonably fit within your 60/40 range of Windows/Mac, so I'm going to go out on a limb and guess that this is a graphics/video app of some kind. If this is the case, the priority will be on speed, thus cross-platform solutions are (basicaly) out. Pick a platform, build your app, and document like crazy so the porting won't be too painful.
If I'm wrong, then go with Java. Not because it's particularly amazing or I'm a zealot or anything, but because you'll want the largest possible number of libraries and frameworks available to you (preferably open-source), so you should go with the one with the biggest adoption.
posted by Civil_Disobedient at 4:34 PM on May 26, 2006
There are only a few apps that could reasonably fit within your 60/40 range of Windows/Mac, so I'm going to go out on a limb and guess that this is a graphics/video app of some kind. If this is the case, the priority will be on speed, thus cross-platform solutions are (basicaly) out. Pick a platform, build your app, and document like crazy so the porting won't be too painful.
If I'm wrong, then go with Java. Not because it's particularly amazing or I'm a zealot or anything, but because you'll want the largest possible number of libraries and frameworks available to you (preferably open-source), so you should go with the one with the biggest adoption.
posted by Civil_Disobedient at 4:34 PM on May 26, 2006
What does your app do?
If it requires media handling of any sort, Macromedia Director may be something you want to check out. It has an easy and powerful scripting language, can do about anything a "real" app can (short of say, Photoshop) with a fraction of the development time/cost of a lower level language, and compiles cross platform (OS 9, OS X and Windows).
I'm working on a desktop app in it right now (surfing break) used by several of the world's largest sports apparel companies.
Direct-L is a good list to inquire about possibilities if you want to pursue it.
posted by nonmyopicdave at 4:37 PM on May 26, 2006
If it requires media handling of any sort, Macromedia Director may be something you want to check out. It has an easy and powerful scripting language, can do about anything a "real" app can (short of say, Photoshop) with a fraction of the development time/cost of a lower level language, and compiles cross platform (OS 9, OS X and Windows).
I'm working on a desktop app in it right now (surfing break) used by several of the world's largest sports apparel companies.
Direct-L is a good list to inquire about possibilities if you want to pursue it.
posted by nonmyopicdave at 4:37 PM on May 26, 2006
Response by poster: What does your app do?
First, thanks to all for your interest and great responses.
The app, or to be more accurate a planned suite of apps, will be aimed at scientists, initially those involved in biomedical research, which is what I'm familiar with. Database software that allows them to record and track what they do daily in the lab. In the corporate world you've got MS Office, accounting programs, etc. Scientists have no dedicated software save for certain specialty applications: they record their work by writing in a notebook--the pen and paper kind. The unusual platform skew that Civil_Disobedient noted is a legacy of Apple's failure to maintain this market--it was initially, to my estimation at least, more like 90/10 in favor of Mac 15 years ago, but this has been eroded.
So as far as technical requirements it's pretty bog-standard database software--not requiring high end graphics or video support. But the cross platform nature is crucial, as I wish to revolutionize the way scientists do their work, and I can't do that while I'm excluding anyone.
posted by Turtles all the way down at 5:30 PM on May 26, 2006
First, thanks to all for your interest and great responses.
The app, or to be more accurate a planned suite of apps, will be aimed at scientists, initially those involved in biomedical research, which is what I'm familiar with. Database software that allows them to record and track what they do daily in the lab. In the corporate world you've got MS Office, accounting programs, etc. Scientists have no dedicated software save for certain specialty applications: they record their work by writing in a notebook--the pen and paper kind. The unusual platform skew that Civil_Disobedient noted is a legacy of Apple's failure to maintain this market--it was initially, to my estimation at least, more like 90/10 in favor of Mac 15 years ago, but this has been eroded.
So as far as technical requirements it's pretty bog-standard database software--not requiring high end graphics or video support. But the cross platform nature is crucial, as I wish to revolutionize the way scientists do their work, and I can't do that while I'm excluding anyone.
posted by Turtles all the way down at 5:30 PM on May 26, 2006
How complicated is/are the database schema? Are we talking about heavy objects (with several different one-many, many-one and many-many) relationships? If it's just lightweight objects, you could go in any number of directions. Web-app (PHP/Ruby/.NET) + MySQL/Postgres/MS SQL... etc. ad. infinitum.
If the objects are substantial, however, I'd recommend Java all the way.
posted by Civil_Disobedient at 5:40 PM on May 26, 2006
If the objects are substantial, however, I'd recommend Java all the way.
posted by Civil_Disobedient at 5:40 PM on May 26, 2006
Response by poster: Civil, I'll try to answer your question via an analogy. Let's say you'd have an individual record for a pie--record name, ID, date of baking etc. That record would be linked to a record for the berries that were used to make the pie. It would also be linked to the particular recipe used to make the pie. Possibly linked to another database of notes as to how the pie was cooked that day. Other records would link back to the pie record in a similar way--the analogy kind of breaks down at this point ;-) . I'm envisioning storing the recipe as XML, if that makes a difference.
posted by Turtles all the way down at 6:15 PM on May 26, 2006
posted by Turtles all the way down at 6:15 PM on May 26, 2006
You might also want to take a look at Cincom Smalltalk. It produced the cleanest cross-platform GUIs I've ever seen. You don't seem to have settled on a language yet, so let me just say that smalltalk is a pleasure to work with.
posted by gemini at 6:33 PM on May 26, 2006
posted by gemini at 6:33 PM on May 26, 2006
Response by poster: That looks promising gemini: how easy would it be to find someone who could develop on that platform?
posted by Turtles all the way down at 6:38 PM on May 26, 2006
posted by Turtles all the way down at 6:38 PM on May 26, 2006
The app, or to be more accurate a planned suite of apps, will be aimed at scientists, initially those involved in biomedical research, which is what I'm familiar with. Database software that allows them to record and track what they do daily in the lab. In the corporate world you've got MS Office, accounting programs, etc. Scientists have no dedicated software save for certain specialty applications: they record their work by writing in a notebook--the pen and paper kind.
Go with Java for this. There are great cross platform APIs for C++, but for general office-y stuff, java will be great. In fact, you probably won't need to do anything to make it work on Macs and windows machines (other then making sure they both have the JVM installed).
As far as smalltalk goes: That's the kind of thing you only want to mess around with if you're going to be programming it yourself, sadly. Trying to find a Smalltalk programmer will be very difficult.
If you want to program something yourself you have a lot more options then if you want to hire someone to do it. Java is by far the easiest way to do this.
---
That said, what about a totally web-based system? That would then work on any platform with a browser. General office type apps are mostly being written as web-based applications these days. Of course, it might be easier to market your product as a shink-wrapped box then as a web-based service. After all, I'd hate to have all my data on someone else's server, if it goes down...
posted by delmoi at 6:57 PM on May 26, 2006 [1 favorite]
Go with Java for this. There are great cross platform APIs for C++, but for general office-y stuff, java will be great. In fact, you probably won't need to do anything to make it work on Macs and windows machines (other then making sure they both have the JVM installed).
As far as smalltalk goes: That's the kind of thing you only want to mess around with if you're going to be programming it yourself, sadly. Trying to find a Smalltalk programmer will be very difficult.
If you want to program something yourself you have a lot more options then if you want to hire someone to do it. Java is by far the easiest way to do this.
---
That said, what about a totally web-based system? That would then work on any platform with a browser. General office type apps are mostly being written as web-based applications these days. Of course, it might be easier to market your product as a shink-wrapped box then as a web-based service. After all, I'd hate to have all my data on someone else's server, if it goes down...
posted by delmoi at 6:57 PM on May 26, 2006 [1 favorite]
Web based system. Ruby on Rails (ruby) or Catalyst (perl) (http://catalyst.perl.org). With Catalyst you also win a huge stack of libraries including all of the Bio:: namespace.
The web is the future here, not desktop applications.
posted by singingfish at 7:23 PM on May 26, 2006
The web is the future here, not desktop applications.
posted by singingfish at 7:23 PM on May 26, 2006
I know I'm committing open source heresy by suggesting this, but you might want to look for a RealBasic person. It's cross platform and you usually don't have to install a bunch of other stuff along w/ it.
posted by jdfan at 7:35 PM on May 26, 2006
posted by jdfan at 7:35 PM on May 26, 2006
I'll throw in for a web-based solution, too. It sounds to me like there's nothing in this that really needs to be local. Even if there is, you can easily write light-weight widgets for Windows and OS X that behave like users of those OS' expect, rather than Java whose windowing toolkits are some unholy middle-ground between the two.
Re: delmoi's point about having your data on someone else's server - My knee-jerk reaction is that this is just FUD. If you're being smart about your users' data it's a hell of a lot more secture on your servers than it is on their boxes. Raid-array the hell out of it and do daily offsite-backups and you can offer better data integrity than any scientist's personal box. That might even be a major selling point if you can convince them that you're not going to steal their stuff.
posted by heresiarch at 7:38 PM on May 26, 2006
Re: delmoi's point about having your data on someone else's server - My knee-jerk reaction is that this is just FUD. If you're being smart about your users' data it's a hell of a lot more secture on your servers than it is on their boxes. Raid-array the hell out of it and do daily offsite-backups and you can offer better data integrity than any scientist's personal box. That might even be a major selling point if you can convince them that you're not going to steal their stuff.
posted by heresiarch at 7:38 PM on May 26, 2006
Response by poster: The web-based idea appeals to me greatly. I think delmoi's personal reticence about having one's data on someone else's server is unfortunately going to be representative of the scientists in my market, whose data, after all, is everything to them. It would be a marketing challenge to say the least.
Many thanks again for introducing me to so many different possibilities! I can't think of any other way I would have so easily gotten this great input.
posted by Turtles all the way down at 8:31 PM on May 26, 2006
Many thanks again for introducing me to so many different possibilities! I can't think of any other way I would have so easily gotten this great input.
posted by Turtles all the way down at 8:31 PM on May 26, 2006
Don't forget that OpenOffice.org is cross-platform and has database tools built in. You may need to do less work than you thought.
posted by flabdablet at 10:49 PM on May 26, 2006
posted by flabdablet at 10:49 PM on May 26, 2006
WxWindows
Ultimate++ (although intel mac only so far)
SDL (for more realtime/games)
and stick to posix style code :)
Pick a core library maybe, if you need to fork, thread, network. I have my own you can use, guaranteed to work on all platforms :)
posted by lundman at 11:09 PM on May 26, 2006
Ultimate++ (although intel mac only so far)
SDL (for more realtime/games)
and stick to posix style code :)
Pick a core library maybe, if you need to fork, thread, network. I have my own you can use, guaranteed to work on all platforms :)
posted by lundman at 11:09 PM on May 26, 2006
Civil, I'll try to answer your question via an analogy.
Excellent abstract analogy! Given that level of complexity, I highly, highly recommend Java.
...rather than Java whose windowing toolkits are some unholy middle-ground between the two.
You're missing something. Combine both Java and a webapp. Specifically something like Tomcat (a java web app server).
When most people think "Java application," they think either stand-alone program (like the Azureus Bittorrent client), or Java-loaded-inside-a-browser (which kicks off an instance of your JVM, causes your machine to grind to a halt, etc.) The first is fine if you need a write-once, run-anywhere stand-alone application with file access (Azureus, for instance, or IDEA's IntelliJ IDE for software development). But as others have already said, a web app gives you a lot of benefits: mainly, someone has already done all the hard work building the UI engine, so you only have to hook up the guts and you get a powerful display package out of the box.
The reason you'll probably need a Java backend is because your objects are going to be pretty complex with many interrelationships that all tie to a big database. With a system like Hibernate, you provide the mappings to the tables, then define how those columns relate to the overall objects, and that's it. You never have to do a single SQL query--you just deal with the objects. Hibernate supports a concept called lazy-loading, which is a very effective way of caching resources and not calling queries until they're absolutely necessary.
For instance, let's say you have an object called Company. This object has some one-to-one properties like companyName, companyTaxID, etc. It also has a set of Employee objects. Those employee objects have Address objects attached to them. The company also has an address object attached to it. The Employees relate to a lookup-table of EmployeeTypes. Based on those types ("president", "vice-president", "worker-bee", etc.), you might have a table of business Roles, and another table of Permissions. So the "vice president" has an "administrative" role, which gives him total access permissions to, say, the employee records.
My point with the simple exercise is to show how things can quickly get out-of-hand if you were to try and hand-code sql queries. With Hibernate, you can do a company.getEmployees() method that returns a set of employees, all of whom have addresses--but the addresses won't be loaded until they are actually needed. This whole technology allows you to completely abstract your database schema from your system objects. If you're interested in the gory details of Object/Relational mapping, read this excellent primer.
Once you get to a certain level of DB complexity, you have to think about how you're going to deal with the data. Most "internetters" are only used to the simplest of relationships: an Article has an Author and a WrittenOn date. A "Section" has a group of "Articles", etc. All nice and tidy. Real apps (useful ones, at least) aren't nearly as nice to play with, so you'll need some help on the backend. The reason I suggest Java is because Hibernate+Spring or Hibernate+Tapestry (or Hibernate+JSF) are popular frameworks so you won't have a problem finding developers. And more importantly, all this shit is free. So you can concentrate spending your limited resources on the "talent" and not on the "tools".
posted by Civil_Disobedient at 11:49 PM on May 26, 2006
Excellent abstract analogy! Given that level of complexity, I highly, highly recommend Java.
...rather than Java whose windowing toolkits are some unholy middle-ground between the two.
You're missing something. Combine both Java and a webapp. Specifically something like Tomcat (a java web app server).
When most people think "Java application," they think either stand-alone program (like the Azureus Bittorrent client), or Java-loaded-inside-a-browser (which kicks off an instance of your JVM, causes your machine to grind to a halt, etc.) The first is fine if you need a write-once, run-anywhere stand-alone application with file access (Azureus, for instance, or IDEA's IntelliJ IDE for software development). But as others have already said, a web app gives you a lot of benefits: mainly, someone has already done all the hard work building the UI engine, so you only have to hook up the guts and you get a powerful display package out of the box.
The reason you'll probably need a Java backend is because your objects are going to be pretty complex with many interrelationships that all tie to a big database. With a system like Hibernate, you provide the mappings to the tables, then define how those columns relate to the overall objects, and that's it. You never have to do a single SQL query--you just deal with the objects. Hibernate supports a concept called lazy-loading, which is a very effective way of caching resources and not calling queries until they're absolutely necessary.
For instance, let's say you have an object called Company. This object has some one-to-one properties like companyName, companyTaxID, etc. It also has a set of Employee objects. Those employee objects have Address objects attached to them. The company also has an address object attached to it. The Employees relate to a lookup-table of EmployeeTypes. Based on those types ("president", "vice-president", "worker-bee", etc.), you might have a table of business Roles, and another table of Permissions. So the "vice president" has an "administrative" role, which gives him total access permissions to, say, the employee records.
My point with the simple exercise is to show how things can quickly get out-of-hand if you were to try and hand-code sql queries. With Hibernate, you can do a company.getEmployees() method that returns a set of employees, all of whom have addresses--but the addresses won't be loaded until they are actually needed. This whole technology allows you to completely abstract your database schema from your system objects. If you're interested in the gory details of Object/Relational mapping, read this excellent primer.
Once you get to a certain level of DB complexity, you have to think about how you're going to deal with the data. Most "internetters" are only used to the simplest of relationships: an Article has an Author and a WrittenOn date. A "Section" has a group of "Articles", etc. All nice and tidy. Real apps (useful ones, at least) aren't nearly as nice to play with, so you'll need some help on the backend. The reason I suggest Java is because Hibernate+Spring or Hibernate+Tapestry (or Hibernate+JSF) are popular frameworks so you won't have a problem finding developers. And more importantly, all this shit is free. So you can concentrate spending your limited resources on the "talent" and not on the "tools".
posted by Civil_Disobedient at 11:49 PM on May 26, 2006
you can always have the server running on localhost or in the local netblock for the web based solution. Still seems to make most sense to me.
posted by singingfish at 3:02 AM on May 27, 2006
posted by singingfish at 3:02 AM on May 27, 2006
This thread is closed to new comments.
Performance is the major pitfall of cross-platform frameworks. If you're writing a graphics or audio application, for example, the main engine of your application should probably be written native, with hooks into platform-specific GUI elements.
posted by Mr. Six at 1:47 PM on May 26, 2006