Vector based UI design tool that generates ObjC

[aggarwalachal]

PaintCode is a simple vector drawing app that instantly generates resolution-independent Objective-C drawing code for both Mac OS X and iOS.

You no longer have to tweak and recompile your drawing code over and over again to achieve the desired result.

[basil]

Really cool. This reminds me of Bret Victor's talk where he stresses the importance of seeing the effect of your code immediately (http://vimeo.com/36579366).

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 (http://www.youtube.com/watch?v=JupqhcT4ONY) which popped up in my Twitter stream a couple days ago.

[aggarwalachal]

What Bret Victor showed in his talk was quite amazing. It really opens up one's mind to what all is possible and what can be changed.

The Core Graphics video is interesting. Live rendering like that can help developers see what they are actually coding. The whole compile and test cycle just breaks the chain of thought which goes on while coding.

[coob]

I love the execution of this app, but I disagree with the underlying idea for most cases.

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.

[tezza]

Not sure I can agree with you. I think vector drawing can be better in both size and drawing speed.

It depends a lot on the representation. Bitmap will not get a lot better than what we've got at the moment with JPeg or Gif. Vector representations can vary wildly in compactness and rendering speed. Eg. SVG bad, CSS gradients good. SVG bad, EPS/PDF good.

Obviously drawing from CPU can be much quicker than reading from disk. And if you draw into the GPU buffer first you get all of the advantages of GPU acceleration later.

And it can be much more bandwidth efficient.

Take streaming a bitmap over http. You have to take the penalty of the PNG header, the penalty of assembling a data:url and a 33% fixed penalty for Base64 encoding the binary bits.

So to stream a 1x256px gradient sprite there is a shedload of wasted bits.

If you're in vector land you can just send the gradient endpoints.

If you're not in WebKit land or with pre-sent vector algorithms (rare) you also have to stream the vector drawing code. In that case you can ammortize the cost of the drawing code with a simpler/smaller wire representation.

[eaten_by_a_grue]

Using something like the Apple-provided CGLayer, you can draw the image once, then use it like a bitmap while it is in memory, AND they can keep it cached on the graphics card. These guys could easily produce code that does that.

Reference: https://developer.apple.com/library/mac/#documentation/graph... (it works on iOS too)

[gdubs]

What about localization? That combined with what others have mentioned below adds up to a lot of imagery.

There's also no reason you can't build your images the first time they're used, and save them out to PNG files for successive uses (if profiling determines that it is indeed more optimal). Even if you end up using graphics at runtime, you'll save work by using code to generate your graphics.

For instance, simply write utility programs to generate all of your graphics with code -- this is definitely faster than photoshop when you have buttons in lots of different languages. It's also useful if you want to use a font where it's not legal to embed it. (You can generate all of your button imagery using code and localization files, then remove the embedded fonts and use the generated PNG files in the release version.)

[saurik]

This isn't about performance: it is about resolution independence.

[pornel]

iOS devices can render Infinity Blade smoothly. I don't think few shapes (probably automatically cached as a bitmap) are going to be an issue.

And I don't get why Apple bothers with CgBi PNGs, since endian swap on ARM is a single cycle instruction, and it's probably free anyway while moving the bitmap to the GPU memory.

[phil]

Without benchmarks, that's kind of a pointless assertion. I'd guess that both methods are close in performance most of the time but don't really know.

Anyway sometimes you need drawing code -- it's much more animatable, for example.

[angerman]

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.

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.

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.

For interactive views (drag, move, ...), where redrawing is necessary, this could be a valuable tool -- if it can do that.

[gdubs]

When a uiview renders, it does so to a layer. Calayer caches its bitmap content. So, moving something on screen doesn't require redrawing. Most implicitly animated properties (opacity, transforms, etc) won't require a redraw. As mentioned below, it's fairly trivial to save a context to a png file if you must.

[irrationalfab]

You have the option to save a Core Graphics generated UIImage to NSCache or even to the temp folder.

[betageek]

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.

[tvon]

Not via the App Store, but there is nothing preventing them from doing this via a direct download on their website.

[revorad]

It's how Apple has commoditized mobile apps and is now trying the same on the desktop.

[jaimzob]

Seems very cool, but as far as I can tell there's no trial version? $80 seems a bit much to lay out before you even find out if the thing works.

[aggarwalachal]

True. A trial version would be very nice.

One thing I would like to see is being able to export these vector graphics to other formats.

[aggarwalachal]

You no longer have to tweak and recompile the drawing code...

Edit

PaintCode is a simple vector drawing app that instantly generates resolution-independent Objective-C drawing code for both Mac OS X and iOS.

You no longer have to tweak and recompile your drawing code over and over again to achieve the desired result.

[benbjohnson]

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.

Here's a short 5 minute walkthrough in designing the Mail app in Mockdown:

http://vimeo.com/23869680

[supar]

WMF anyone?

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.

Generating static ObjC seems like a dumb idea except in very specific cases.

[thought_alarm]

PDF is actually serialized CG graphic calls. This app should produce PDF files rather than raw CG graphics code. Of course, there are lots of apps that can produce PDF.

[michaelw]

Well.... WMF was a great example of the difference between theory and practice. Not really resolution or even device independent.

[aggarwalachal]

Craig Hockenberry (http://twitter.com/chockenberry) - Got an email from PaintCode's support: a demo and tutorials are coming. Replied with some friendly advice about releasing products…

[unjinxable]

This, while cool, just seems like the wrong way to go about things. I like this solution or something like it: https://github.com/mindbrix/UIImage-PDF

[aggarwalachal]

Updates:

Just got an email from their team

Trial version of PaintCode

You can now download a limited trial version of PaintCode at http://paintcodeapp.com/trial.html

Video guides

We've prepared 4 short video guides demonstrating PaintCode in action. These guides show various basic drawing techniques at: http://paintcodeapp.com/examples.html

Examples

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.

[feralchimp]

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. :)

[eduardordm]

I bought the app and just came by to drop my 2 cents.

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.

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.

The ugly: The price is not aligned with apps at the same level of complexity.

Buy it.

[Flow]

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.

Non-native UI controls everywhere. :-/

[seanalltogether]

I agree, the sample controls shown in the screenshots look very windows-y

[kranner]

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?

[joelhaasnoot]

Code generation seems to be the selling point. I've never seen wel executed GUI code generation however on any platform. Windows Forms was especially awful...

[286c8cb04bda]

It looks like to biggest extra is the ability to insert variables into the generated, so you can make e.g. a blue and orange button from the the same output.

[vdm]

Think 'Save As NSView Code' for Illustrator.

[sarbogast]

What would also be great would be a way to import Illustrator files. Because I don't see how designers will prefer to work in that environment.

[febeling]

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.

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.

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.

I don't see why such a feature could not be added to this app.

Amazing application.

[dchest]

Sometimes ideas are just floating around, aren't they?

I think Opacity [1] was the first program with this feature (added in 2009 [2]).

1. http://likethought.com/opacity/

2. http://daringfireball.net/linked/2009/09/22/opacity

[seclorum]

I'm already doing all this with python scripts for Inkscape - draw the entire UI in Inkscape, name things in the DOM appropriately, run a few scripts -> MOAI code (Lua) or C Code (SDL_svg).

Haven't quite got it ready for launch yet, but rest assured the idea is not new. There have been Inkscape exporter tools for this sort of thing for years, you just have to know where to look (inkexport, &etc.)

PaintCode sure is pretty, though.

[kenrikm]

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.

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?

[cwbrandsma]

On the Apple developer web site you can watch the WWDC videos, there is one on graphics and animation that talks about just that.

Conventional wisdom, especially for small images, it is much more efficient to draw them with Core Graphics than use a image, more so if there is transparency in the image.

This will even be true for non-ios systems. Microsoft has said for years, that generating a 16x16 image is faster than getting it from disk (depending on complexity and disk speeds).

Plus, code does tend to be more compact (again, within reason), so it is less that has to be loaded when your application starts.

[randomdata]

> you would be set for any future resolution increases.

Only if you're willing to release an update. There's something to be said about having it already ready for any future resolutions, now.

[chj]

I hope this idea is not patented, because I am developing a similar app.

[nupark2]

Prior art (also mentioned elsewhere in the comments): http://likethought.com/opacity/

[nudded]

Ideas can't be patented.

[aggarwalachal]

How far are you? Would we be able to test it out before release?

[chriseidhof]

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.