Why is it 1500 dollars per day to do what seems to be templated app development -- many other companies offer this at far far lower rates (think 50 dollars or less for a complete app).
Why only iOS? The purpose of templated distribution is to reach a wider audience, not a narrower one.
Pixate Engine is a native framework for iOS (and Android soon) for styling your native controls using the CSS syntax. There's no web here other than the shared syntax of CSS. For example, to style a native UIButton:
First there was the native client era on desktops that involved twiddling around with swt, gtk, qt and windows programming.
Then came the advent of webapps with more uniform abstractions of client side js frameworks and css3 and dozens of toolkits and decorators around these.
Then came the mobile era with a new breed of native v/s web applications. Nowadays, the general opinion I hear is that no one really likes webapps on mobiles. But we as a community actively are trying to port over the abstractions of css/js frameworks to native mobile so that developers can continue being comfortable while programming devices that function at the whim of Apple and Google.
I wish there were a timeline of sorts of all the paradigm shifts that programming user experiences has undergone over the last decade.
I think it's a shame that something as as unambiguous and nice to work with as, say, the Cocoa framework and MVC (using that example because of familiarity), was available for us web developers without trying to shoehorn it into javascript and the browser environment.
Having had a taste of native app development, it makes client side web development comparatively frustrating. We're continuously getting new features but little in the way of a more satisfying environment that can help bring all these parts together.
Have you heard of Cappuccino? It's Cocoa for the web. You don't write javascript, you write Objective-J. It's pretty awesome. As a mac developer, I was immediately able to jump in and do cool stuff with it.
I'm not sure what the current state of the framework is, since the company that made it has been acquired, but it sure was a cool idea.
This is what makes me nowadays prefer work on native every time I am given the opportunity to do so.
Too many crazy web projects trying to shoehorn the desktop experience into the browser in a way that has to work the same across multiple browsers and operating systems, which leads to CSS/HTML/JavaScript hacks everywhere, with some customers discussing designs down to the pixel level.
Trying to turn native apps into template-styled web apps is just backwards; you're discarding the fine attention to detail, typography, pixel-positioning, scaling animations, etc, that can make native apps so great.
This isn't an all-or-none situation. You lose none of the fidelity of native development, it's just an abstraction of code to markup. It's all natively executed using native APIs. Typography, absolute pixel postions, animation, and much more is all there.
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)...
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.
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.
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.
Is it just me or is it a bit ironic that an iOS related website doesn't work well on iPhone? All the screenshots o out of the screen, and you can't zoom out or pan to see them.
I still think CSS is one step away from making something awesome for developers of all flavors (from not developing at all to extremely competent in other languages) to make native apps even easier to code. I'm working on a more natural language version for iOS right now.
I'm not a developer (or user) on iOS, but does it not have a similar design scheme for apps to Android (since ICS at least)? Would an app that looks like bootstrap fit in at all, and indeed would Apple even allow an app that resembles Bootstrap instead of its own design guidelines?
Bootstrap is totally configurable, we're just showing the default styling. In terms of Apple allowing alternate designs, I think they encourage it, just look at Garage Band ;-).
Of course, but if there was a standardised sort of style used by most applications, then recreating it using Bootstrap would seem like a lot of effort for little benefit. If there isn't much of a standard style, then this is really neat - that just seemed like an odd situation to me. My impression was that there would be a style, and Apple would enforce it, but it's great if that's not true. And fair enough, googling for Garage Band iPad..it looks unique.
31 comments
[ 2.9 ms ] story [ 46.1 ms ] threadHow is a system based on CSS stylesheet native?
Why is it 1500 dollars per day to do what seems to be templated app development -- many other companies offer this at far far lower rates (think 50 dollars or less for a complete app).
Why only iOS? The purpose of templated distribution is to reach a wider audience, not a narrower one.
button { border-radius: 5px; background-color: red; }
Think of it as declarative markup for styling native controls.
First there was the native client era on desktops that involved twiddling around with swt, gtk, qt and windows programming.
Then came the advent of webapps with more uniform abstractions of client side js frameworks and css3 and dozens of toolkits and decorators around these.
Then came the mobile era with a new breed of native v/s web applications. Nowadays, the general opinion I hear is that no one really likes webapps on mobiles. But we as a community actively are trying to port over the abstractions of css/js frameworks to native mobile so that developers can continue being comfortable while programming devices that function at the whim of Apple and Google.
I wish there were a timeline of sorts of all the paradigm shifts that programming user experiences has undergone over the last decade.
Having had a taste of native app development, it makes client side web development comparatively frustrating. We're continuously getting new features but little in the way of a more satisfying environment that can help bring all these parts together.
I'm not sure what the current state of the framework is, since the company that made it has been acquired, but it sure was a cool idea.
http://www.cappuccino-project.org/
Too many crazy web projects trying to shoehorn the desktop experience into the browser in a way that has to work the same across multiple browsers and operating systems, which leads to CSS/HTML/JavaScript hacks everywhere, with some customers discussing designs down to the pixel level.
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)...
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.
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.