Hacker News Reader

Comment by bsaul | Hacker News Reader

How far are you planning to go in your support for css properties ? css animations/transitions ? Positionning (top, left, right) ? There are a lot of similarities, but by going very far you may end up rewriting a lot of the storyboard xml in a css format... Then maybe later on, you'll want a WYSIWYG css editor on top of it, and i'm a bit wondering whether you won't have ended up rewriting absolutely everything.

From my personal opinion, CSS is nice the first 10 minutes, or whenever you only have a few element to style, but styling a complete app along with animations between states makes you really want to stay away from it as far as possible for mobile apps (and especially ios where resolutions are quite standard)...

View on HN

I'm with you about CSS. It seems the target market of this app is geared towards Web->iOS devs, but that seems like a smaller slice than something like "Bootstrap for iOS" should be made to do. Bootstrap is great because it makes web development so much easier through native uses. It doesn't add another language paradigm to make web development easier - it does it inherently.

1) If you're gonna' call it "Bootstrap for iOS", have the analogy end there. The site is way, way, way too much like Bootstrap already. Brand it better.

2) Good native code should be inherent! Nobody should have to learn CSS to make better iOS apps! A beginner should have a framework for her/him that allows something easy like [view fadeIn] and it work. Then, if they want a little more control something like [view fadeInOverTime:seconds]. Adding a shadow should be as easy as [view addShadow] or [view addShadowWithCornerRadius:radius]. Rounding corners is already extremely easy using QuartzCore, but let's make it even more intuitive for people. [view roundCorners] and then [view roundCornersWithRadius:radius]. The whole point is to make development exponentially easier for anybody to come in and start making useful, beautiful things.

I'm working on a class to include that does all of point #2 plus a ton more - and seeing this post will probably be the catalyst to releasing it this weekend. I have a huge plan in the works for making extremely easy to use UI elements as well, but I think open sourcing this in chunks, then releasing the whole thing as an example on how they all work together is gonna' be the route I go. So far, I've released one part of the project that makes choosing good colors to use in the app a breeze (https://github.com/bennyguitar/Colours-for-iOS). The next one will be for UI utilities like the fade in and shadow code mentioned above.

Coming to Cocoa dev from the web all of the direct manipulation in objective C of styling seems like mayhem. I’m not very far in, but already the giant amount of searching and replacing required to change all the corner radii in an app is crazy.

For me it seems obvious that this stuff should be /declared/ in one place, with all other styling mechanism, not littered through dozens of classes that are primarily interested in getting things done, not looking pretty.

Of course I’m a new at this - and everyone seems to think the other way is better… So maybe I’ll come around with time, but right now Pixate seems like a great idea.

Beginner often tend to underuse storyboards. Except for fadein/fadeout and views being moved you really never end up coding styles in Obj-c. It's all done graphically using xcode and interface builder. Rounding corners is very often not necessary at all, since you end up using images all the time for buttons and backgrounds.

The stuff I'm working on doesn't use interface builder at all. Nor storyboards. When I start a new project I'll take a look - I was actually advised to ignore the tools and go all code all the time (and lots of images). And it’s worked out - but this is certainly a downside.

ever worked with git and storyboards? quite the disaster once you're more than the sole developer

Exactly. Plus storyboards tend to lock you in, and moving around and constantly iterating to better and better nav schemes kind of goes out the window.

FWIW this kind of thing is far, far easier on Android. It has it's own styling system that's somewhat similar to CSS and you can define and reuse properties and layout elements in a much saner way than the hodgepodge of tricks you have to resort to in iOS. Actually this is one of the reasons I consider Android to be overall easier than iOS to develop for.

Storyboards aren't dynamic. Our CSS implementation not only lets you style your app, including animation and transition, but it can be changed at run time, either locally or remotely -- just like the web. Think of storyboards/xibs as a layout mechanism, and ours as a dynamic styling mechanism.

It's theoretically interesting, but after having coded ios app for the last three and a half years i really don't see any user case where you'd want styles to be dynamic, and not behavior. Either use a UIWebView if you want to include completely dynamic and server-generated content (such as ads), or use native... Do you have any example ?

One real-life example (told to us by a customer): imagine you have a "spring sale" that you want to promote to your customers. You want to customize the look of the app, perhaps rearrange a few things, change the look, etc. You want to do this for a period of time, and perhaps even for a certain geographic or demographic area. With Pixate, you could push new CSS and assets as needed, then revert when the sale is over. You could even push different looks to different users, etc. Effectively, Pixate is the flexibility of web with the power of native.

Oh, ok, i didn't see that Pixate also handled download and caching of images. That's a good use case indeed, thx.

Reply on news.ycombinator.com