On Aug 16, 2011, at 5:46 AM, Kyle Sluder wrote: > 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. I'm pretty much in the same boat.
I was right in the process of writing my own optimized BGHUDAppKit-like theming framework. Why? Because Apple refuses to give us access to their HUD controls. (a rather common pattern at Apple unfortunately) Or how about Apple's Safari/Xcode tabs? There's a reason why IBPlugin frameworks such as PSMTabBarControl exist(ed). It's (usually) not about doing silly custom controls, but about filling a gap that Apple is refusing to fill themselves. My theming framework was meant to be the base of a rather big app project of mine. Luckily I hadn't started yet when Xcode 4 got released. But even for single (or very few) custom controls it's sometimes worth making an IBPlugin. I for one had a plugin & framework which contained a movie trimming control (as seen in SL's Quicktime). It was used in only one place yet. But what the plugin also contained and what made it really worth it was a GradientView class and a GradientEditorView class, which I wrote only for IB live editing of said GradientView. This GradientView allowed me to create a totally customizable gradient backed view for list views of all sorts without the need of a single line of code. I'd been using it in pretty much every (4+) non-trivial project (and all over the place in there) of mine (of which none are released yet, unfortunately). Again, it's the lack of a generic gradient view that's forcing me to use an IBPlugin. > 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. I couldn't agree more. The iOS App Store has become a stinking pile of UI junk. If Apple provided proper (and guided by the API) customization capabilities in the first place (as done with iOS' UIAppearance, eventually) or would provide experienced UI designers/devs means for providing affordable (and well designed) custom UIKits, the quality would rise quickly. The current state of iOS third party app user interfaces and app icons is hideous to say the least. > And even the smallest developers wind up writing their own custom > libraries that they use in every app. This. See comment above on my gradient view. > 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. If IBPlugins really are incompatible with Xcode 4 (O_รด), then why is Xcode 4 still/again using them? - /Developer/Platforms/MacOSX.platform/Developer/Library/Interface Builder/Plug-ins/CocoaPlugin.ibplugin - /Developer/Library/Frameworks/InterfaceBuilderKit.framework/Versions/A/Headers/IBPlugin.h_______________________________________________ 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
