Re: How does Apple want us to deal with custom elements in Xcode 4, with IBPlugins having been killed?
Re: How does Apple want us to deal with custom elements in Xcode 4, with IBPlugins having been killed?
- Subject: Re: How does Apple want us to deal with custom elements in Xcode 4, with IBPlugins having been killed?
- From: Kyle Sluder <email@hidden>
- Date: Mon, 15 Aug 2011 20:46:51 -0700
On Mon, Aug 15, 2011 at 7:40 PM, Joar Wingfors <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden