TurtleSoft has shipped software built with 3 different programming tools: Excel, HyperCard and CodeWarrior C++/PowerPlant. We started but abandoned projects using 4 others: FileMaker, Omnis, Serius Developer and Think Pascal/C++/TCL. There were another 6 app-development tools that we bought and poked at for a while, but decided not to use. Cocoa's status is still pending.
I've been thinking about what it was that made some platforms work well, and some not. Rather than anything specific, it pretty much came down to productivity. With some tools, we chugged along steadily and eventually shipped software. The rest bogged down for one reason or another. When a product release started looking too far off, it was time to bail. Programming seems like one of those things that works best in a state of "flow". Get totally focused and immersed. In the groove. It's possible to get a lot done in that state. One phone call can kill it. So can getting stuck on a problem. If you have to wander too far looking for a solution, your concentration shifts elsewhere and it can be hard to go back. In the 3 years moving from Carbon to Cocoa, we got stuck many, many times. Surprisingly, it wasn't just a learning curve. The frustrations were remarkably constant. It may even have grown harder with time, rather than easier. I'd estimate that our time with Cocoa was about 25% highly-productive flow state. Looking back, Excel macro programming was about the same, but spreadsheet setup was much faster. HyperTalk and C++ ran about 90% high-productivity. Here's where we stumbled the most with Cocoa: 1. Documentation. Class and method naming is usually quite reasonable in Cocoa. But when something was confusing, online docs rarely helped. Too often, they either stated the obvious, or linked to lengthy theoretical background. To stay productive, what we really needed was usage examples, code snippets, warnings about pitfalls. Sometimes deep knowledge is worthwhile, but sometimes you just need a bit of code to copy/paste. 2. Example projects. Apple has a good selection, but most for Mac are outdated and useless. Many don't even run. Some show features that are nifty, but deprecated. Anything recent is Swift-only, and usually iOS rather than Mac. Sample code from blogs has the same problems. Cocoa is complex enough that it really helps to run working examples. Jump-starting with existing code saves days or weeks, and keeps the workflow going. 3. Nibs. The graphic "GUI builder" environment is a great idea in theory, but overly complex in practice. Too many minor settings with unexpected consequences. Too hard to debug problems caused by small errors. Constraints were a constant hassle. Woe to anyone needing to add a new item in the middle. I suspect that nibs and storyboards are supposed to let non-programmers create an entire app without writing code. Two of the tools we abandoned (Serius and Prograph) had a similar goal, and both were disasters. Text is easier to read. Easier to comment and debug. 4. Memory management. I complained about this previously. ARC sounds great in theory, but it's too complicated in practice. Our C++ code rarely crashes. It had just one small memory leak, hidden somewhere in PowerPlant's LWindow (now removed). In contrast, we wasted too much time on mystery deallocs in Cocoa classes. There are too many subtle ways to create leaks. 5. Missing features. Cocoa includes all the basics and more, but there were small deficiencies which made it more difficult. The first one that bit us was NSComboBox not having a way to restrict choices to existing items only. Apple's docs mentioned that it was possible, but we never found a way to make it work, despite help from this list. Multiply that by 100. I get the sense that most Cocoa features were created to run Safari, Finder, Preview or some other Apple product. Not enough focus on the needs of folks who develop other types of apps. 6. Changes too rapid. The assumption seems to be that Mac and iOS developers should rewrite code frequently. That alone is more than some of us can afford, but the pace of change also made problem-solving more difficult. It was the root cause of problems #1 and #2. There is a whole ecosystem of bloggers and Stack Overflow contributors who provide free support for iOS and macOS, but they can't keep up. As a result, most online help is outdated and unreliable. BTW Microsoft seems to err in the opposite direction. They rarely toss anything, so their dev tools are a confusing mess of options and duplications. Surely there is a sweet spot somewhere in the middle? 7. MVC needs a more cooperative C layer. Right now the Cocoa controller classes work fine with outside model code, but they don't coordinate well with an outside controller. I think the key might be to have deeper access to event handling within NSWindowController and NSViewController, but that's just a guess. It would take some experimenting to figure how best to connect Cocoa and C++ controllers. Linking the C's is particularly important for cross-platform work, because Microsoft uses MV rather than MVC. They have an MVC add-on for ASP.net, but not for MFC, and apparently not for their other frameworks. Please correct me if I'm wrong on that. Developing for Windows means writing your own controllers, and it would really help if they didn't need a rewrite for Mac. This may also apply if coming from PowerPlant or Carbon. In general, Cocoa seems well-designed, with many extremely useful classes. I think it's better than anything from Microsoft. More powerful than PowerPlant. But there were enough impediments that it became a long, painful slog that never improved. Not enough time spent on productive programming. Is there a way to fix this stuff? Changing Cocoa online docs into an Apple-curated wiki might help with #1. Then people actually using Cocoa can share their experience. Add code snippets, warn about the quirks and gotchas. Like this list does, but more targeted and accessible. For the rest, Apple really needs to listen to developers more. These days, Cocoa is pretty much the only tool that creates native software for Apple hardware. It ought to be more developer-friendly. That's why this wheel is squeaking. We hope to be back on Cocoa in a year or two, and hope it will be easier by then. Casey McDermott TurtleSoft.com _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
