There is also SnapKit which I really like:

https://github.com/SnapKit/SnapKit

        box.snp_makeConstraints { (make) -> Void in
           make.width.height.equalTo(50)
           make.center.equalTo(self.view)
        }

And Masonry, if you're still on Obj-C (like me):

https://github.com/SnapKit/Masonry

    [box mas_makeConstraints:^(MASConstraintMaker* make) {
        make.width.height.equalTo(50);
        make.center.equalTo(self.view);    
    }];

And cartography, which is my preference:

https://github.com/robb/Cartography

    constrain(button1, button2) { button1, button2 in
        button1.right == button2.left - 12
    }

Or use NSLayoutAnchor, which was added in iOS 9 and OS X 10.10;

    [box.widthAnchor constraintEqualToConstant:50].active = YES;
    [box.centerAnchor constrantEqualToAnchor:self.view.centerAnchor].active = YES;

Or while we're sharing, here's mine in Obj-C++ (although I never managed to extract it into a separate package):

https://github.com/viewfinderco/viewfinder/blob/master/clien...

    [self addConstraints:box.anchorWidth == 50];
    [self addConstraints:box.anchorHeight == 50];
    [self addConstraints:box.anchorCenterX == self.view.anchorCenterX];
    [self addConstraints:box.anchorCenterY == self.view.anchorCenterY];

Came here to say the same thing. I've abandoned storyboards and nibs in favor of SnapKit and it hasn't let me down so far. It's one of the better libraries I've used on OS X and iOS.

It's not really on-topic, but why do people name their projects with names that are very difficult to find via search engine? I really don't understand this mindset.

I guess they don't understand how search engines work, like that dumb company that created the unsearchable programming language Go.

I think this has hugely influenced the number of people who refer to it as 'golang' instead of just 'go'.

If a query comes up with junk I usually replace 'go' with 'golang'.

Which would have been a terrible name if they weren't simultaneously controlling the bully pulpit.

All projects start that way, mostly because it very hard to invent a new noun for something. Some projects just get really popular and then get high on search rankings for that noun organically.

I get that¸ but naming your project a single word that has tons of pre-existing search results can't be a great idea if you're looking for traction. The average person's (or even programmer's!) Google-fu has always been much worse than I expected, ime.

I don't think this is actually an issue. You can always add context to searches -- rather than searching for just "stevia" you can search for "stevia iOS layout"

I mentioned it in my response to the other reply, but I've found that the average programmer's Google-fu is actually quite poor, and they would not do that subsequent narrowed search.

Doesn't matter anyway, Google nowadays just ignores some words if it feels like it. Even if you add quotes << "stevia" "iOS" "layout" >> then you're not guaranteed that the pages will have all the words in. Google need a "just show me the results I asked for" button.

Sometimes you have to add the boolean nots.

PHP templates -"WordPress" -"joomla" -"codeignitor" -"drupal"

Even worse is the tendency to give every subproject a non-descriptive name. E.g. Safari on iOS/OS X

This just raises the mental burden and lowers discoverability.

I am not an iOS developer with much experience. I have taken one class and built two very simple apps. So I can't weigh in on how good of an idea this is from an iOS developer standpoint.

But I can say from a beginner to iOS standpoint that this looks amazing and I will put it to use in an app I am building immediately, as soon as I can figure out how.

To the author of this library, thank you.

Thanks a ton for the kind words :)

Since people are discussing Auto Layout alternatives, I'd recommend AsyncDisplayKit (http://asyncdisplaykit.org/) – although it's a bit more advanced. Layout mimics CSS and Flexbox. It was originally built by Facebook and very actively maintained.

You also get a number of other advantages, like moving UI operations off of the main thread (which is often a pain point in iOS apps shooting for 60fps).

AsyncDisplayKit is cool stuff, but I really wish it were possible to yank its layout and “doesn’t do layout on the main thread” parts and apply them to vanilla UIKit. It’s frustrating to run into the inevitable unsupported use cases, bugs, etc with alternative UI systems. UIKit has its quirks but it’s mature enough that coming up with a use case that it can’t serve in on way or another is difficult. It’ll be years before alternatives can achieve that.

Doing asynch UI "by hand" might be easier than you think. Here's a table view example: https://github.com/pepaslabs/GlitchyTable

OP: this is really neat, but i'm curious - what was your motivation for creating something so similar to autolayout's first party visual format language?

https://developer.apple.com/library/prerelease/ios/documenta...

Have you tried using it? It's all string-typed, and the worst when you don't get any error until you compile the app and then it complains you have an error in your layout "code" (which is just a string). Layout in code should be checked at compile time, which this project seems to attempt.

Exactly the problem we're trying to solve ;)

This is indeed vastly inspired by Visual Format Language purposefully so, so that there's nothing more to learn. This actually does pretty much the same thing behind the hood. We can say this is just Apple's visual format on steroids.

Three reasons mostly motivated us : 1. having the compiler on our side and not just hope the string would parse fin at runtime. 2. Laying out Horizontal and Vertical layout at the same time 3. Having something readable cause readable == maintainable :)

If you can target iOS 9 (or later), `UIStackView` eliminates a lot of the need for handcrafted constraints. Also, the project's example “Native Autolayout” code is written in a gratuitously verbose style.

How do you approach adaptive layout with this? How easy is it to define a layout that can work on all devices and with different orientations? Are you able to specify size ratios between elements for example (one annoying thing missing from Apples visual format language)?

Thanks for the effort. As a professional iOS developer since 6 years, I think is really good to see people coming out with better ways to do things. Autolayout works but the amount of code that you have to write is just out of this world, is a nonsense. And implementations like yours should open the eyes of apple to create something better. GREAT JOB OP

What we found after trying lots of different layout strategies on our iOS App was that Autolayout in code was the simplest to maintain, and still using Apple technology, contrary to ReactNative for example. Furthermore we were absolutely against reinventing a heavy layout engine knowing we had Autolayout at hand. The syntax was very harsh on the eyes though so we looked into ways to make it better, and Stevia (healthy syntactic sugar) was born! Thanks a lot for the kind words :)

For anyone looking for something a little closer to what they know from the web: https://github.com/facebook/css-layout

Actually laying things out in iOS, coming from an Android background, was something I could just not grasp. It was a big driving factor in me going with Ionic, which lets me use flexbox.

Looks like they've included their .DS_Store files within the git repository:

https://github.com/s4cha/Stevia/tree/master/Stevia/Stevia

Screenshot: http://imgur.com/5EPUNeZ

Can you elaborate on the consequences of doing that for the non-Mac users among us?

I feel like the app developers who don't simply bite the bullet and use the technologies that Apple promotes inevitably dig themselves into a corner.

Programmatic layouts/constraints just crumble underneath you when Apple decides to make changes in each new version of iOS or introduces a new formfactor.

I think that's often true, up until the point in time where it isn't. :-)

I remember that when DHTML/Javascript was young, from 1998-2004, you used the features built into every browser or you'd find yourself painted into a corner with the next release. Java applets, VBScript, ActiveX, Flash, and numerous third-party plugins: all dead. And then suddenly, around 2005, Prototype/JQuery/YUI/Dojo all came out, and you were an idiot if you didn't use a third-party library. The pendulum is starting to swing the other way now that browsers are pretty reliably standards-based, but there are still a number of people who look at you funny when you suggest using vanilla JS.

I was a little young to remember, but IIRC the same thing happened with the PC: through most of the early 80s, if you didn't write in assembly and use the specific features provided by each vendor, your app didn't have a chance. Then 1990 rolled around, decent C/Pascal compilers came out, third-party class libraries took off, and you got left behind if you still coded in assembly. Then by the early 2000s things had centralized under Microsoft .NET again, but by then the web was taking off and nobody cared.

It seems like this is the pattern of most software platforms: for the first 10 years, you better code to proprietary APIs because you won't be able to accomplish anything otherwise, and if you do it'll be obsolete with the next OS release. For the next 10 years, an explosion of third-party frameworks takes off, and you pick the one that makes you the most productive. In the last 10 years, things centralize again under a monopoly vendor, but by then the platform is already getting obsolete. Not sure where we are in the cycle for iOS - we've probably got a couple years to go - but it looks like it may be happening in Android land already, with Dagger 2 and RxJava.

Um, auto-layout, which this says it uses, is an Apple supported constraints system? https://developer.apple.com/library/ios/documentation/UserEx...

I think grandparent poster is saying app devs should program directly to the built-in Apple syntax rather than using a third-party library which wraps it. Because if Apple comes out with extensions or changes, then anyone who uses Stevia will need to wait until the library incorporates them, losing their advantage to competitors in the process.

I sympathize somewhat with the grandparent poster's point, but it all depends on how likely Apple is to improve auto-layout vs. how many new developers need an easier layout system now. JQuery managed to become massively popular on the web, despite web browsers eventually adopting most of its innovations, because the browsers took years to incorporate its innovations (and sometimes never quite got the syntax right) while millions of people needed to make a webapp right now.

I can see that now. Certainly anyone who worked with the HTML-based iOS components Facebook had back in the day was in for a shock later. I don't recommend using any iOS libraries you aren't prepared to upgrade/replace later -- and this includes Apple code too! Plenty of Apple APIs change every year, so... I'd hope somebody takes up the cause of updating this for as long as the API proves useful. :)

I hate storyboards and I decided that I will start using them after my current project is done. I just had so much code dealing with autolayout and constraints and weird little bugs. This looks really cool and will try it out. Thanks for the lib.

I find it strange that something akin to markdown-style syntax sugar is more user-friendly than a visual designer. Do the tools for developing a UI for iOS this way not include a WYSIWYG editor to set things such as contraints?

The tools do include that functionality, called Interface Builder or the Storyboard Designer.

The editor on its own is fairly nice to use these days, but it outputs obtuse XML and has a propensity to edit parts of the layout XML file that weren't actually modified. This makes source-control level collaboration and especially code review very difficult. To make things worse, for a long time the tooling encouraged putting almost all UI into one giant "Storyboard XML" file, guaranteeing confusion and conflicts.

The editor was also quite slow and crashy for years which drove the proliferation of these libraries and the "don't use the storyboard editor" meme accompanying them. It's gotten a lot better in the last ~2 years and I haven't had a crash in heavy day-to-day usage for quite some time.

If Apple could improve the XML output format to be easier to review, eliminate the serialization/deserialization weirdnesses, introduce a visual diff-and-merge tool, and improve the performance just a bit more, the Interface Builder would be excellent, but as is, I see why a lot of people don't like using it, especially on big projects with many collaborators.

They do, but search and replace, diffing, and copy-paste of multiple elements and their constraints likely (I haven't used Xcode's editor much, certainly not recently) do not work as well as their equivalent in text.

And of course, some people find markdown more user-friendly than a visual GUI for more or less the same reasons, so it should not be that surprising to find some people experiment with this.

And of course, autolayout has a text-based language of its own (https://developer.apple.com/library/ios/documentation/UserEx...)

you can copy elements in interface builder, iirc. you can't copy their constraints, which makes sense because the copied instances necessarily have different constraints. otherwise the copies would just stack on top of each other.

in my personal opinion, IB is great for layout of one view or screen, especially with the new IBDesignable and IBInspectable features.

doing app navigation in a storyboard is a terrible idea and will lead to a monolithic storyboard file that is very annoying to work with.

Was going to say something similar, that IB is great if you are doing one-off screens, but it isn't the best for creating reusable / composable UI elements.

couldn't agree more !

I think it's really a question of audience. A textual DSL for visual layout is popular to the HN audience, because most of us are more comfortable writing code and interacting with computers on the command line. While we love having a DSL that we can use our favorite tools on (like diff, grep, ack, etc.), the majority of other folks (read: non-HN users) probably find a WYSIWYG editor much nicer.

Using Interface builder is Great indeed it just has a ton of other issues down the road, this article sums it well : http://blog.teamtreehouse.com/why-i-dont-use-interface-build...

They do in the interface builder however if you just wanted to use programmatically created views then not really no.

I find XCode's UI editor pretty good!

Do you also find it strange that WYISWYG website editors are not more widely used?

I wonder if something similar would work in Java using annotations.

I experimented with this a little in a game I was working on. You just need a standard way of displaying everything, then automatically generate the UIs.

Is that operator-overloading abuse or something else?

haha indeed

Apple should pull their finger out and solve this historically very well solved problem so that this work is not necessary ::

Amen!

Why reinvent a wheel? Have a look at miglayout http://www.miglayout.com/

Yeah let's use Java on iOS !

No lets reimplement miglayout