Our staff is making progress on tables, and also starting work on the layout view. It replaces the Custom Layouts command that sets up data entry screens, printed forms and reports in the current version of Goldenseal accounting software. The layout view is essentially a drawing program. It has a tool palette, and graphic objects that you can click on and drag to new locations. We use it to set up most of the appearance in our estimating and accounting software. It also allows users to change things.
Apple has sample code for a simple drawing app, which makes our life easier. But not that much easier, since the sample was written in 1998, and its code is very outdated. It’s a helpful start, but we end up rewriting most of it.
The Objective-C language that Apple uses for Cocoa is even older. Both Objective-C and C++ evolved in the early ’80s as enhancements to the venerable C language (origins mid ’70s). However, C++ has been updated frequently since then, while Objective-C has lagged. Almost nobody uses it except for Apple.
The little boxes that you drag around in the layout view are a perfect example of how difficult it is to migrate a large app like ours from C++ to Cocoa. In our existing code, each box is a C++ object. The object responds to mouse clicks, updates the screen display, and stores its new position when you stop dragging it. When you save, it writes changes to the database. The code is not trivial, but it’s all in one place. For the new Windows version, we can still use the current code with only minor changes.
The 64-bit Mac version still needs that C++ object to read and write data. It also needs a “linker” object (written in a hybrid language called Objective-C++). The linker connects with an Objective-C object which knows how layouts work, and that in turn contains a Cocoa control object that responds to mouse clicks and draws on the screen. Four classes instead of one. To make things work, we either have to pass messages back and forth through 3 layers, or write it from scratch in Cocoa.
This is a general problem that all software developers must face. Objective-C is not bad for small apps, but for a large app like ours it would be horrendous. Objective-C is creaky and cranky and decrepit. Then, the end result would be code that only runs on Apple hardware. It would require a complete rewrite for Windows, with two code bases to manage. Mixing C++ and Objective-C is possible, but challenging. We are doing that now, but it pretty much added a year to the development time for Goldenseal Pro.
Most big companies like Microsoft and Adobe only converted their Mac apps to Cocoa in the past few years. That’s very slow, considering that Mac OS X and Cocoa first appeared in 2001. Apple’s apps are written almost entirely in Cocoa, but they’ve had the benefit of adding Cocoa classes that specifically suit their own needs. Apple pretty much programmed their apps with a lot of C language code, and just a little Objective-C.
The new Swift language may some day make Mac programming easier, but it’s still immature. It also does not connect with C++ at all. Developers either need to write in pure Swift, or have two linkers (one from C++ to Objective-C, then another from Objective-C to Swift). It’s doable, but not fun.
Even more worrying, the usage rate for both Apple languages has been dropping, rather than expanding. Swift’s percentage in the TIOBE index declined from 2.1% to 1.8% over the past year, while Obj-C fell from 1.5% to 1.1%. That compares to 15% for Java, 11.9% for C, and 5.7% for C++. Programmers really don’t like either Apple language. Meanwhile, C and C++ are growing.
This coming Fall, the newest Mac OS 10.14 will start to give a warning when you run older 32-bit apps written with the C++ Carbon library. In the Fall 2019 release, Mac OS 10.15 will not run them at all. That change will affect the current Goldenseal software, but not Goldenseal Pro. Right now it’s looking pretty good for getting the Pro update out before this September.
Many good apps disappeared during the conversion from OS 9 to OS X in the early 2000s, and many more vanished after the conversion from PPC to Intel in the late 2000s. Most likely, in a couple years there will be similar carnage.
We actually find this bad news to be rather cheering. TurtleSoft has already outlasted many competitors, and having to slog through (metaphorical) knee-deep mud means a few more will be left behind. Already, QuickBooks for Mac desktop is officially doomed after May 2019. It will be interesting to see if AccountEdge (currently 32-bit) can make the switch. They may be surprised at how hard it is. Chances are good that there will be a lot more room for other accounting programs such as ours.
We keep that in mind, every time that Cocoa programming goes #%@⊗!# or %!$♣~#(øΣ or &U+1F4A9;. Fortunately, we are still ascending the learning curve, and it keeps getting easier.
Dennis Kolva
Programming Director
TurtleSoft.com
.
