On Mon, Aug 15, 2011 at 7:40 PM, Joar Wingfors <j...@joar.com> wrote: > That aside, here are my 2 cents on this topic: I don't think that there's a > lot of value to adding IB plugins for your own custom controls (not that you > can right now, but even if you could). It makes sense for framework > developers to provide support for their controls in IB (since they provide > things that will be used by a lot of other developers), but I don't think > that the investment pays off for regular app developers (where custom UI will > typically only be used in one / a few nib files).
I suppose our company is large enough to somewhat fits the "framework" pattern, but one of our engineers recently implemented a substantial suite of Cocoa control subclasses that mimicked or followed the Lion style, so that our apps look consistent and at home on both Snow Leopard and Lion. He also implemented an IB plugin for these controls so that our User Experience design team would be able to lay out interfaces in IB rather than just OmniGraffle and Photoshop, and so our Localization team could integrate changes from our localizers while ensuring that metrics still lined up. We are back to bothering engineers in order to get turnaround on some of these aspects of our applications. Is it an insurmountable burden? No. But we saw an opportunity to improve our workflow and our products by giving more power to our UX and Localizations folks, and had to scrap it at the last minute when Xcode 4 was released. And I can imagine there are plenty of iOS job shops out there that would LOVE to have IB plugins to expedite their client work. If they can invest the effort in making a neat, flexible widget once, and use IB to quickly turn around iterations to their customers, the quality of App Store software goes up. Because let's face it, you don't get to half a million apps if everyone follows the desktop development model. And even the smallest developers wind up writing their own custom libraries that they use in every app. The point Charles makes about garbage collection is a very valid one. Writing dual-mode code sucks so much that Apple invented ARC. And I'm sure that the Xcode 4 team had perfectly valid reasons for omitting IB plugins from their ground-up rewrite of the IDE, even if garbage collection wasn't among them. But I do hope that the Xcode team reconsiders its abandonment of this technology, especially now that IB is an even more integral and easy-to-use component of the developer tools, and the underlying technologies have changed to make supporting the same code in design mode and at runtime far easier. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
