I’ve found myself having to address this question several times in the past few months, mostly in the comments to these blog articles. For the convenience of all you Mac users, I’m going to put this in its own article.
Let me explain some realities. First, while I’m deeply entrenched with Windows with seven or eight actively used Windows PCs in our 4-person household, I’m no Redmond apologist. I think Vista has some huge problems beginning with User Account Control (UAC), a feature Apple has mocked in their “Hi, I’m a Mac” TV ads. When it comes to UAC, if California courts can issue restraining orders against people who just talk about committing crimes, then I should make sure I stay here in Iowa.
The “Windows Genuine Advantage” program is another one that scares me. I have a tablet PC I carry in my airplane to display aviation maps and real-time weather information. Last year I installed a Windows update that ran the WGA program and declared that my computer had a bootleg copy of Windows on it. I’m sitting here looking at the hologram certificate from Sony but that wasn’t good enough and Microsoft reached out from Redmond through the WGA program and disabled my computer. I had to send it back to the vendor to have Windows re-installed (the backup CDs turned out to be faulty). So I’m no fan of Windows.
Second, I’ve owned a couple Macs, I’ve done Macintosh development, and I’ve done PDA development on a Mac (remember the Newton MessagePad?). At least two of the seven of us here at Laridian own Macs. So we’re not ignorant of the platform nor emotionally biased against it.
Third, even though we have existing code that could be ported to the Macintosh, in order for it to be truly great it needs to embrace the Zeitgeist of Macintosh. When we wrote QuickVerse for the Macintosh back in 1989, we brought along some user interface concepts from the PC that were foreign to the Mac, and took some heat from users. It’s necessary to understand not just how to write programs that run on a particular platform, but what makes that platform unique and its applications special. We’re hoping, for example, that our iPocketBible for iPhone will look and feel like an iPhone app — not just be a Bible program that runs on the iPhone.
So as we look at the Macintosh platform I hope we come to it without biases beyond the realities of the marketplace. And the main reality is market share. After some downward trends over the last few years, the Mac is back at around the 10% market share that it has always had. When we consider what it will cost to create a Mac version of our software, we have to look at the revenue potential. Can we pay for our development through sales of the program?
One way to estimate this is to compare it to sales of our desktop product. If the Mac is 10% of the personal computer market then we would expect it to do about 1/9th of the business that our Windows product is doing. While PocketBible for Windows is doing well, it’s not doing well enough that we’d be happy with only 1/9th of the revenue it’s generating.
To make matters worse, the new Macs can run Windows through programs like VMWare Fusion. Some Mac users are already purchasing PocketBible for Windows and running it on their Mac. So when we look at revenue potential we have to consider just the net increase in revenue from customers who haven’t already purchased the program. If as few as 10% of customers are already running PocketBible on their Macs, then that eliminates quite a few from the pool of potential buyers. We might then be looking at PocketBible for Macintosh revenues of 1/10th or less of the Windows sales.
When we look at costs, we might be tempted to conclude that the Mac version would be less expensive to create than the Windows version because of the large amount of code that could be shared. But the Windows version already benefited from the large amount of code that was shared from the Pocket PC version of PocketBible. Our Pocket PC code compiles unchanged for the desktop. Then when you add the learning curve involved to make the program not look like a Windows program ported to Macintosh, you can easily arrive at numbers that are actually greater than the cost of developing the program for Windows.
Finally, there’s the question of whether the Macintosh would be “just another platform” or a first-class, fully supported platform for our software. The primary impact of this is whether or not our other products, especially BookBuilder and the synchronization manager, would have to run on the Mac. The latter would be a large project (it was a large project on the PC!). It depends on technologies that don’t exist on the Mac. Similar capabilities exist, I’m sure, but these would have to be researched and implemented. This adds more time and money to the cost of the project.
Of course we’d have the option of not porting all of our desktop apps to the Mac, but then, why do it? This is one of the same reasons we haven’t done many non-English translations of the Bible. It seems to us that just shipping a Spanish Bible is not really addressing the market. What about a Spanish user interface, Spanish reference books, Spanish tech support, and a Spanish Web site? Plug in any other language into that question. Or plug in words like “Muslim” or “Catholic”. With the Mac, some of these issues are trivial, but Mac tech support is not. Sure, it might be easier than Windows support, but remember we’re primarily a Windows-oriented company and somebody has to learn all the “easy” Mac support stuff. It’s one more cost to consider.
What I hope you can see is that this is a non-trivial question and that there are costs here that go beyond simply porting the program to Mac. None of this is to say we’ll never do a Mac version; only to address the question of why we don’t have one now. If things change in the future, we’ll certainly approach the question again. In the meantime we continue to monitor the situation. As usual we appreciate your feedback.