It occurred to me a while ago that had Apple released an updated version of Yellow Box for Windows, most of the effort would have been for nought.
The point is ObjectiveC 2.0 with garbage collection.
Any developer jumping on Yellow Box for Windows would have found that the entire platform changed again just two or so years after introduction. Perhaps that is why Apple didn't do it?
The advantages of Yellow Box for Windows are obvious. Few people bother to learn Cocoa if Mac OS (and the iPhone) is the only target. If Windows could be targeted, the argument for Cocoa would be much stronger.
As I see it memory management and non-portability are the two major show stoppers for Cocoa adoption among developers. Apple have started solving the first problem, maybe they are targeting the second as well?
At the moment I am looking into Cocoa# as a platform of choice, because it would allow me to develop an application in Visual Studio and, if I strictly follow a Model-View-Controller pattern, to port it to Cocoa easily by building a new GUI and replacing the controller class, i.e. making my own glue.
Cocoa# applications look and feel exactly like native Cocoa applications. And once Cocoa# becomes really usable I see no reason to use ObjectiveC instead.
REALbasic is doing fine precisely because it targets Windows and Mac OS (and Linux, but I have never seen such a program in the wild). Almost all other portable toolkits target C++ except GNUstep which also requires the developer to redo the GUI.
So what are the options for crossplatform development sans Yellow Box?
Cocoa -> GNUstep -> Linux/UNIX/Win32
REALbasic -> Carbon/Win32/Linux
C# and VB -> anything that runs a CLR
C# and VB -> Cocoa# -> Cocoa (including native GUI)
C++/QT -> Carbon/Win32/Linux/UNIX
C++/WxWidgets -> Carbon/Win32/Linux/UNIX
Java -> anything that runs a JVM
A Yellow Box for Windows would make a good case for Cocoa.
And I know the arguments about it being difficult for Apple to support all Cocoa APIs on both Mac OS and Windows and Spotlight etc..
But Apple would not have to support all APIs. The documentation for each class could simply tell us if it is supported in both versions of Cocoa (or rather all three, given that the iPhone is quite different too).
The developer could develop a base application using only supported APIs and then modify a specific Mac and specific Windows version in the same way QT or REALbasic development are done.
I miss Yellow Box for Windows and I have never used it.
But it's such a visible hole.
The point is ObjectiveC 2.0 with garbage collection.
Any developer jumping on Yellow Box for Windows would have found that the entire platform changed again just two or so years after introduction. Perhaps that is why Apple didn't do it?
The advantages of Yellow Box for Windows are obvious. Few people bother to learn Cocoa if Mac OS (and the iPhone) is the only target. If Windows could be targeted, the argument for Cocoa would be much stronger.
As I see it memory management and non-portability are the two major show stoppers for Cocoa adoption among developers. Apple have started solving the first problem, maybe they are targeting the second as well?
At the moment I am looking into Cocoa# as a platform of choice, because it would allow me to develop an application in Visual Studio and, if I strictly follow a Model-View-Controller pattern, to port it to Cocoa easily by building a new GUI and replacing the controller class, i.e. making my own glue.
Cocoa# applications look and feel exactly like native Cocoa applications. And once Cocoa# becomes really usable I see no reason to use ObjectiveC instead.
REALbasic is doing fine precisely because it targets Windows and Mac OS (and Linux, but I have never seen such a program in the wild). Almost all other portable toolkits target C++ except GNUstep which also requires the developer to redo the GUI.
So what are the options for crossplatform development sans Yellow Box?
Cocoa -> GNUstep -> Linux/UNIX/Win32
REALbasic -> Carbon/Win32/Linux
C# and VB -> anything that runs a CLR
C# and VB -> Cocoa# -> Cocoa (including native GUI)
C++/QT -> Carbon/Win32/Linux/UNIX
C++/WxWidgets -> Carbon/Win32/Linux/UNIX
Java -> anything that runs a JVM
A Yellow Box for Windows would make a good case for Cocoa.
And I know the arguments about it being difficult for Apple to support all Cocoa APIs on both Mac OS and Windows and Spotlight etc..
But Apple would not have to support all APIs. The documentation for each class could simply tell us if it is supported in both versions of Cocoa (or rather all three, given that the iPhone is quite different too).
The developer could develop a base application using only supported APIs and then modify a specific Mac and specific Windows version in the same way QT or REALbasic development are done.
I miss Yellow Box for Windows and I have never used it.
But it's such a visible hole.