<p>When do you recommend integrating a custom view into Interface Builder with a plug-in? When skimming through Apple's <a href="http://developer.apple.com/documentation/DeveloperTools/Conceptual/IBPlugInGuide/CreatingPluginBundle/chapter_2_section_3.html#//apple_ref/doc/uid/TP40004323-CH4-DontLinkElementID_15" rel="noreferrer" title="Interface Builder Plug-In Programming Guide">Interface Builder Plug-In Programming Guide</a> I found:</p>
<blockquote>
<ul>
<li>Are your custom objects going to be used by only one application?</li>
<li>Do your custom objects rely on state information found only in your application?</li>
<li>Would it be problematic to encapsulate your custom views in a standalone library or framework?</li>
</ul>
<p>If you answered yes to any of the preceding questions, your objects may not be good candidates for a plug-in.</p>
</blockquote>
<p>That answers some of my questions, but I would still like your thoughts on when it's a good idea. What are the benefits and how big of a time investment is it?</p>

[{'answer_id': 50835, 'author': 'Andrew Grant', 'author_id': 1043, 'author_profile': 'https://Stackoverflow.com/users/1043', 'pm_score': 2, 'selected': False, 'text': "<p>I think the Apple guidelines sum it up nicely.</p>\n\n<p>If you're writing a control that will be used in multiple applications and is completely generic, then creating a custom object is a good idea. You'll be able to visualize the look and set properties directly from Interface Builder.</p>\n\n<p>If your control is limited to one application, or is tightly coupled with your data, then moving it into a custom object really won't buy you much.</p>\n\n<p>It's not difficult to create a custom view, there are a lot of easy to follow guides out there.</p>\n"}, {'answer_id': 89185, 'author': 'Chris Hanson', 'author_id': 714, 'author_profile': 'https://Stackoverflow.com/users/714', 'pm_score': 4, 'selected': True, 'text': "<p>It's perfectly reasonable to push the view and controller classes that your application uses out into a separate framework — embedded in your application wrapper — for which you also produce an Interface Builder plug-in.</p>\n\n<p>Among other reasons, classes that are commonly used in your application can then be configured at their point of use in Interface Builder, rather than in scattered <code>-awakeFromNib</code> implementations.  It's also the only way you can have your objects expose bindings that can be set up in Interface Builder.</p>\n\n<p>It's a bit of coding, but for view and controller classes that are used in more than one place, and which require additional set-up before they're actually used, you'll probably save a bunch of time overall.  And your experience developing with your own controller and view classes will be like developing with Cocoa's.</p>\n"}]
['https://Stackoverflow.com/questions/49442', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/5156/']