 Thank you for being here. Oh, you got a place to stand. Right. So today I'm going to talk about a library which I wrote recently called 字. It's a library written in Swift that lets you live reload auto layout constraints. So for most of the iOS app that I built, I find that roughly 30% to 50% of the time is spent doing UI work. It's just changing color, tweaking the placement of a button, of a view, and so forth. And it is actually very disruptive because every time I tweet, I may hit the Rebuild button, wait for the simulator to load the updated app, navigate to the correct screen so that I can do my testing, find that it's wrong, and then I have to repeat the cycle. It's very, very disruptive and weighs a lot of time. So what we want to do is what I like is being able to live reload, basically try to reduce this, rebuild, navigate, and test cycle, reduce the time spent on this. So there are already many different tools in different environments that do this. Some are on iOS. Some are on other platforms. For example, in iOS, there is this excellent tool called Injection for Xcode. If you haven't tried it out, I encourage you to look at it. There is also React Native and so forth. Of course, on other environments, like web applications, if you do server-side rendering, live reload is basically free, right? Because every time you reload your web application, you get the latest server-side code. I'll show you a demo of how it works. So I have a very simple app. I'm showing a ViewController. The ViewController's background color is red, and then I have two more views, which are blue and green respectively. So in order to use the library, you create your sub views just as you would do normally, and then you add them accordingly to their respective parents. The one additional thing you need to do is you need to create a style object as part of the library, and then you pass in a mapping between mapping from a string name for each view that you want to style using the library. I'm going to show you an example of how it works. So for example, I want to add a label to each of these views. So I'm going to call this v1. I'm going to call it a green view v2. So step 1, v1, label, add the label, and then add them to their respective parent. I'm going to add them to the map. I like to keep the name short, so it's more readable. I have to rebuild the app. So of course, they don't appear because I haven't set any tags, any background, foreground color, or the frames. So how the library works is for each ViewController, you have a corresponding style file. It's a bit like HTML and CSS. It comes in a pair. So this ViewController is called ViewController.swift. And we have a ViewController.styles file. I'm going to go through this later. But just for this example, so I call my label v1l. I'm going to set the text v1, v2l, text v2. I'm going to style it so that each label appears in the center of each parent. Center x equals v1. OK, you see that it appears at the top in the status bar. So if I do v1, center y, and I hit Save, it moves to the middle of its parent. And notice that each time I hit Save in the console, it says reloading styles. I don't have to rebuild the app anymore because the structure has already been established earlier on. I had to do one rebuild. So I can repeat the same thing for v2. I hit Save. It says reload and then it appears. It can say background color equals to red. Save, oh, wrong one. Save v1, red, oh, demo, live demo. Just fix this first. OK, so I can also set the background color of the label to red. I can change the background color of the second label to say white, and so on. So all this can be changed without rebuilding the app if it doesn't crash. So let me just go through what the styles file does. It supports auto layout visual format language. So you just copy and paste whatever that Apple provides for horizontal and vertical constraints. But in addition, it supports a way of specifying the metrics as a constant. So over here in this auto layout constraint, we use the constant m1. Can actually modify it here. So if I want it to be 120, this is basically the width of the red part of the screen. So it changes without having to rebuild. In addition to visual format language, it also supports an equation-like syntax. This basically maps directly to NSLayout constraint. So you have y goes to mx plus c, something like that. So this is basically saying that v2, the green view, has half the width of v1, the blue view. So I can change it to 1 quarter, hit Save. And then it life reloads. But in addition to layout constraints, I can also set properties as I showed earlier. So I can do red, green, blue. I can have a name, color, for example. I can specify an alpha value and so forth. So there are also other properties that you can set, for example, text labels. There's an image at the top. I can say image is here in the top left-hand corner. And change the background color to be white. I can say that the image on the left is not clip or clip. I can swap the image file. As long as the image is already included in the app. Same for buttons. I can change the title, so on and so forth. I can change the background color, white, oh, white. So if I hit the button, it shows another view controller. So normally, if you do changes here, you will need to rebuild. And then I was saying that you need to navigate again. It breaks your concentration because you need to do different stuff and not focus just on your code. So it's the same thing. We can life reload. This view controller is called ViewController2. So I just open ViewController2.styles file. I can proceed to make my changes. Again, equation-based syntax or visual format language. And then in addition, I can again specify different properties. This can be placeholder. So it changes the placeholder in the search bar. I can change the value of the progress bar just to see how it works visually. I can make the switch on or off. I can modify the slider value. I can even change tint colors. So here's one thing that I found useful, because this is auto layout. If I change the number of lines for a label, it will change. And then you'll notice that the corresponding UI views below also shift because it's auto layout, right? Everything recomputes on the fly. Very useful for testing. I can change the font use. Font can change the font. Can change the font size. Or if I want, I can use dynamic type and subtitle and so forth. So everything or not everything. Auto layout and certain property changes is all live reloaded. So let me show you. So that was the demo. Just look at how it works again. You still specify. You still specify your view hierarchy in code. And then you create a corresponding style file. And you can put your constraints and property changes in your separate style files. The style files are all reloaded directly from the project folder. And then it falls back to the app bundle. So in production or when you do a submission or test flight, it basically skips the project directory and just read it from the app bundle just as normal. The style files are line-based. So each line is one instruction. Each line can be in visual format language. It can be an equation like syntax. Or you can write commands with preceding pound sign. We can set properties, as I showed earlier. Red-green-blue components, red-green-blue-alpha, name colors. These are examples of properties that you can set. It should be extensible so other properties can be supported. Setup is relatively simple. You create your views in code. You add them in the correct hierarchy. And then most importantly, you need to specify, give them each a name which you pass to the installer. And then you call life reload. The implementation is actually quite simple. There is a parser which uses NS scanner and some simple string parsing to go through each and every style file, which reads each line and interprets them as individual instructions. Then the parser just watches the group of style files for any changes and then reloads whatever is currently on screen. So that's it. It's a very simple library. Just some links for some of the things that I mentioned, or at least listed. So check them out. It's very useful. So that's me. The code is on GitHub. I write a weekly newsletter if you're interested. I write simple tips about iOS app development, sometimes about Mac OS app development. And that's all I have. Thank you. One limitation is especially for visual format language is passed directly to NSA out constraint. So it crashes if you do something funny. But if you do the same thing without using this library, it will crash anyway. So in future, I might add some detection for syntax and stuff just to make sure it doesn't crash. So it's more friendly because it gets irritating after a while. It crashes. But there's actually a few limitations. There's no easy way to retrieve the constraint which you create. That means that a typical example is if you show the keyboard and you want to shift your entire view upwards, or part of view upwards, one way to do that animation is to change the constant of the constraint. So that's not possible now, or at least it's not that easy right now. If you want to do partial updating, for example, you hit a button and part of the view changes. And you just want to add one or two constraints. That's possible, but you can't use the library to do it directly. So bits and pieces like this. But I found that for most cases, most use cases are supported quite well. I haven't tested it much with UI TableView. When you use UI TableView, UI TableView sells with AutoLayout, without a library, usually it doesn't work perfectly anyway. So you might not even want to use AutoLayout with that. And of course, there's a one-to-one mapping between the view controller and each style file right now. So if your way of programming iOS app is to build two separate hierarchies, one for view controllers and one for views and sub-views, you can't use this library easily because the style file is mapped to each view controller. So you have a lot of custom views that you want to reuse across view controllers. You have to style them per view controller. Yes and no. You can still use Storyboard to create the views, to build the hierarchy. You can still use Storyboard to add constraints if you want. And then you can use style files to add more constraints. Yes, yes, yes. The one thing I didn't show is all the views are actually added to one view I call main view. But I think that's just an implementation detail. You'll notice that I have this view called main view. I've been doing this even before I wrote this library. What I do is in a view controller, all the views that I have, they don't go into view controller.view. It goes into a big view called main view. And then the main view gets added to the view controller. I find it's easier because you can sort out the entire view. Or in the example that I gave, if you want to shift your view, if you show the keyboard or you want to hide it, it's way easier to just move that view and not touch view controller's view. It also helps for animation and stuff. The library assumes that you have such a view, which is a minor detail. Any other questions? The one in the storyboard will of course be created first. And then the library will remove all the constraints and then add. So whatever you add in your storyboard is wiped out. And basically with each live reload when you hit Save, it will remove all the constraints and then add them back. So it's possible that there can be performance issues if you have a very complicated view hierarchy. But in practice, I've always just removed all the views and then reload even before I use this library, unless for a certain case. That's when you need to do partial, just adding one or two constraints. Not that common, as far as I can tell. Unless you use UI table view. Second thing, this is some good help. Yeah, yeah, just, I actually regret the name as I prepare for presentation, because when I write the code and when I came up with the name, it's all on paper. I don't need to pronounce it. It's actually Chinese. It's like creating a map. Yeah, so life is filled with regrets. Any other libraries? Yes, it depends on, I think it's called File Watcher by Christoph. It was one of the presenter for 2016. It is basically a library which lets you watch files for changes. Yeah, the library has one purpose, which it does very well. Oh, one thing I forgot to mention is I recommend not using the library support for setting properties in submissions, just to be safe. Yeah, because it's interpreting whichever properties and then calling them dynamically. Probably don't want to do that too much, but you can use it for auto layout. And in the event if you really don't want to use a library, you don't want to use a library in production at all, it's designed in such a way that it's relatively easy for you to just cut out everything from the style files and paste it in your code. Most of them remain unchanged. Yeah, thank you.