PaintCode is a simple vector drawing app that instantly generates resolution-independent Objective-C drawing code for both Mac OS X and iOS.<p>You no longer have to tweak and recompile your drawing code over and over again to achieve the desired result.
Really cool. This reminds me of Bret Victor's talk where he stresses the importance of seeing the effect of your code immediately (<a href="http://vimeo.com/36579366" rel="nofollow">http://vimeo.com/36579366</a>).<p>It's not clear from the description but it would be great if it could immediately render whatever Core Graphics code I was writing, as I was writing it, much like this in-development tool (<a href="http://www.youtube.com/watch?v=JupqhcT4ONY" rel="nofollow">http://www.youtube.com/watch?v=JupqhcT4ONY</a>) which popped up in my Twitter stream a couple days ago.
I love the execution of this app, but I disagree with the underlying idea for most cases.<p>Drawing your UI is never ever going to be as cheap as loading a converted PNG (which Apple's modified pngcrush converts for you). I think a lot of devs have the draw/vector vs. precomposed bitmap tradeoff the wrong way round.
Drawing all of your gradated UIButtons with CoreGraphics methods is a false economy compared to just loading a stretchable PNG. Almost all of Apple's UI system imagery is bitmap based, and for a good reason.
So basically we stop using graphics and start using code (UIViews) to draw the images.
Does it do caching? A quick search for cache didn't turn up anything. If we have learned anything from using UITableViews with custom UITableViewCells then it is that drawing is expensive.<p>The underlying idea of generating your images "programmatically" is not a bad one to start but performance wise, if the image (View) is going to be static, rendering into a bitmap and using that subsequently is the more performant solution.<p>Maybe the tool we are looking for is not one that generates UIViews but let's us just get the images correctly name and at the right resolutions with a click? Like automatic slicing and exporting at predefined resolutions with predefined naming schemes. I just think this would better be done off the device.<p>For interactive views (drag, move, ...), where redrawing is necessary, this could be a valuable tool -- if it can do that.
This highlights one of the main problems with selling dev tools on the App store - it looks amazing but there's no way I'm shelling out $80 without trying it first.
You no longer have to tweak and recompile the drawing code...<p><i>Edit</i><p>PaintCode is a simple vector drawing app that instantly generates resolution-independent Objective-C drawing code for both Mac OS X and iOS.<p>You no longer have to tweak and recompile your drawing code over and over again to achieve the desired result.
I made an open source project last year called Mockdown that does the opposite of PaintCode. It takes declarative design code and converts it to PNGs so they can be used in iOS apps. The original idea was to do mockups but it actually turned out to be more interesting as an open source design tool.<p>Here's a short 5 minute walkthrough in designing the Mail app in Mockdown:<p><a href="http://vimeo.com/23869680" rel="nofollow">http://vimeo.com/23869680</a>
WMF anyone?<p>Windows MetaFile contain(ed) serialized GDI graphic calls to generate the picture in a resolution independent way, while still working as a vector file format that other application could parse.<p>Generating static ObjC seems like a dumb idea except in very specific cases.
Craig Hockenberry (<a href="http://twitter.com/chockenberry" rel="nofollow">http://twitter.com/chockenberry</a>) - Got an email from PaintCode's support: a demo and tutorials are coming. Replied with some friendly advice about releasing products…
This, while cool, just seems like the wrong way to go about things. I like this solution or something like it: <a href="https://github.com/mindbrix/UIImage-PDF" rel="nofollow">https://github.com/mindbrix/UIImage-PDF</a>
Updates:<p>Just got an email from their team<p>Trial version of PaintCode<p>You can now download a limited trial version of PaintCode at <a href="http://paintcodeapp.com/trial.html" rel="nofollow">http://paintcodeapp.com/trial.html</a><p>Video guides<p>We've prepared 4 short video guides demonstrating PaintCode in action.
These guides show various basic drawing techniques at: <a href="http://paintcodeapp.com/examples.html" rel="nofollow">http://paintcodeapp.com/examples.html</a><p>Examples<p>You can also find examples of PaintCode documents at the same page.
Some of the examples include simple Xcode projects.
These projects utilize the drawing code generated by PaintCode.
Seems like a nice tool at a high-but-fair price point. I look forward to seeing some deeper reviews, because the Illustrator trial I used to design my app icon expired a long, long time ago. :)
I bought the app and just came by to drop my 2 cents.<p>The good:
It's great. I've been looking for something like that for a while. I wish XCode could do that. If you are a serious iOS developer you will love this tool. Very useful.<p>The bad:
Some of the code cannot be easily used, specially if you need to manipulate positions in runtime. It should use relative positions, where 0 is "somewhere" within the object. The code generated may cause some UIViews to blur, sometimes you need to round x/y.<p>The ugly:
The price is not aligned with apps at the same level of complexity.<p>Buy it.
The idea is cool, but I must say the app itself gives me the same feeling I get from Microsofts Expression Blend app. Or any Silverlight app for that matter.<p>Non-native UI controls everywhere. :-/
Other than dynamically-related colors, is this much different from designing in Illustrator and exporting to PDF, which I understand is well-supported in iOS and OS X?
Sometimes ideas are just floating around, aren't they? I was thinking of very similar things lately as well. Obviously this application must be under development for quite a while already.<p>One thing that I'm not totally sold on it that fact that it generates code though. It is not going to be the running application which you interactively tweak. Because that is what Bret was showing in his talk. And that is also what you would be doing in Smalltalk. I'm not sure this is as 'immediately connective' (to use a variant of Bret's language) as it seems.<p>Another approach to go about this would be to store the 'drawing' in a data structure and have a special view that takes it and puts it into an image (or on screen immediately). That would also open possibilities for caching, something that likely would be make sense, as other commenters have mentioned as well. Such an approach would come dangerously close to implementing/reinventing SVG, though. Another benefit of such a data structure would be that it could have some simple, textual representation. JSON maybe? Even XML would do. And that would greatly help with version control and diffing.<p>I don't see why such a feature could not be added to this app.<p>Amazing application.
You could just create you assets in Illustrator/Vector and you would be set for any future resolution increases. However the PNGs would still increase your bundle size.<p>What I'm curious about, maybe someone here has the answer is if there would be a significant performance gain from using Core Graphics over just loading a PNG?
This is awesome. I've been waiting for this, and it was on my list of projects to build. However, it looks like the execution is really well done. I would love to see a trial version though.