Slashdot Mirror
Does New Development For Mac OS X Make Sense?
DLWormwood wonders: "As a long time Mac developer, originally as a hobbyist and then a professional, I'm feeling pessimistic about the future of the platform now that Apple is embracing Intel and abandoning the few remaining 'Mac' technologies (like the PowerPC and OpenTransport) left to the platform. With the high likelihood that these new Macs will offer a full speed version of Virtual PC and (what I think is) the almost assurance that some clever hacker will make 'X for x86' run on commodity hardware, I'm doubting the willingness of most IT and development houses to even give the Carbon and Cocoa APIs a first glance. (If it wasn't for the poor past performance of VPC, I would not have gotten my first Mac programming job.) Can anybody with a more optimistic view think of a scenario where a modern development house will do Mac development in an age where the help desk will just say either 'switch boot to Windows/Linux' or 'run Virtual PC?'"
Apple is much more than just a processor. What really differentiates Apple from the Windows world is the OS. Not to get into the argument about stability, OS X is much more intuitive and overall an easier to use operating system.
I don't think that you will come into a situation where a help desk would tell a user to switch into Windows or run VirtualPC because I doubt that Macs will ever come with those pieces of software installed. Working at a helpdesk is not about telling users what they should do, it's about helping them do what they want to do
I think that now that Apple is switching to Intel they will have more flexibility in pricing and will probably continue to grow their market share. I'd say that the prospects for Mac developers will be better than ever in the future. If you need another opinion check out this article.
Those who know, do not speak. Those who speak, do not know. ~Lao Tzu
I think your view, while logical and understandable, is unnecessarily pessimistic.
The market has always viewed the Mac as another computer, one interchangeable with every other computer. While a Mac is (technology wise) a computer, the people who buy them view them very differently and the sheer dynamics of the Mac Economy (the customers, companies and products that hinge on the Mac platform) prove this out.
Take your fear of people figuring out how to run X on beige boxes... Apple doesn't care about these folks. Simply by having not purchased a Mac, this portion of the market has already proven that they are unwilling to have ever paid the Apple premium so, in effect, Apple will virtually never loose a sale to this crowd.
Or think of it this way; the kind of people who are drawn to the Mac platform are drawn to it PRECISELY because they don't want to fuck around with patches, workarounds and general hackery in order to make their computer run. Here is the test: could you imagine telling your mother to run out, buy a beige box, download some boot hack, install it, then install OS X on top of that? Probably not and that's exactly why Apple isn't going to be kept up at night worrying about the people who are going to hack OS X to run on commodity hardware.
If anything, I think this will bolster Mac sales- the kind of people who are willing to jump through the hoops to make OS X run on beige boxes are computer enthusiasts and typically serve as the computer information maven within their circle of friends. I think that if these hardcore Windows guys get OS X (for free) and play with it on their beige (or Tie Fighter) boxes, they are going to be pretty impressed. When it comes to telling people what computer to buy though, they will probably just recommend to their friends that they buy a Mac.
The same logic generally applies to your second point (will software developers still make Mac versions of their stuff). I think that the answer here is again, a big yes because there is a fairly substantial wall between people who will want to run native apps and people who want to run emulated apps. As someone with a Mac, I've proven (by voting with my dollars) that I am someone who will pay a premium to have an elegant computer that "Just Works." Any software developer with half a brain is going to realize that forcing the Mac customer to run clunky Windows emulation (even if it is at native speed) is inherently out of step with what that customer wants.
I think this is the perfect time to start developing Mac software. Porting over PC code is going to be easier then ever. The overall buy rate of Macs is going to be increasing significantly. A major chunk of risk in regards to the stability of the Mac platform has now been removed. Apple will be rocking the computer world within the next 24 months...
Well, I'm fairly sure OpenTransport has been gone for a while now, but to answer the question...
One, Mac users will still want Mac-native applications. Witness the lack of interest in X11 ports of Linux programs. These all work just fine, but look comparatively ugly. Same goes for Java apps.
Two, Cocoa and friends is a wonderful language / API set. The programs I have made under OS X have been actually fun to create and build. I, for one, will still program for OS X, regardless of what everyone else does, because I use OS X.
I think the problem facing people programming for OS X will be the same as it always has been, which is just getting enough user base to make the application financially viable for companies. That is up to the markets.
> its just ...too gui for me
Put Terminal in your dock and then click on it once in a while. Your problem will clear right up.
-- Mark
They who do not learn from history are destined to repeat it.
Yeah. After all, it did OS/2 a whole lot of good that it could run Windows 3.1 applications in protected memory space, and pre-emptively multitask them back in 1992.
Sorry, but you're failing to learn from history.
Back before Windows 95, OS/2 had a significantly better desktop environment than Microsoft Windows did. It ran Win16 applications, typically better than Windows itself did. I knew of a lot of Windows developers who did their development on OS/2 because of its better memory management, pre-emptive multitasking, and crash protection.
And what good did any of this do for OS/2? I remember personally contacting ISVs to talk to them about porting their popular software to OS/2, and the answer I always got was "why, when it runs our Windows software so well?". They didn't care one whit about the desktop environment, or the fact that their Win13 and Win32s applications looked bad on OS/2, and ran worse than native applications, didn't integrate into the desktop environment, couldn't use long filenames, etc. They cared only about one thing: how do we target the largest possible market at the lowest cost?
I don't see that much has changed within the industry. There are a lot of Windows-only ISVs out there who have no intention of putting any effort into making OS X applications, but who wouldn't mind increasing their userbase. And there are a lot of other ISVs out there who put minimal effort into OS X native applications, but who would love to do away with the additional staff and costs associated with that.
Fortunately for Apple, unline IBM they already have a significant development community using their APIs. Cocoa is an absolute joy to develop with. If anything, I would think that instead of having good Windows emulation, what Apple really needs to do is to port Xcode and Cocoa to Windows and Linux, and get developers on those platforms to write applications to their APIs, and allow existing Xcode developers create apps which will run on Windows and Linux. That is where the real battle is -- for the hearts and minds of developers. If you permit Windows to run on OS X as well as on native Windows, you concede the most important battle by telling developers that using the Windows APIs is just as good as using your own APIs.
That is the lesson IBM learned the hard way. They continued to make that mistake with their Open32 APIs, which mirrored the most common Win32 APIs in order to permit Win32 applications to be recompiled to run on OS/2. That didn't work out too well either.
That was introduced about 10 years ago. Do you want OS X in 10 years to be where OS/2 is today?
Yaz.
Apple has been developing builds of Mac OS X for Intel since day once. They obviously have the resources to handle both architectures at the same time. So they will be able to maintain builds for PowerPC as well as Intel for years to come but yes, they will eventually phase out PowerPC, yes.
If you've read about the keynote, or watched the video, you'll know that Apple will introduce the Intel line in 2006, and complete the transition of all Apple products to Intel in 2007. My guess is you'll have two years of OS X updates for PowerPC after that (about how long OS 9 was still maintained after OS X was introduced). Simple math says your PowerPC will probably be running Mac OS X 10.8 (Garfield?) in 2009 by the time PowerPC is EOL'd.
Of course, I don't know for sure. It's just speculation based on Apple's historical transitions. They're not going to leave you out in the cold.
Gabriel Ricard
Interestingly, the major improvements in Tiger, such as core video and so on, move all the graphically intensive stuff into the GPU. The cleverness of this is that the lack of the altivec units aren't such a big issue if you use the OS X core API's - everything is done in the graphics card, altivec is much less important, and this means that emulation of the PPC code will work fairly fast on their software emulator (rosetta). So your legacy code isn't going to suffer too much, and newer code even less so using the core API's even if you don't use fat binaries, which you will.
Apple's thinking bigger than that. It's not just about the graphics card or altivec, it's about providing abstracted system libraries for just about anything. If you write a program that uses the system libraries, Apple will ship an implementation that runs fast on a sufficiently advanced GPU, one that runs fast on AltiVec, one that runs fast on SSE3, one that runs fast on whatever the next step is. If you use this library, you get the benefits on all platforms.
Maybe this is a misconception, but I thought that at some point the ancient x86 instruction set and registers were "set aside" in favor of a more modern RISC-style processor core, and the old x86 stuff is supported as a kind of pass-through layer on top of that. I understand that's the case with AMD's Athlon, anyhow.
This has been correct for everything since the Pentium Pro. CISC is a bad way to do a CPU, and everyone knows it. You can think of the x86 layer as a sort of machine code compression that actually increases how much code you can keep in cache at one point. A byte of x86 goes a lot farther than a byte of PPC.
-twb