5 ms·

Stevia: Human-readable auto-layout in code

125 points by sachadso 11y ago

tomyws 11y ago
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?
- euyyn 11y ago
  I find XCode's UI editor pretty good!
- pducks32 11y ago
  They do in the interface builder however if you just wanted to use programmatically created views then not really no.
- Someone 11y ago
  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/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html https://developer.apple.com/library/ios/documentation/UserEx...)
  - schwarrrtz 11y ago
    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.
    - sachadso 11y ago
      couldn't agree more !
    - cellularmitosis 11y ago
      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.
- woah 11y ago
  Do you also find it strange that WYISWYG website editors are not more widely used?
- wrigby 11y ago
  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.
- bri3d 11y ago
  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.
- sachadso 11y ago
  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-builder http://blog.teamtreehouse.com/why-i-dont-use-interface-build...
bphogan 11y ago
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.
- sachadso 11y ago
  Thanks a ton for the kind words :)
gravypod 11y ago
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.
seanalltogether 11y ago
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.
- nostrademons 11y ago
  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.
- lstamour 11y ago
  Um, auto-layout, which this says it uses, is an Apple supported constraints system? https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/ https://developer.apple.com/library/ios/documentation/UserEx...
nashequilibrium 11y ago
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.
msoad 11y ago
There is also SnapKit which I really like: https://github.com/SnapKit/SnapKit https://github.com/SnapKit/SnapKit box.snp_makeConstraints { (make) -> Void in make.width.height.equalTo(50) make.center.equalTo(self.view) }
- aaronbrethorst 11y ago
  And Masonry, if you're still on Obj-C (like me): https://github.com/SnapKit/Masonry https://github.com/SnapKit/Masonry [box mas_makeConstraints:^(MASConstraintMaker* make) { make.width.height.equalTo(50); make.center.equalTo(self.view); }];
- RussianCow 11y ago
  And cartography, which is my preference: https://github.com/robb/Cartography https://github.com/robb/Cartography constrain(button1, button2) { button1, button2 in button1.right == button2.left - 12 }
- bdarnell 11y ago
  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/clients/ios/Source/UIView+constraints.h 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];
- mbenjaminsmith 11y ago
  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.
- thought_alarm 11y ago
  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;
iLoch 11y ago
For anyone looking for something a little closer to what they know from the web: https://github.com/facebook/css-layout https://github.com/facebook/css-layout
mpd 11y ago
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.
- Pharaoh2 11y ago
  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.
  - mpd 11y ago
    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.
- glenda 11y ago
  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"
  - mpd 11y ago
    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.
    - pbhjpbhj 11y ago
      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.
  - Can_Not 11y ago
austinl 11y ago
Since people are discussing Auto Layout alternatives, I'd recommend AsyncDisplayKit (http://asyncdisplaykit.org/ 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).
- kitsunesoba 11y ago
  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.
  - cellularmitosis 11y ago
    Doing asynch UI "by hand" might be easier than you think. Here's a table view example: https://github.com/pepaslabs/GlitchyTable https://github.com/pepaslabs/GlitchyTable
ufo 11y ago
Is that operator-overloading abuse or something else?
- sachadso 11y ago
  haha indeed
chuinard 11y ago
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.
jheriko 11y ago
Apple should pull their finger out and solve this historically very well solved problem so that this work is not necessary ::
- sachadso 11y ago
  Amen!
mayoff 11y ago
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.
heyalexchoi 11y ago
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/documentation/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html https://developer.apple.com/library/prerelease/ios/documenta...
- radicality 11y ago
  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.
  - sachadso 11y ago
    Exactly the problem we're trying to solve ;)
- sachadso 11y ago
  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 :)
sshykes 11y ago
Looks like they've included their .DS_Store files within the git repository: https://github.com/s4cha/Stevia/tree/master/Stevia/Stevia https://github.com/s4cha/Stevia/tree/master/Stevia/Stevia Screenshot: http://imgur.com/5EPUNeZ http://imgur.com/5EPUNeZ
- cellularmitosis 11y ago
  Can you elaborate on the consequences of doing that for the non-Mac users among us?
xHopen 11y ago
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
- sachadso 11y ago
  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 :)
jkot 11y ago
Why reinvent a wheel? Have a look at miglayout http://www.miglayout.com/ http://www.miglayout.com/
- sachadso 11y ago
  Yeah let's use Java on iOS !
  - jkot 11y ago
    No lets reimplement miglayout
harryf 11y ago
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)?

125 points by sachadso 11y ago

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?

euyyn 11y ago
I find XCode's UI editor pretty good!
pducks32 11y ago
They do in the interface builder however if you just wanted to use programmatically created views then not really no.
Someone 11y ago
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/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html https://developer.apple.com/library/ios/documentation/UserEx...)
- schwarrrtz 11y ago
  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.
  - sachadso 11y ago
    couldn't agree more !
  - cellularmitosis 11y ago
    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.
woah 11y ago
Do you also find it strange that WYISWYG website editors are not more widely used?
wrigby 11y ago
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.
bri3d 11y ago
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.
sachadso 11y ago
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-builder http://blog.teamtreehouse.com/why-i-dont-use-interface-build...

bphogan 11y ago

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.

sachadso 11y ago
Thanks a ton for the kind words :)

gravypod 11y ago

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.

seanalltogether 11y ago

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.

nostrademons 11y ago
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.
lstamour 11y ago
Um, auto-layout, which this says it uses, is an Apple supported constraints system? https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/ https://developer.apple.com/library/ios/documentation/UserEx...

nashequilibrium 11y ago

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.

msoad 11y ago

There is also SnapKit which I really like: https://github.com/SnapKit/SnapKit https://github.com/SnapKit/SnapKit box.snp_makeConstraints { (make) -> Void in make.width.height.equalTo(50) make.center.equalTo(self.view) }

aaronbrethorst 11y ago
And Masonry, if you're still on Obj-C (like me): https://github.com/SnapKit/Masonry https://github.com/SnapKit/Masonry [box mas_makeConstraints:^(MASConstraintMaker* make) { make.width.height.equalTo(50); make.center.equalTo(self.view); }];
RussianCow 11y ago
And cartography, which is my preference: https://github.com/robb/Cartography https://github.com/robb/Cartography constrain(button1, button2) { button1, button2 in button1.right == button2.left - 12 }
bdarnell 11y ago
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/clients/ios/Source/UIView+constraints.h 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];
mbenjaminsmith 11y ago
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.
thought_alarm 11y ago
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;

iLoch 11y ago

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

mpd 11y ago

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.

Pharaoh2 11y ago
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.
- mpd 11y ago
  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.
glenda 11y ago
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"
- mpd 11y ago
  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.
  - pbhjpbhj 11y ago
    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.
- Can_Not 11y ago

austinl 11y ago

Since people are discussing Auto Layout alternatives, I'd recommend AsyncDisplayKit (http://asyncdisplaykit.org/ 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).

kitsunesoba 11y ago
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.
- cellularmitosis 11y ago
  Doing asynch UI "by hand" might be easier than you think. Here's a table view example: https://github.com/pepaslabs/GlitchyTable https://github.com/pepaslabs/GlitchyTable

ufo 11y ago

Is that operator-overloading abuse or something else?

sachadso 11y ago
haha indeed

chuinard 11y ago

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.

jheriko 11y ago

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

sachadso 11y ago
Amen!

mayoff 11y ago

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.

heyalexchoi 11y ago

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/documentation/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html https://developer.apple.com/library/prerelease/ios/documenta...

radicality 11y ago
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.
- sachadso 11y ago
  Exactly the problem we're trying to solve ;)
sachadso 11y ago
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 :)

sshykes 11y ago

Looks like they've included their .DS_Store files within the git repository: https://github.com/s4cha/Stevia/tree/master/Stevia/Stevia https://github.com/s4cha/Stevia/tree/master/Stevia/Stevia Screenshot: http://imgur.com/5EPUNeZ http://imgur.com/5EPUNeZ

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

xHopen 11y ago

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

sachadso 11y ago
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 :)

jkot 11y ago

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

sachadso 11y ago
Yeah let's use Java on iOS !
- jkot 11y ago
  No lets reimplement miglayout

harryf 11y ago

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)?