PaintCode - Vector Based Obj-C Graphics Code Generator
paintcodeapp.com
paintcodeapp.com
(I have a couple Mac Cocoa apps I'm working on that I kinda sidelined because UI controls were painful).
1) You need to design the selected/deselected states for buttons separately and merge the code.
2) It'll give you drawing code, but you have to maintain those chunks of code directly in your source files. Any modifications you make to the code need to be reflected in the original PaintCode data, and vice-versa. This could be solved with clever comment guards and the ability to rebuild internal structure from the code it generated.
Neither of these really detract from the product. I've only used the demo, but it's honestly pretty amazing.
Having recently ripped out most of my -drawRect: methods, replacing them with custom rendered UIImages, I can attest to the significant performance gains that UIImage gives you. On the Retina iPad, I think it's pretty much mandatory.
With that in mind, I think most people are better off using a tool like this to produce PDF data rather than raw CG calls, and use generic code to render that PDF data to a UIImage. PDF data produced by Quartz is going to render exactly the same as raw CG calls.
It makes for easier project management, and much better performance.
Of course, if you don't need resolution independent graphics, just use png.
Quick question: How does UIImage's -drawInRect: and -drawAtPoint: differ?[1]
With that in mind, I think most people are better off using a tool like this to produce PDF data rather than raw CG calls, and use generic code to render that PDF data to a UIImage
The CGPDFPage* functions that Apple provides are document-oriented (remember: the D in PDF stands for "document"), and don't necessarily work well in all cases, either. A compromise could be to render your CG calls into a context that is then turned into a UIImage that gets cached and stuck into a UIImageView for display. This way, you can do your drawing in CG*, get GPU-backed rendering, and don't have to deal with clumsy PDFs to get images.
So, my advice? Click the "buy" button. Drawing in code is just another tool to have. No reason to avoid doing so, if the situation calls for it -- and the trick to any tool is knowing when to use it.
1. If you guessed that -drawInRect is CPU-backed and drawAtPoint: is GPU-backed, pat yourself on the back. Simply having your resources in a UIImage isn't enough to guarantee GPU-backed drawing. And drawing on the GPU isn't enough to guarantee that it will be fast.
That said, Opacity's development has slowed to a crawl. If the gentleperson(s) behind PaintCode keep it up, they will surely surpass it very soon.
I've worked on a few apps where I need to pre-render some high-quality images and include them in the app bundle. In some cases they are relatively difficult to hand-draw in an image editor (at least the sort of image editors I can afford) and I've had to write a Mac app to draw the image. Basically the sort of thing that a CAD program would be good at.
So I'd love to have something that I can script in a relatively high-level language that renders really sharp antialiased graphics at 2x resolution with control over things like end caps.
That aside, the ease of prototyping makes development that much faster.
So you're hardcoding either way.
Additionally, paintcode has the flexibility of making say, a button that shrinks/grows based on the shape of another view, say, as is caused when you rotate an ipad, etc.
I've been very happy with the product so far.
I can certainly see where having easy programmatic access to the primitives that make up a vector drawing would be useful though.