Native Mobile Apps Styled With CSS - Pixate (YC S12) Launches | Hacker News Reader

Native Mobile Apps Styled With CSS - Pixate (YC S12) Launches

techcrunch.com

59 pointspcolton42 comments

As someone who builds app for big brands (Conde Nast, Nike, Porsche, etc.) I will not use this, despite any desire to actually do so.

Why?

You're shipping me a binary only. I want the source. I don't want to wait for you to fix some shit that you may or may not get around to doing. I have a really strict rule about this when it comes to client work, even stricter for personal work.

Your idea that I should base an entire application on a closed source binary that may or may not work is customer hostile, imho. You are inadvertently leaving customers out to dry when something breaks or doesn't work correctly. Unless your company has a team of devs ready to handle these cases ...

Would have been a good idea when the component market was roaring in the Borland Delphi days, but we're in the future now were open source is the way to go.

Pass.

I'm really torn about this. I was a Kickstarter backer of Pixate, and I love their tools, but I brought up the exact same concern to them over a few months ago. The response I got from them can best be paraphrased as 'we'll do our best'[1].

Accordingly, I'll likely use Pixate for apps shipped under my own brand, but I'd never use it for client work until this situation is resolved. The risk is simply too great.

There's an open source solution that does roughly the same thing but not as nicely, called NUI (http://www.cocoacontrols.com/platforms/ios/controls/nui), that you might want to check out.

[1] In case Paul or Kevin see this and want more context, the reply I got was via Kickstarter on July 24 2012 at 8:40AM Pacific.

Pixate is not an all-or-nothing solution. You can just style what you want via CSS, and do the rest in code. Do it all in code and just inline some CSS if you like. This isn't a "use UIKit or us" type of decision, but more of a "how can I write a lot less code and more dynamically style my apps". Lastly, at the Enterprise level, we offer source code escrow.

Local to Dallas?

This is crazy, you're already using closed source when you link with the SDK, which links with numerous other closed source components.

God grant me the serenity to accept the things I cannot change, the courage to change the things I can and the wisdom to know the difference.

That applies here.

UIKit is designed to be built upon. A lot of Apple stuff may be a black box but it is designed to be subclassed. This is really an all or nothing affair. Either this works perfectly for you or you are shit out of luck and you have to compromise to fit inside their box.

A lot of Apple stuff may be a black box but it is designed to be subclassed.

Aside from a small number of top-level classes[1] UIKit isn't designed to be subclassed. When you subclass things like UIAlertView, UIButton, UISwitch, UITextField, UIWebView… etc, you're in for a world undocumented gotchas and spending hours to do small simple things.

1. UIView, UIControl, UITableViewCell, UIScrollView, UIGestureRecognizer, UIViewController, UIApplication and maybe one or two other classes.

And you've listed about 90% of the things I usual end up subclassing because I've hit some limitation.

Also I wasn't talking specifically about UIKit. Foundation is another great framework that I've subclassed many times.

It's not perfect but Apple puts a lot of work into documenting how to subclass their frameworks. Third-party UI frameworks like this are much less forgiving.

Can you give an example of some things that you subclass?

From Foundation? NSDictionary, NSArray and NSOperation instantly jump to mind.

What do you get out of subclassing NSDictionary or NSArray that you don't get out of a category?

Well in this case I subclassed them so I could have the backing data source only weakly reference the items in the dictionary/array and because I subclassed them I can use them wherever NSDictionary or NSArray is an accepted parameter.

Apple's documentation also gives some examples:

https://developer.apple.com/library/ios/#documentation/Cocoa...

Why not use CFDictionaryRef and pass it along via toll-free bridging?

I'm confused. How is that any easier? It's six of one, half dozen of the other.

I'd much prefer to write Objective-C code than pure C.

Are there any examples of really successful big name projects using third-party UI frameworks that cost money?

Anything I use in my apps has to be open source in case either I come across limitations or support is dropped. I can't create a dependency in my app that could severely cripple me in the future.

It seems like using Pixate would introduce a huge dependency on your application and everything that Pixate does is mapping down to something already done in UIKit or perhaps CoreGraphics. I can understand the allure of this framework because it would save you writing a lot of code yourself but when you come across a limitation (which you undoubtably will because not even the mighty UIKit does everything we need) and you implemented it yourself you can then easily make improvements rather than waiting for a third-party. Sure you could make requests but if Apple honoured every single improvement request on UIKit they would never ship.

As an iOS developer I'm already in bed with Apple but their track record with AppKit and UIKit speaks for itself. Their frameworks are black boxes but I can build upon the shoulders of giants. Third-party UI frameworks like this feel like I am constraining myself to very explicitly defined limitations and the second I cannot adhere to those limitations I must be the one to compromise instead of striking out on my own.

Is there something that I am missing with these third-party UI frameworks because the opportunity cost has always seem to be too high for me.

If the pricing becomes more affordable, I think Pixate has a chance to totally change the way native mobile front-end development is done.

Just look at the simplicity and familiarity with traditional front-end development. http://www.pixate.com/blog/2012/12/15/table-disclosure/

View Controller:

   button.styleId = @"disclosure";

default.css:

    table-view #disclosure {
        background-color: linear-gradient(#75a4e6, #2670d8);
        border-radius: 15pt;
        border-width: 2pt;
        border-color: white;
        size: 27pt 27pt;
        font-size: 16pt;
        box-shadow: 1pt 1pt 1pt #333;
    }

If only they had a demo we could test how well Pixate lives up to its claims.

Example of use in XCode: http://www.youtube.com/watch?feature=player_embedded&v=h...

You can install our free Pixate Playground app on your iPad and play with the CSS in real-time:

https://itunes.apple.com/us/app/pixate-playground/id57867638...

It's also open sourced: https://github.com/Pixate/Playground

I download it and get:

.../Playground-master/Playground/PXViewController.m:9:9: 'PXEngine/PXEngine.h' file not found

The framework file is not included...

https://github.com/Pixate/Playground/issues/1

Any plans to do a similar framework for Android?

Pet hate: light source at the top left for drop shadows. The iOS light source is at the top…

Getting Chrome malware warning for this article:

Danger: Malware Ahead! Google Chrome has blocked access to this page on techcrunch.com. Content from d.adsbyisocket.com, a known malware distributor, has been inserted into this web page. Visiting this page now is very likely to infect your Mac with malware.

I'm also getting this.

I didn't get it for TechCrunch, but did for this: http://www.cultofmac.com/192350/how-apples-obsession-with-go...

Getting similar error message "Reported Attack Page!" and page blocked message in Firefox.

For me, not being able to try the library in my app is a deal-breaker. I'm not willing to shell out $199 on faith alone.

It would have been nice to have it link to the framework instead of a techcrunch article. First hand sources are always preferred if they're available.

EDIT: forgot to include the link instead of just commenting: http://www.pixate.com/

relevant: https://github.com/tombenner/nui

I'm very curious how much Pixate differs from NUI.

I looked into doing something like this and it seems like a pretty straight forward idea. Map CSS properties to UIView properties. It felt like it was lot of brute force work. Creating a parser and some sort of renderer for every supported UIView seems like the majority of the work.

Great idea. I think that anything that aids cross-platform development is going to be very valuable over the next few years.

Building a platform agnostic front end without having to resort to javascript/HTML could be a really useful step forward.

Looks cool, but why can't this be achieved by simply using the native iOS implementation?

Assuming you're interested in custom UI elements, visual styling in native iOS code is significantly more time-consuming than something like CSS (assuming an equal level of familiarity with both). A lot of apps just end up using static image assets for everything because it's that much easier and quicker. If the performance is decent and the pricing fair, this could be a big time-saver.

Of course it can be achieved using traditional methods. But this could be a much faster and more maintainable method of styling. Compare straightforward CSS files to XIB files, storyboards, and a bunch of images.

You can use a native iOS implementation. I wrote a demo app over Christmas break using Pixate and it was so easy to style. The only problem was that including Pixate caused a crash when I tried to removed the camera view controller so I had to redo the whole thing native.

That's when I realized the power of Pixate. My code got a bit more complex having to implement the gradient layers, borders and background images in Objective-C. I ended up migrating it, but Pixtae was definitely a lot simpler.

Nobody is saying it can't be. The draw is making it easier for people who are more comfortable with CSS, which is a lot of people.

It can and it is preffered. Especially if you dont care about iOS < 5.

This would seem to answer the "is no-idea a good idea for YC" question -- it looks like a great product, and they applied as no-idea (according to the TC article).

I like the subtle Arrested Development joke on the front page. "Loose seal!!"

Geeez whats up with the music, I couldn't watch the whole video.

So let me get this straight - Pixate wants people to build native iOS apps with CSS.... um, ARENT WE JUST RE-IMPLMENTING THE WEB PEOPLE?!

Jesus! The one valid use case for native apps is games, everything else can be solved with web apps. Why we are going out of our way to re-implement the ease of web development on native apps should fucking tell you something. On top of all this, they want to charge you $199 for it?

Disregarding the topic of whether or not Pixate itself is commercially viable, but it makes me feel like XML-RPC all over again. Wasn't that what HTTP was for in the first place?

We go through all this crap to make making "apps" convenient. Ultimately the answer was in front of us the whole time we were just too stupid to see it. The web will win. SECREST OUT!

  > everything else can be solved with web apps.

Key word there is can. You sure cab try and sometimes succeed in replicating native specialized components with html, js and css cobled together, and maybe even to get it to work more or less OK. But why?

  > the ease of web development

You gotta be kidding. Developing web apps is not easy. Developing cross-platform mobile web apps is even harder. Developing mobile web apps of comparable to native performance is extremely difficult. I wonder is there anyone who after spending some time to properly learn either native SDK still prefers builng mobile apps with the web stack.

  > The web will win.

The web will win what? Is there a war? A race? What I think will eventually win is understanding what the web is for, what the apps are for and what is the best tool for the job. Trying to fit a square peg into a round hole cannot win.

Reply on news.ycombinator.com