I'll be sharing how to make GenericTableViewController very soon since it greatly reduces the tedious list creation process. This class will also be used in the latest Podcasts course to speed things up significantly.
Lets Build That App I was thinking if you would have used them in Instagram course, codebase would have been so much smaller. :) When is podcast course coming by the way?
Yes indeed, live and learn. Trying to improve things one thing at a time in 2018. Thanks for the support and feedback. I'm recording the demo video for podcasts course today.
Amazing! Can’t wait to watch it. Thanks to you actually. Been following you since Feb 2016. It’s been an year. My skills have improved vastly! 😀 Thank you for everything Brian. I had some doubts regarding my iOS dev, can I contact you on email regarding them?
I was REALLY hoping you would just copy/paste a similar tableView you've created in a previous project, and then just tweak that for the programatic part. Would have been hilarious. "Storyboard took 11 minutes... programatic... 2 minutes, lol. I'm half-kidding of course, but a nice bonus to 100% programmatic UI elements is the possibility to reuse similar elements between projects (with some tweaking of course). Things like custom buttons, views, etc...
Haha that would've been the ultimate cheat. I find the great thing about code is that I can eliminate all the tedious busy work that comes with creating a basic list and one cell. In addition, there is no need for these strange segue/cell identifiers maintained in a separate file. Once the project grows, a bunch of common components then gets abstracted away with their own styling for reusability which is killer.
Lets Build That App a solution I like is to create xibs for views and cells which need to be reusable. You could also make their class designable so you can see the cell display inside a storyboard. For reuse identifiers I find it’s best to just have an identifier in the cell class which is a strong describing self, this avoids magic strings outside the storyboard 👍
Few comments : 1. Using storyboard is to visualise the flow of app when action is done from one page. If you focus on business flows while development, that perfectly suits your mind since we can map the business flows directly to storyboards. 2. If your app does many tasks and flows are complicated, I shall use multiple storyboards instead of xib / code. Either of this we have to bear the flow in mind. I often use code to control UI visibility and delegate actions but not to control every part including constraints and colours, e.t.c. 3. From my experience, I have tried pure codes to set UI positions and properties on view controllers. I have to search keywords of methods to fix bugs since the lines of codes are more clustered to one controller file. Of course we can split the delegates and create models but still a lot when the business flow complicates.That makes longer time for user to search and revise logic parts. I use view controllers to control UI actions and execute networking actions. That makes to one question : What does the App used for and which major actions are crucial for app and which are optional. If some tasks or requirements are optional , delegate those to backend system instead.
@@larrystreehouse1124 Doesn't storyboard become tedious to manage when there is a whole organization working? Also version control becomes an issue right?
Literally no one is making tutorials in code for those of us who prefer that. Your UA-cam channel is a godsend for me. Learning the code helped me to understand the storyboard. I continue to be amazed as to why Apple and others don’t have a beginner code path that focuses on the code and building the UI in the storyboard.
I learned generics in my hardest college course. I was wondering how they would help my iOS career. Now I am starting to see why my professor sang their praises! Thanks for this video please keep making more; you are helping me out so much!
Great video, great explanations. Been coding UI since Java/Swing days (yeah, a long time ago) and have always preferred code built UI vs "builder" tools when possible. Thanks for you r video and I look forward to watching more.
Really liked this video! Thanks for making the differences between the two a lot clearer. Can’t wait for the generics tableview video. Still trying to wrap my head around generics.
Brian, I follow your videos since I started coding iOS apps. So I have learned to love to code my uiviews programmatically. But the problem with this approach began when I started to work on companies that use storyboard. They defend the use of storyboard to keep your code clean and separate the View from Controller. And most of the ios programmers that I know prefer to manage the UI with storyboards. Interviewers always ask me if I know how to use the storyboard. I personally prefer the programmatically approach but companies and work colleagues not always will agree with you and this can make something cool become a nightmare.
Yeah it's understandable that certain companies prefer a particular style with the codebases. When the app is simple and doesn't do much, SB is probably going to be faster for most people just learning iOS programming. However for serious programmers, ones that want to the option to use React Native, coding is the easiest and most straightforward approach.
I honestly think storyboard is even worse for beginners. It might be good for following the intro tutorials, but I immediately ran into issues where I would get views that wouldn't show up or they would disappear for "no" reason. Doing it in code (following your videos) made me aware of what is actually happening with my views.
Actually I begin learning iOS app by coding all those UI parts and logic into one view controller. It pains when the app flow and requirement is getting complicated. Then , I shall choose using storyboards with serious consideration of flow. I tend to minimise the pages required and work it out. Loading storyboard sometimes makes compilation time longer.
For me, the biggest drawback of using storyboards is when we work on large project with many developer. We are unable to review storybooard file in PR, and usually just trust with screenshot of the layout (most of the time we dont have time to literally check the branch). So pure code helps a lot when we still support older than ios 13
Hi Brian. Thanks to your tutorials! Because of them I stopped using storyboard and I love it! The only problem that I have is the size of my ViewController. When I'm setting up my constraints to anchors in code and I have a lot of elements, it's taking a lot of space and get a bit messy. Is it a good idea to create separate file with code of setting up the views as an extension of my VC ? Thanks for your hard work !
Very interesting. Do you have examples of calling view controllers recursively. No navigation stack. I’m doing something like that now and may use your approach.
Both are fine. If projects get really big and complicated, maybe programmatic way is the way to go, but I suspect most apps don't get that to that point. Use whatever works. If you're at a stage where you have to ask which one to use, you're probably better off using storyboards. I would recommend using both. Use storyboard where it makes sense, but hand off some of the complicated controls to code, so that your storyboard always looks very neat. Consider making custom views and use them as modules in your storyboards. Also use storyboard references.
like as C++ style! great! my opinion is if you will make big projects with more than 50 different screens - best way is using storyboard... because after release you need support this app and storyboard makes it faster - you can remember what is there... or it can be easier for understanding implemented UI design by some another developers that will be support it after release. but if you will use typical screens with standard ui in app - this style is very good. I already have few apps without storyboard and some that using it... cant say that one of these method is better... it is depends of your goals
When I first started Storyboards where nice because it allowed me to quickly build application UIs. But ever since I started using AutoLayout Constraints, I seriously cannot go back to using Storyboards. One think I strongly dislike about storyboards is how much of a hassle it is to have your application be able to scale properly across all devices. AutoLayout constraints allows me to handle that issue very efficiently. Thanks for getting me onto Programmatically creating UIs
not sure, what you mean here. You can use AutoLayout constraints in SBs too. You can bound them to your code same way as you'd instantiate those programmatically. Actually, apart from time on creation of SBs vs. programmatically creating whole UI, I'm more concerned on run-time performance. I had a long discussion on StackOverflow, why conversion of programmatically created Views to SBs dramatically decreased performance of the app in runtime - obviously system does much more work on SBs, than you'd explicitly write in your code. IMHO: complex UI is much better manageable in SB (you really simplify your code, which tend to be huge if app is really complex by putting many things to metadata of the SB items). With Swift this is getting better than with ObjC, but still benefits of declarative programming are obvious with SBs. If there are run-time performance questions, I'd still stay with programmatic. It's getting better with newer versions of XCode and iOS, but still far behind your capabilities to express logic programmatically. Some can remember switch from Assembler to C, where last gave you chance to write simpler code, but much slower from performance point of view. In meantime compilers are optimizing sometimes better than a human will do :)
Great analysis of SB vs Code. Great thing about Xcode is that you can use both approaches together very easily. I think the decision really depends on how crazy your designers are at the company. For the simple views with a box here, a label there, SB or Code layout is trivial. However I've come across many designers that really think outside the box and come up with some really great ideas. As a senior engineer, you have power to veto these designs but as a junior/mid developer you either have to step up to the challenge or admit failure. For example, you might want to enlarge a button while dragging and at the same time fade and enlarge the background image with a parallax effect. If all you know is the SB, this task will be impossible.
Code go go go! Great vid. Was listening earlier to the discussion between Ray Wunderlich and other developers on the topic. Really really interesting. Just search for "xib vs code vs storyboards"
Great video Brian! I've never used the .init() method before for an initializer, thanks for teaching me something today! That seems to be a better way to work with code competition, most of the time it fails to work for me when I'm passing arguments to functions.
Yeah Xcode is horrible at autocomplete when it comes to strange syntax territory. I have a feeling Swift 5 has a good chance of breaking this .init auto completion.
Hi Brian what should be the order of your courses on your website if i know the basics should it be Basic Kindle Course -> Core Data -> Instagram or differently ??? Thanks :)
Hey Koko, the Core Data and Instagram course can be taken separately since they use different technologies. Both course offer quite different UI architecture so I'm sure you'll learn a lot from both.
Hi Brian, is there any autolayout XCode plugin that can automatically do the layout constraint automatically ? just curious tho. Another question is, in term of building an app, which way are you recommending us to do? Programmatically or by using story board ?
Just love the way you code without using storyboard...simply awesome...would love to take a course regarding apps like Tinder which uses pagination for data. Any thought on that?
Awesome video as usual...I am on the path of replacing storyboard with a programmatic approach..Its hard but will reach there soon!...A request from me Brian..Can you make a separate video about implementation of NSOperationQueue and GCD...I know you have covered these topics in your videos in between but i did not have time to check it all out...Thanks!!!
Whats the best way of taking a programmatic approach to learning? I know a lot of front end and just connected the dots on the commonalities between swift and html/css/js. Creating buttons and creating their actions have been difficult
Hey cool video I‘d like to ask how you manage to type without looking at the screen? Maybe 10 finger system but i suck with the brackets any tips for coding 10 finger system?
It seems like where you really save time is when you have to edit the cells and change them up. Also the storyboard sometimes does weird things. I set up the horizontal stack view just like yours and set the constraints the same way you did but the cells looked a bit different in the first UITableView. Hopefully I can go without the story board in the future. Unlike some I really liked this video thanks!
I'm joining a company that has an existing project that is already using storyboards... I've been using Xcode without storyboards for the past 2 years :/
SnapKit is a great library. I've used it in past projects and it works fine. However it doesn't follow the standard conventions of UIKit anchors and constraints. In the future I might start using it for videos, but it's another hurdle for beginners to learn in order to get started.
You'll also run into compatibility issues, for example using Xcode 9.1 github.com/SnapKit/SnapKit/issues/491 You don't always want to be at the mercy of pods being updated.
Hi Brian, regarding my previous question on the other video about passing data from one controller to another. In the destination controller I declare a variable then instantiate an instance of that controller in the origin controller to access the variable and then point my data to that variable. Then push to the controller?
Thanks man for impressive stuff. I have learnt a lot from your videos. I want to ask something about Localization of IOS Apps. can you show a master class to your fans? it will be so great if we can translate apps into multiple languages
Hey Brian, What backend service do you recommend beginner iOS developer to learn when he wants to build his first app requiring backend? Anything except CloudKit because I want to potentially take up Android just in case I want to develop it in Android as well.
Yeah I wouldn't recommend CloudKit either since its such a locked down system. I personally think NodeJS is a good choice as a beginner backend language. Hopefully I can come out with a course for this in due time.
Hey Brian! I've only dabbled in HTML and CSS previously, and want to learn Swift - tried a Udemy course but I didn't like the teaching style. I really like your no-storyboard approach and I'd really like to learn the basics from you if possible. Do you use this same method in your iOS Basic Training Course, and can I jump right into it if I'm a total beginner at Swift? Thank you!!
Hey Ally, yeah the no storyboard approach definitely helps answer a lot of questions behind all the mysteries of storyboards. The Basic Training course teaches everything through code and should be quite straightforward to follow if you have some slight programming knowledge.
great tutorial. you mentioned about generics, all i know about it is : generic can make a class type like array or dictionary, which accept all generic types inside , and that is it, have no idea how to use it, whenever Mr.brian you got time, please make a tutorial explain it more in detail, "' Generic for Dummies" , thanks
Hi! Could someone point me a course or book where I can learn swift programmatically from start to finish? All the courses I researched use only the storyboard. Thank you all! Thank you Brian!
Storyboards are wrong. I’m rewriting now app from Objective-C to Swift. I can do this as I want so first time ever I can do this without Storyboards. I have similar extension for UIView even with shorter syntax. It depends on names for functions however only. Generics you’ve presented will solve my case for base implementation of view models, view controllers and flow controllers. So now it will be rocket science.
But I have problems with generics in my MVVM architecture. If someone can help then please visit: stackoverflow.com/questions/53539605/how-to-declare-base-classes-in-swifts-generics
I like your 'code' approach but there is a way to get rid of this segue part of code, you can simply Refactor VC to SB and then voila, you can make VC from newly created SB and implementation will look almost the same either for code or IB solution.
Yes you are right it could be painful and dont get me wrong I love to code but on the other hand I feel like IB allow us to prototype nice looking app much faster but I can be wrong because I am fairly new in iOS. Anyway I really love your work, thanks!
This looks like an unfair comparison to me. You wrote and implemented all the data source from the ground up in the Storyboard run but use your existing code in the code run. Why didn’t you also use that existing code in the Storyboard run too? I think that would save a lot of time in the Storyboard run
How does one reuse existing storyboard code? Do you mean copying and pasting all code from another file? This is a common bad practice that leads to bad design and what eventually turns into massive view controller.
I understand your point but my point is that this is an unfair comparison. Your title is which one is faster but what you did for the code run would reduce the time to implement it by a lot. If your title saying that which one is faster then I think this video should shows the comparison where both runs should share the same factors So if you implement the data source methods for the Storyboard run then you should do that in the code run too. Or if you want to subclass your existing Generic subclass in the code run then you should also do that for the Storyboard run. I think it’s misleading by doing what you did in your video
You think I like to switch from sb to my controllers by millions of annoying clicks? I just have NO IDEA how to programically set up views ! Love your tutorials, but I am a new iOS guy and only can achieve something by using sb. But one day, if I was familiar with sb, i would kick it out. By the way, how to successfully do autolayout without physically viewing the contents inside a view? That's sounds like a magic and you literally manage to do it. OMG.
Believe it or not all websites are created using straight css and html code. There is no visual representation of this and the internet has survived many decades.
@@LetsBuildThatApp As a new iOS Dev Learner, starting with the IB makes me more comfortable. However, once I am stick to it, I would follow your steps and destroy the storyboard. I started to build a small app last week and spent all the time to get myself familiar with UITabBarController, UISplitviewController, how to make tableview which is embedded inside a scrollview not scrollable, etc. All about UI stuff. BUT I WON"T GIVE UP. Cheers
Hello Brian great video. But just a bite worried about your approach of creating a Swift file for your tableview controller, and then go ahead and delete the import Foundation, then import UIKit and then make the class conform to the uiviewcontroller or uiviewcell etc.. would did not be simpler and quicker by rather just selecting the Cocoa Touch Class file instead of plain Swift file? Just a view, but I admire your work a lot and learn a lot from it as well
Yeah you get a bunch of junk with subclass UITableViewController and UICollectionViewController. Moreover, as a developer you should be fully aware how and what subclassing does. Finally, you'll be surprised how much easier it is to understand thing by simply watching someone type it out, regardless of how trivial it seems.
You could have been a little more fast if you used cocoa touch class instead of swift file Also that Generic TableView code really caught my eye .! Would really love an explanation on that soon 😄
Storyboard vs Code SpeedRun - Which is Faster? Faster to create? Faster to maintain? Runs faster on the CPU so there are more clock cycles left for other tasks?
So I only just started coding apps and of course all the tutorials thus far have been using Storyboard, but this makes me want to rebel and start learning the programmatic approach lol. Get rid of the bad habit before it fully develops, you know?
I really like the fluidity of your videos and commentary but I have to say this feels like a very disingenuous comparison. What about: 1) If you are implementing more complex UI's or simply testing different hierarchies/layouts, having to compile and run for every little change adds up a ton of time especially as a project grows larger. 2) You don't have to use segues in IB/Storyboards, you can use the same approach you used in the code section without a problem. That said, your criticism of segues rang a little hollow when nearly the exact same code steps are required either way. 3) Using custom/generic views is just as easy and perhaps even better in IB thanks to IBInspectable and IBDesignable. 4) What about newcomers to a project? No matter if you are proficient with a code-only approach, to get a sense of the app structure and flow you still need to crawl through all code that creates a transition or run the app and poke at everything; more than likely both. With storyboards you can get a bird's-eye view of the entire app in far fewer files (most often just one).
Your arguments make a lot of sense on the surface, everything just seems easier with visual editors. I think an honest question you have to ask yourself is, why aren't websites built like this? Why do we have CSS and responsive layouts? Shouldn't the entire internet of websites use drag and drop tools? Editing html is much harder if I have to dive into the code and figure out where each component is right? Why can't I just click on some toggles and switches and let the magic handle itself? Interesting topic nonetheless.
Hey, thanks for replying and so quickly, that's pretty awesome! I do find it odd that you say my argument makes sense on the surface (meaning not so much past the surface) but then don't bother actually trying to prove it. I also find your web argument specious as well. Your argument is that an ancient technology used the same approach since way back when and so it's better or at least just fine? Here's my view on this perspective: A) The Web building blocks (namely HTML and CSS) are ancient tech (in tech timeframes anyway). They are so widespread and tangled with their platform, that they still being used is more a product of necessity than convenience. B) The Web in its most basic form does not require building and running. In modern web, you could say there is such a building/running step but even then live-reload technologies make it just as seamless as raw HTML and CSS (even better than that actually). C) Every web front-end tool, library, and framework out there exists precisely to ameliorate the deficiencies that code-only UI/UX production suffers from. And there are tens if not hundreds of thousands of these because so many people see that HTML and CSS by themselves are not sufficient anymore. D) Some of the biggest plugins/functionalities for graphic design suites (e.g. Illustrator, Sketch, Photoshop, etc...) are ones that can produce approximate HTML and CSS for easy transition from graphic design to code. E) The biggest web platforms out there are are either focused around more graphical and drag-and-drop front-end interfaces or have them as a big part of their selling point. I don't know, man. I don't see what you are seeing.
The main point is that if you open up many codebases, you’ll find thousands and thousands lines of code. A lot of this is simply drawing out the UI whether it be html or other drawing code. The advantages of code is that it is structured and rules are easy to enforce. For example testing and dependency injection of components is much easier. Of course the rules for small projects vs large corporations differ greatly. Large companies have stricter demands that allow for easier iterations. Doing everything manually by hand is such a chore
Not sure what pointing out that a lot of codebases doing code-based drawing (in other languages & platforms, no less) does for the argument to do it for iOS. I still find this point very strange to be honest. I mean, I already exemplified why I think comparing to HTML and CSS is not a workable comparison and even proves my point further. Now, the other advantages of code-focused approaches I can get more behind and those could be legitimate reasons to choose that approach, but this just brings me back to my original point that this video is kind of disingenuous. For the reasons I mentioned originally, which you didn't really contest, in most real-world scenarios there are factors that will likely erase any seeming speed advantages between the two approaches when you work on a full project, big or small. Don't get me wrong man, I think anyone should take whatever approach they prefer, but that should be by acknowledging all the pros and cons. My point is simply that a speed comparison that does not address large factors in each approach that affect development speed over the course of an entire project, big or small, is not a proper comparison.
Well obviously this is a super short video, it was only meant to jog the brain of people doing storyboard development. The point of the video is to also demonstrate that with the proper in house tooling, you can pull up and entire iOS screen with just a few lines of code. This screen would also contain the guidelines established by your UI/UX team as the code enforces the proper designs. Moreover, views such as cells could be reused across multiple view controller screens in your app without IB duplication. And one last point, you can automatically inherit error handling, scroll behavior, and other common components through a base component that drives your screens. Having built bigger and bigger projects, these concepts are what drive the more interesting parts of development. I suggest watching a couple of the videos from the objc.io guys, they go into great detail on how they handle size classes and trait collections through some great coding techniques. Thanks for the discussion, as with many videos its horribly bias towards the intention of the creator.
For me on the one hand storyboard makes it easy to understand the overall surface level view application flow ... on the other hand you can accomplish the same thing with sketch files. Seeing the code means I can catch constraint errors and other view errors in code. Those code errors are harder to catch when they are spread out across xml jibberish that gets pushed up to github. Even now I feel storyboards are more marketing to get new developers in the door than anything else. I gave up dreamweaver for a reason...only to have it shoved down my throat in iOS when barely any large scale apps use it.
Indeed, any software organization out of the prototype phase will be much better suited for coding view and doing things dynamically. Its unfortunate that all tutorials online are done through the storyboard, beginners never get to truly tap into the power of coding.
Lets Build That App I wish I had watched your video tuts much sooner than I did. They are so well done. I love iOS in code but I do love the idea of nibs and storyboards but I end up not liking it when I actually try to do it especially when building apps. I think storyboards should be writeable by actual humans for me to like them I think.
Brian, even if it's a nice video, I don't think you have enough ui graphic items in your layout to really make use of interface builder here. It would be more relevant if you took an existing app and try to redo its layout by code and interface builder
See, the problem I have with one of the criticism against storyboards is your use of segues. Every companies I've worked for, who uses storyboards, never used segues. When working with a large project with 50+ developers, where people come and leave every now and then, having storyboards allows much faster onboarding and easier rationalization of the flow of the application. In the programmatic approach, you have to run the app, which can take up to 5+ mins each time you recompile, depending on the size of the app. Your example above is cool when it's your own personal project.
Well, imagine working on a React Native project at Uber, AirBnb, Facebook, or Instagram. How do you suppose the engineers there rationalize all the view logic?
True, nonetheless all the view logic is written in HTML which requires a human brain to parse. I really enjoy using XIBs to visualize iOS designs and see changes in real time. Can't have it all I guess.
Which is better is really the wrong question. You should be asking which is a better fit for me (or my team). If you're a one man shop, the code only approach is probably fine but if you're working on a larger codebase with multiple team members in several roles, you'll quickly find that storyboards are more maintainable. Translators can easily change labels without touching code, designers can move things around and tweak look and feel without touching the code and you can generally hire more junior developers when your team is using storyboards. If you don't need that kind of separation, code only is great. if you do, storyboards are too. granted, you could get most, if not all the storyboard advantages i mentioned in other ways as well, but it'd probably be more than a bit more difficult. All in all, Apple does allow us both ways of doing things for very good reasons.
I often hear people tell me they allow designers to touch storyboards and application code. I've never been at an organization that needed or allowed this. Isn't it really scary to let a non developer introduce critical bugs in your storyboard? A lot of places wont even let interns merge code onto master without heavy code reviews.
Thanks man! impressive stuff. But you could just as easily make so-called "cheat" classes for storyboards too. I have such generic classes for firebase and some buttons with some @ibdesignable vars for whenever I have to make similar buttons and such. Regarding the segues though I agree, and you don't have to use them. you can just use storyboard to keep everything visual and easy to remember and write your transitions programmatically. sort of the best of both worlds
Beginner here. I never thought of keeping the storyboards then using code for transitions instead of segues. That seems like a great advice. Thank you! I'll try it out next time!
@Lets Build That App well, anything would be great but i want to learn how to create a widget in the notification bar. For example, when you are using spotify or pandora, on the notification bar you see the options: *play, stop or skip a song*. I want to learn how to do that so the user can interact with my app through there.
I get the point and all but it does feel like in the storyboard side you did a lot more explaining and jumping around than is needed. As well can it truly be considered a “speed run” when you already have some of the files you need for program view done? That’s like me doing a speed run of Pokémon red vs Pokémon blue but in the blue version starting at a save were in two gyms in. I feel like there should be a disclaimer saying as an experience programmer I have these files sitting around l, although anyone doing it the first time would have to make these files themselves so their times will be horrible off.
Good points but this video was shot from the perspective of a real world dev scenario. No honest developer starts from scratch, we rely on a bunch of libraries to make our jobs faster and easy to write clean code. Furthermore I can type out all the code in this video in about 2 mins if I didn’t explain or run the simulator until the last bit of code.
trying to choose between (More clicks && less typing) vs (More typing && less clicks) 🤔 ... But great video anyways, this shows how powerful generics and programmatically can be. Keep up the good work!
yeah seems like you get more control in code since you can remember you did everything and know what is what, I also dislike seeing strings typed everywhere and it is the no. 1 cause of bugs or untraceable errors. What I do now is keep all the cell id's and segues in an enum class. Looking forward to taking your course soon tho, I'm interested in doing things in code as well.
his method might actually be less clicks and less typing in the long run but i would have to run experiments or go back and keep track. if you copy pasta the extensions and understand how to use them then they are a great weapon to have. i love this dude cuz i just learned something new
I think the biggest problem of storyboards is the over usage of them. Someone put EVERY view controller in the main storyboard and this approach makes the storyboard itself totally unusable. It’s a common usage put table view cells directly in the view controller, so storyboards contains cells too. And segues in my opinion are evil. My approach is to have several storyboards that contain related view controller, single xibs for cells and custom reusable views. Then I created a library to have more uiview properties in interface builder (shadow color, rounded corners etc) so I have always a good idea of what I’m drawing. Finally I don’t use segue.
Please sir, make a full tutorial on blogging from start to end. I would love it if it will be a series and it should include how could earn from blogging?
i think it has always been a series of Scrollable and non scrollable parent views with Sectioned Nested StackViews. So I made a Generic Project Template I can always use, where the things I only need to change are the data model, the cell properties, the XIB of the cell, the request parameters and just handle all the events and business logic in the view controller. I Inconsistent placement of our codes and having to jump from one file to another until we forget what we were actually looking for is one of the major reason we tend to become slow. Not only that is our code becomes spaghetti code and un maintainable which in turns App not scalable enough to last atleast 5 years. For me, I think the best way is to invest on creating a template that you can always reuse. Right now, I just kept copy pasting my codes however complex the ui is because everything are already setup using behavioural driven mvvm pattern. Just sharing my opinion, hoping anyone might find this helpful and at the same maybe I'm wrong and someone can help me :)
Isn't this kind of skewed because you had to create the app before the video for the example. Therefore the method you used for the example would be quicker because you had already done this project in that format once before. Still great video, just picked up on this flaw while watching.
Well, the functionality in the app isn't anything new or advanced. I've built this out both in code and storyboard a ton of times and its just a bunch of busy clicking for me now. Anyhow, the idea is to show people how little code it takes to put things together very cleanly.
Okay, that makes sense. If a person is an expert at a specific thing, then it truly does show the advantage to one method over another (I am, also, a programmatic iOS dev - not a fan of storyboard). I do want to say, I really appreciate you responding to my comment. It shows real integrity and a true belief in the work that you do. I have always liked your videos, but now I have a much greater respect for your work. Great job Brian!
After years of React Native and experimenting with Swift, I don't wanna go back. No Android support out of the box but hey.. at least it's lightning fast on iOS! And there's not as many styles as before. Yay!
Less code, less bug. The storyboard (or xib files) itself hides so much code (rendering things, auto-layout handlers, properties settings, etc.) Now, what you do is to re-write what the storyboard hide. I used to think on your way in my previous project. The result is : writing is faster, but end up with tons of code. In my current project, I do opposite by conversing all codes to possible bindings in storyboard or xib. As result, code is short, looks clean and easy to maintain. Of course, each approach has pros and cons. 100% agree with you : "code revisioning is much easier with your way", but the trade-off is we have to write tons of code.
In a lot of larger projects, your code repo will contain a ton of reusable components for your lists and cells that follow company styles/guidelines. These components will take 2 seconds to create in code and will be much easier to edit en masse compared to opening each and every storyboard file. You'll start to understand this once you start working at a sizable software organization.
Each reusable component as you said can be implemented in xib files. Even, better by using IBDesignable, you can embed one xib into another xib file. As result, another component can be created, based on a component which is implemented by using xib files. Opening a xib file, you can see right away what the component looks like. Other developers can read and understand your code better. I never say your approach is wrong. Anyway, I admit that it's good sometimes.
Yep, I think I use XIB files more now since they're much easier to look at and understand when I go back to edit the UI. Keeping the view files isolated in IB is quite nifty.
Would love to know how did you made those Generics table views. :)
I'll be sharing how to make GenericTableViewController very soon since it greatly reduces the tedious list creation process. This class will also be used in the latest Podcasts course to speed things up significantly.
Lets Build That App I was thinking if you would have used them in Instagram course, codebase would have been so much smaller. :)
When is podcast course coming by the way?
Yes indeed, live and learn. Trying to improve things one thing at a time in 2018. Thanks for the support and feedback. I'm recording the demo video for podcasts course today.
Amazing! Can’t wait to watch it. Thanks to you actually. Been following you since Feb 2016. It’s been an year. My skills have improved vastly! 😀 Thank you for everything Brian.
I had some doubts regarding my iOS dev, can I contact you on email regarding them?
You can hit me up on Twitter @buildthatapp.
I was REALLY hoping you would just copy/paste a similar tableView you've created in a previous project, and then just tweak that for the programatic part. Would have been hilarious. "Storyboard took 11 minutes... programatic... 2 minutes, lol. I'm half-kidding of course, but a nice bonus to 100% programmatic UI elements is the possibility to reuse similar elements between projects (with some tweaking of course). Things like custom buttons, views, etc...
Haha that would've been the ultimate cheat. I find the great thing about code is that I can eliminate all the tedious busy work that comes with creating a basic list and one cell. In addition, there is no need for these strange segue/cell identifiers maintained in a separate file. Once the project grows, a bunch of common components then gets abstracted away with their own styling for reusability which is killer.
Lets Build That App a solution I like is to create xibs for views and cells which need to be reusable. You could also make their class designable so you can see the cell display inside a storyboard. For reuse identifiers I find it’s best to just have an identifier in the cell class which is a strong describing self, this avoids magic strings outside the storyboard 👍
Few comments :
1. Using storyboard is to visualise the flow of app when action is done from one page. If you focus on business flows while development, that perfectly suits your mind since we can map the business flows directly to storyboards.
2. If your app does many tasks and flows are complicated, I shall use multiple storyboards instead of xib / code. Either of this we have to bear the flow in mind. I often use code to control UI visibility and delegate actions but not to control every part including constraints and colours, e.t.c.
3. From my experience, I have tried pure codes to set UI positions and properties on view controllers. I have to search keywords of methods to fix bugs since the lines of codes are more clustered to one controller file. Of course we can split the delegates and create models but still a lot when the business flow complicates.That makes longer time for user to search and revise logic parts. I use view controllers to control UI actions and execute networking actions.
That makes to one question : What does the App used for and which major actions are crucial for app and which are optional. If some tasks or requirements are optional , delegate those to backend system instead.
@@larrystreehouse1124 Doesn't storyboard become tedious to manage when there is a whole organization working? Also version control becomes an issue right?
Literally no one is making tutorials in code for those of us who prefer that. Your UA-cam channel is a godsend for me. Learning the code helped me to understand the storyboard. I continue to be amazed as to why Apple and others don’t have a beginner code path that focuses on the code and building the UI in the storyboard.
Nice to see another video of Brian! Yes when things become more complicated you get screwed by sb.
You videos are getting better and better !! They are very helpful !!! Very useful!! Keep doing the great work!
I learned generics in my hardest college course. I was wondering how they would help my iOS career. Now I am starting to see why my professor sang their praises! Thanks for this video please keep making more; you are helping me out so much!
Great video, great explanations. Been coding UI since Java/Swing days (yeah, a long time ago) and have always preferred code built UI vs "builder" tools when possible. Thanks for you r video and I look forward to watching more.
Really liked this video! Thanks for making the differences between the two a lot clearer. Can’t wait for the generics tableview video. Still trying to wrap my head around generics.
As someone coming from web development this approach makes much more sense than using the storyboard.
Absolutely BRILLIANT! Thanks, Brian. Super-informative - love your programatic, generic-based approach!
Gotta love em Generics, one of the most powerful features when used correctly.
One of the greatest videos for intermediate swe
Brian, I follow your videos since I started coding iOS apps. So I have learned to love to code my uiviews programmatically. But the problem with this approach began when I started to work on companies that use storyboard. They defend the use of storyboard to keep your code clean and separate the View from Controller. And most of the ios programmers that I know prefer to manage the UI with storyboards. Interviewers always ask me if I know how to use the storyboard. I personally prefer the programmatically approach but companies and work colleagues not always will agree with you and this can make something cool become a nightmare.
Yeah it's understandable that certain companies prefer a particular style with the codebases. When the app is simple and doesn't do much, SB is probably going to be faster for most people just learning iOS programming. However for serious programmers, ones that want to the option to use React Native, coding is the easiest and most straightforward approach.
I'm a big fan btw. and I'm very excited to see your video about generics. Thank you for the answer.
If you enjoy this channel, please consider LineByLine as another resource for your learning!
I honestly think storyboard is even worse for beginners. It might be good for following the intro tutorials, but I immediately ran into issues where I would get views that wouldn't show up or they would disappear for "no" reason. Doing it in code (following your videos) made me aware of what is actually happening with my views.
Actually I begin learning iOS app by coding all those UI parts and logic into one view controller. It pains when the app flow and requirement is getting complicated. Then , I shall choose using storyboards with serious consideration of flow. I tend to minimise the pages required and work it out. Loading storyboard sometimes makes compilation time longer.
Amazing as always. Excited to learn how to create generic tableview/files.
For me, the biggest drawback of using storyboards is when we work on large project with many developer. We are unable to review storybooard file in PR, and usually just trust with screenshot of the layout (most of the time we dont have time to literally check the branch). So pure code helps a lot when we still support older than ios 13
Hardcoding is HARD, but it is cool :)
If you enjoy this channel, please consider LineByLine as another resource for your learning!
Hi Brian. Thanks to your tutorials! Because of them I stopped using storyboard and I love it! The only problem that I have is the size of my ViewController. When I'm setting up my constraints to anchors in code and I have a lot of elements, it's taking a lot of space and get a bit messy. Is it a good idea to create separate file with code of setting up the views as an extension of my VC ? Thanks for your hard work !
Very nice and eye opening tutorial, thanks!
Very interesting. Do you have examples of calling view controllers recursively. No navigation stack. I’m doing something like that now and may use your approach.
Thank you so much. God bless you for the work you put here~ I'm your subscriber and a fan for life~
Both are fine. If projects get really big and complicated, maybe programmatic way is the way to go, but I suspect most apps don't get that to that point. Use whatever works.
If you're at a stage where you have to ask which one to use, you're probably better off using storyboards. I would recommend using both. Use storyboard where it makes sense, but hand off some of the complicated controls to code, so that your storyboard always looks very neat. Consider making custom views and use them as modules in your storyboards. Also use storyboard references.
I actually feel more powerful when I do everything by code! Code only forever :D
like as C++ style! great!
my opinion is if you will make big projects with more than 50 different screens - best way is using storyboard... because after release you need support this app and storyboard makes it faster - you can remember what is there... or it can be easier for understanding implemented UI design by some another developers that will be support it after release.
but if you will use typical screens with standard ui in app - this style is very good.
I already have few apps without storyboard and some that using it... cant say that one of these method is better... it is depends of your goals
Hey Brian, amazing tuto...in this moment i need make a choice about storyboard and uiviews programmaticly and you help me.a lot
When I first started Storyboards where nice because it allowed me to quickly build application UIs. But ever since I started using AutoLayout Constraints, I seriously cannot go back to using Storyboards. One think I strongly dislike about storyboards is how much of a hassle it is to have your application be able to scale properly across all devices. AutoLayout constraints allows me to handle that issue very efficiently. Thanks for getting me onto Programmatically creating UIs
not sure, what you mean here. You can use AutoLayout constraints in SBs too. You can bound them to your code same way as you'd instantiate those programmatically.
Actually, apart from time on creation of SBs vs. programmatically creating whole UI, I'm more concerned on run-time performance. I had a long discussion on StackOverflow, why conversion of programmatically created Views to SBs dramatically decreased performance of the app in runtime - obviously system does much more work on SBs, than you'd explicitly write in your code.
IMHO: complex UI is much better manageable in SB (you really simplify your code, which tend to be huge if app is really complex by putting many things to metadata of the SB items). With Swift this is getting better than with ObjC, but still benefits of declarative programming are obvious with SBs.
If there are run-time performance questions, I'd still stay with programmatic. It's getting better with newer versions of XCode and iOS, but still far behind your capabilities to express logic programmatically. Some can remember switch from Assembler to C, where last gave you chance to write simpler code, but much slower from performance point of view. In meantime compilers are optimizing sometimes better than a human will do :)
Great analysis of SB vs Code. Great thing about Xcode is that you can use both approaches together very easily. I think the decision really depends on how crazy your designers are at the company.
For the simple views with a box here, a label there, SB or Code layout is trivial. However I've come across many designers that really think outside the box and come up with some really great ideas. As a senior engineer, you have power to veto these designs but as a junior/mid developer you either have to step up to the challenge or admit failure.
For example, you might want to enlarge a button while dragging and at the same time fade and enlarge the background image with a parallax effect. If all you know is the SB, this task will be impossible.
Great, nice video... Did you post the generics video?
good productivity extensions, bravo. subbed
Thanks to Brian I’ve been 90% storyboard free for 4 months now!
Code go go go! Great vid. Was listening earlier to the discussion between Ray Wunderlich and other developers on the topic. Really really interesting. Just search for "xib vs code vs storyboards"
If you’re a GOOD programmer, code is faster and amazing real world practise. End of that story. #deadhorse
Great video Brian! I've never used the .init() method before for an initializer, thanks for teaching me something today! That seems to be a better way to work with code competition, most of the time it fails to work for me when I'm passing arguments to functions.
Yeah Xcode is horrible at autocomplete when it comes to strange syntax territory. I have a feeling Swift 5 has a good chance of breaking this .init auto completion.
Hi Brian what should be the order of your courses on your website if i know the basics should it be Basic Kindle Course -> Core Data -> Instagram or differently ??? Thanks :)
Hey Koko, the Core Data and Instagram course can be taken separately since they use different technologies. Both course offer quite different UI architecture so I'm sure you'll learn a lot from both.
Useful video (cheat code) for generic tableview. Want more video about GenericTableVC and GenericCollectionVC.
Hi Brian, is there any autolayout XCode plugin that can automatically do the layout constraint automatically ? just curious tho. Another question is, in term of building an app, which way are you recommending us to do? Programmatically or by using story board ?
Whichever solution you are comfortable with, I recommend that one.
Just love the way you code without using storyboard...simply awesome...would love to take a course regarding apps like Tinder which uses pagination for data. Any thought on that?
Awesome video as usual...I am on the path of replacing storyboard with a programmatic approach..Its hard but will reach there soon!...A request from me Brian..Can you make a separate video about implementation of NSOperationQueue and GCD...I know you have covered these topics in your videos in between but i did not have time to check it all out...Thanks!!!
Whats the best way of taking a programmatic approach to learning? I know a lot of front end and just connected the dots on the commonalities between swift and html/css/js. Creating buttons and creating their actions have been difficult
Great tutorial! Hope to see you in your video about generic table view :)
SwiftUI vs Code when is going to come ?
Hey cool video
I‘d like to ask how you manage to type without looking at the screen? Maybe 10 finger system but i suck with the brackets any tips for coding 10 finger system?
Typing the keys like numbers and brackets gets easier the more you practice. Maybe an American style layout makes it easier.
It seems like where you really save time is when you have to edit the cells and change them up. Also the storyboard sometimes does weird things. I set up the horizontal stack view just like yours and set the constraints the same way you did but the cells looked a bit different in the first UITableView. Hopefully I can go without the story board in the future. Unlike some I really liked this video thanks!
I'm joining a company that has an existing project that is already using storyboards... I've been using Xcode without storyboards for the past 2 years :/
You’ll find it quite easy to get over that storyboard hump now that you understand exactly what code does
Lets Build That App I’ll do my very best to try get them to convert to one us of! Haha
Hi Brian, what do you think of SnapKit? Why would you basically recreate SnapKit style methods with your extensions if you could just use SnapKit?
SnapKit is a great library. I've used it in past projects and it works fine. However it doesn't follow the standard conventions of UIKit anchors and constraints. In the future I might start using it for videos, but it's another hurdle for beginners to learn in order to get started.
You'll also run into compatibility issues, for example using Xcode 9.1 github.com/SnapKit/SnapKit/issues/491
You don't always want to be at the mercy of pods being updated.
Hi Brian, regarding my previous question on the other video about passing data from one controller to another. In the destination controller I declare a variable then instantiate an instance of that controller in the origin controller to access the variable and then point my data to that variable. Then push to the controller?
Simply verify your code in Xcode
can we use both approaches simultaneously I mean programming and storeyboard?
Thanks man for impressive stuff. I have learnt a lot from your videos. I want to ask something about Localization of IOS Apps. can you show a master class to your fans? it will be so great if we can translate apps into multiple languages
Hey Brian, What backend service do you recommend beginner iOS developer to learn when he wants to build his first app requiring backend? Anything except CloudKit because I want to potentially take up Android just in case I want to develop it in Android as well.
Yeah I wouldn't recommend CloudKit either since its such a locked down system. I personally think NodeJS is a good choice as a beginner backend language. Hopefully I can come out with a course for this in due time.
Id say firebase too
Hi, Brian. It would be nice to hear more about your GenericTableVC.
I’ve prepared a video for it since I’ll be using it a lot in future courses
Hey Brian! I've only dabbled in HTML and CSS previously, and want to learn Swift - tried a Udemy course but I didn't like the teaching style. I really like your no-storyboard approach and I'd really like to learn the basics from you if possible. Do you use this same method in your iOS Basic Training Course, and can I jump right into it if I'm a total beginner at Swift? Thank you!!
Hey Ally, yeah the no storyboard approach definitely helps answer a lot of questions behind all the mysteries of storyboards. The Basic Training course teaches everything through code and should be quite straightforward to follow if you have some slight programming knowledge.
If you enjoy this channel, please consider LineByLine as another resource for your learning!
Really nice extension.
oh shit this guy still alive
Haven't kicked the bucket yet.
great tutorial. you mentioned about generics, all i know about it is : generic can make a class type like array or dictionary, which accept all generic types inside , and that is it, have no idea how to use it, whenever Mr.brian you got time, please make a tutorial explain it more in detail, "' Generic for Dummies" , thanks
Hi! Could someone point me a course or book where I can learn swift programmatically from start to finish? All the courses I researched use only the storyboard. Thank you all! Thank you Brian!
Bro we get it you hate storyboards I’m trying to switch but it’s an addiction
I'm like 90% sure he is just making this video so he has a place to send the 1k people every day, that ask him why he doesn't use storyboards.
Kevin van den Hoek they’re easy for making views with lots of sub views and weird constraints. I don’t really know the constraint syntax at all😂
Kevin van den Hoek yeah I definitely think pure code is the best way to go... I’m probably gonna try and learn it soon
It would be very interesting how long you would take to do this in SwiftUI. Good video btw👍🏼
Thanks, great video though I do prefer storyboard to code
Storyboards are wrong. I’m rewriting now app from Objective-C to Swift. I can do this as I want so first time ever I can do this without Storyboards. I have similar extension for UIView even with shorter syntax. It depends on names for functions however only. Generics you’ve presented will solve my case for base implementation of view models, view controllers and flow controllers. So now it will be rocket science.
But I have problems with generics in my MVVM architecture. If someone can help then please visit:
stackoverflow.com/questions/53539605/how-to-declare-base-classes-in-swifts-generics
Great video! Thank you
Hope the "Generic Code" video will come out soon, because I do not know how fast it will be to create a lists ^_^
I like your 'code' approach but there is a way to get rid of this segue part of code, you can simply Refactor VC to SB and then voila, you can make VC from newly created SB and implementation will look almost the same either for code or IB solution.
Yeah, more Storyboards in your projects. Trying to add and maintain features with visual editors....always a pain in the butt.
Yes you are right it could be painful and dont get me wrong I love to code but on the other hand I feel like IB allow us to prototype nice looking app much faster but I can be wrong because I am fairly new in iOS. Anyway I really love your work, thanks!
really nice to compare i like.
Hi master, Do you have the specific video about generic code . Does it public ? Regards.
The code is in the project download
great ! . Thanks alot.
Good sharing, thank you :)
This looks like an unfair comparison to me. You wrote and implemented all the data source from the ground up in the Storyboard run but use your existing code in the code run. Why didn’t you also use that existing code in the Storyboard run too? I think that would save a lot of time in the Storyboard run
How does one reuse existing storyboard code? Do you mean copying and pasting all code from another file? This is a common bad practice that leads to bad design and what eventually turns into massive view controller.
I mean subclass the Employee Controller from your Generic Subclass like you did in the code run
Well yes but most newcomers never use the story board like this. This video just shows one way to expand outside of standard processes.
I understand your point but my point is that this is an unfair comparison. Your title is which one is faster but what you did for the code run would reduce the time to implement it by a lot. If your title saying that which one is faster then I think this video should shows the comparison where both runs should share the same factors
So if you implement the data source methods for the Storyboard run then you should do that in the code run too. Or if you want to subclass your existing Generic subclass in the code run then you should also do that for the Storyboard run.
I think it’s misleading by doing what you did in your video
Yeah this wasn’t meant to be a super scientific approach to timing. I think you’re looking into this a little too much. Sorry for misleading anyone.
You think I like to switch from sb to my controllers by millions of annoying clicks? I just have NO IDEA how to programically set up views ! Love your tutorials, but I am a new iOS guy and only can achieve something by using sb. But one day, if I was familiar with sb, i would kick it out.
By the way, how to successfully do autolayout without physically viewing the contents inside a view? That's sounds like a magic and you literally manage to do it. OMG.
Believe it or not all websites are created using straight css and html code. There is no visual representation of this and the internet has survived many decades.
@@LetsBuildThatApp As a new iOS Dev Learner, starting with the IB makes me more comfortable. However, once I am stick to it, I would follow your steps and destroy the storyboard.
I started to build a small app last week and spent all the time to get myself familiar with UITabBarController, UISplitviewController, how to make tableview which is embedded inside a scrollview not scrollable, etc. All about UI stuff.
BUT I WON"T GIVE UP. Cheers
Hello Brian great video. But just a bite worried about your approach of creating a Swift file for your tableview controller, and then go ahead and delete the import Foundation, then import UIKit and then make the class conform to the uiviewcontroller or uiviewcell etc.. would did not be simpler and quicker by rather just selecting the Cocoa Touch Class file instead of plain Swift file? Just a view, but I admire your work a lot and learn a lot from it as well
After you code for some time, you realize you pretty much want a blank file every time.
After you code for some time, you realize you pretty much want a blank file every time.
okay. but is there any specific reasons for ?
Yeah you get a bunch of junk with subclass UITableViewController and UICollectionViewController. Moreover, as a developer you should be fully aware how and what subclassing does. Finally, you'll be surprised how much easier it is to understand thing by simply watching someone type it out, regardless of how trivial it seems.
You could have been a little more fast if you used cocoa touch class instead of swift file
Also that Generic TableView code really caught my eye .! Would really love an explanation on that soon 😄
How do you handle constraint priority?
is there a way to use both same time ?
Storyboard vs Code SpeedRun - Which is Faster? Faster to create? Faster to maintain? Runs faster on the CPU so there are more clock cycles left for other tasks?
Yes, faster to write, like what we did in this video.
So I only just started coding apps and of course all the tutorials thus far have been using Storyboard, but this makes me want to rebel and start learning the programmatic approach lol. Get rid of the bad habit before it fully develops, you know?
I really like the fluidity of your videos and commentary but I have to say this feels like a very disingenuous comparison. What about:
1) If you are implementing more complex UI's or simply testing different hierarchies/layouts, having to compile and run for every little change adds up a ton of time especially as a project grows larger.
2) You don't have to use segues in IB/Storyboards, you can use the same approach you used in the code section without a problem. That said, your criticism of segues rang a little hollow when nearly the exact same code steps are required either way.
3) Using custom/generic views is just as easy and perhaps even better in IB thanks to IBInspectable and IBDesignable.
4) What about newcomers to a project? No matter if you are proficient with a code-only approach, to get a sense of the app structure and flow you still need to crawl through all code that creates a transition or run the app and poke at everything; more than likely both. With storyboards you can get a bird's-eye view of the entire app in far fewer files (most often just one).
Your arguments make a lot of sense on the surface, everything just seems easier with visual editors.
I think an honest question you have to ask yourself is, why aren't websites built like this? Why do we have CSS and responsive layouts? Shouldn't the entire internet of websites use drag and drop tools? Editing html is much harder if I have to dive into the code and figure out where each component is right? Why can't I just click on some toggles and switches and let the magic handle itself?
Interesting topic nonetheless.
Hey, thanks for replying and so quickly, that's pretty awesome!
I do find it odd that you say my argument makes sense on the surface (meaning not so much past the surface) but then don't bother actually trying to prove it.
I also find your web argument specious as well. Your argument is that an ancient technology used the same approach since way back when and so it's better or at least just fine? Here's my view on this perspective:
A) The Web building blocks (namely HTML and CSS) are ancient tech (in tech timeframes anyway). They are so widespread and tangled with their platform, that they still being used is more a product of necessity than convenience.
B) The Web in its most basic form does not require building and running. In modern web, you could say there is such a building/running step but even then live-reload technologies make it just as seamless as raw HTML and CSS (even better than that actually).
C) Every web front-end tool, library, and framework out there exists precisely to ameliorate the deficiencies that code-only UI/UX production suffers from. And there are tens if not hundreds of thousands of these because so many people see that HTML and CSS by themselves are not sufficient anymore.
D) Some of the biggest plugins/functionalities for graphic design suites (e.g. Illustrator, Sketch, Photoshop, etc...) are ones that can produce approximate HTML and CSS for easy transition from graphic design to code.
E) The biggest web platforms out there are are either focused around more graphical and drag-and-drop front-end interfaces or have them as a big part of their selling point.
I don't know, man. I don't see what you are seeing.
The main point is that if you open up many codebases, you’ll find thousands and thousands lines of code. A lot of this is simply drawing out the UI whether it be html or other drawing code.
The advantages of code is that it is structured and rules are easy to enforce. For example testing and dependency injection of components is much easier.
Of course the rules for small projects vs large corporations differ greatly. Large companies have stricter demands that allow for easier iterations. Doing everything manually by hand is such a chore
Not sure what pointing out that a lot of codebases doing code-based drawing (in other languages & platforms, no less) does for the argument to do it for iOS. I still find this point very strange to be honest. I mean, I already exemplified why I think comparing to HTML and CSS is not a workable comparison and even proves my point further.
Now, the other advantages of code-focused approaches I can get more behind and those could be legitimate reasons to choose that approach, but this just brings me back to my original point that this video is kind of disingenuous. For the reasons I mentioned originally, which you didn't really contest, in most real-world scenarios there are factors that will likely erase any seeming speed advantages between the two approaches when you work on a full project, big or small.
Don't get me wrong man, I think anyone should take whatever approach they prefer, but that should be by acknowledging all the pros and cons. My point is simply that a speed comparison that does not address large factors in each approach that affect development speed over the course of an entire project, big or small, is not a proper comparison.
Well obviously this is a super short video, it was only meant to jog the brain of people doing storyboard development. The point of the video is to also demonstrate that with the proper in house tooling, you can pull up and entire iOS screen with just a few lines of code. This screen would also contain the guidelines established by your UI/UX team as the code enforces the proper designs. Moreover, views such as cells could be reused across multiple view controller screens in your app without IB duplication. And one last point, you can automatically inherit error handling, scroll behavior, and other common components through a base component that drives your screens.
Having built bigger and bigger projects, these concepts are what drive the more interesting parts of development. I suggest watching a couple of the videos from the objc.io guys, they go into great detail on how they handle size classes and trait collections through some great coding techniques.
Thanks for the discussion, as with many videos its horribly bias towards the intention of the creator.
For me on the one hand storyboard makes it easy to understand the overall surface level view application flow ... on the other hand you can accomplish the same thing with sketch files. Seeing the code means I can catch constraint errors and other view errors in code. Those code errors are harder to catch when they are spread out across xml jibberish that gets pushed up to github. Even now I feel storyboards are more marketing to get new developers in the door than anything else.
I gave up dreamweaver for a reason...only to have it shoved down my throat in iOS when barely any large scale apps use it.
Indeed, any software organization out of the prototype phase will be much better suited for coding view and doing things dynamically. Its unfortunate that all tutorials online are done through the storyboard, beginners never get to truly tap into the power of coding.
Lets Build That App I wish I had watched your video tuts much sooner than I did. They are so well done. I love iOS in code but I do love the idea of nibs and storyboards but I end up not liking it when I actually try to do it especially when building apps.
I think storyboards should be writeable by actual humans for me to like them I think.
You'll really enjoy the XML editor in Android development then.
Lets Build That App im sure but maybe after I feel Ive mastered iOS development.
Brian, even if it's a nice video, I don't think you have enough ui graphic items in your layout to really make use of interface builder here. It would be more relevant if you took an existing app and try to redo its layout by code and interface builder
See, the problem I have with one of the criticism against storyboards is your use of segues. Every companies I've worked for, who uses storyboards, never used segues.
When working with a large project with 50+ developers, where people come and leave every now and then, having storyboards allows much faster onboarding and easier rationalization of the flow of the application. In the programmatic approach, you have to run the app, which can take up to 5+ mins each time you recompile, depending on the size of the app. Your example above is cool when it's your own personal project.
Well, imagine working on a React Native project at Uber, AirBnb, Facebook, or Instagram. How do you suppose the engineers there rationalize all the view logic?
Reach Native has hot reloading. You can see changes instantly. That isn't the case for iOS.
True, nonetheless all the view logic is written in HTML which requires a human brain to parse. I really enjoy using XIBs to visualize iOS designs and see changes in real time. Can't have it all I guess.
From where you learned coding and programming languages?
From Google.
Lets Build That App and from Google where?
Searching Google for stuff.
Lets Build That App but still from where? Any recommendation
Everywhere
Which is better is really the wrong question. You should be asking which is a better fit for me (or my team). If you're a one man shop, the code only approach is probably fine but if you're working on a larger codebase with multiple team members in several roles, you'll quickly find that storyboards are more maintainable. Translators can easily change labels without touching code, designers can move things around and tweak look and feel without touching the code and you can generally hire more junior developers when your team is using storyboards.
If you don't need that kind of separation, code only is great. if you do, storyboards are too. granted, you could get most, if not all the storyboard advantages i mentioned in other ways as well, but it'd probably be more than a bit more difficult.
All in all, Apple does allow us both ways of doing things for very good reasons.
I often hear people tell me they allow designers to touch storyboards and application code. I've never been at an organization that needed or allowed this. Isn't it really scary to let a non developer introduce critical bugs in your storyboard? A lot of places wont even let interns merge code onto master without heavy code reviews.
Besides can’t translators just use the localization files for languages which doesn’t require the existence of a storyboard
Do you have any lecture on Obj-C?
I haven't written any ObjC tutorials yet for this channel.
Lets Build That App That's too bad. but your swift tutorial is really useful. Thanks!
Thanks man! impressive stuff.
But you could just as easily make so-called "cheat" classes for storyboards too.
I have such generic classes for firebase and some buttons with some @ibdesignable vars for whenever I have to make similar buttons and such.
Regarding the segues though I agree, and you don't have to use them. you can just use storyboard to keep everything visual and easy to remember
and write your transitions programmatically. sort of the best of both worlds
I like combining XIBs and code to make life easier when possible. Segues are just...ugh.
Beginner here. I never thought of keeping the storyboards then using code for transitions instead of segues. That seems like a great advice. Thank you! I'll try it out next time!
Are you going to make more vids about kotlin?
I think so, what would you like to see with kotlin?
@Lets Build That App well, anything would be great but i want to learn how to create a widget in the notification bar. For example, when you are using spotify or pandora, on the notification bar you see the options: *play, stop or skip a song*. I want to learn how to do that so the user can interact with my app through there.
THANK YOU!!
I get the point and all but it does feel like in the storyboard side you did a lot more explaining and jumping around than is needed. As well can it truly be considered a “speed run” when you already have some of the files you need for program view done? That’s like me doing a speed run of Pokémon red vs Pokémon blue but in the blue version starting at a save were in two gyms in. I feel like there should be a disclaimer saying as an experience programmer I have these files sitting around l, although anyone doing it the first time would have to make these files themselves so their times will be horrible off.
Good points but this video was shot from the perspective of a real world dev scenario. No honest developer starts from scratch, we rely on a bunch of libraries to make our jobs faster and easy to write clean code.
Furthermore I can type out all the code in this video in about 2 mins if I didn’t explain or run the simulator until the last bit of code.
Wow! I wish to push 1k of likes! Thanks a lot for this video
trying to choose between (More clicks && less typing) vs (More typing && less clicks) 🤔 ... But great video anyways, this shows how powerful generics and programmatically can be. Keep up the good work!
A huge portion of it is type safety which is possible in code but with SB these strings can be very irritating.
yeah seems like you get more control in code since you can remember you did everything and know what is what, I also dislike seeing strings typed everywhere and it is the no. 1 cause of bugs or untraceable errors. What I do now is keep all the cell id's and segues in an enum class. Looking forward to taking your course soon tho, I'm interested in doing things in code as well.
his method might actually be less clicks and less typing in the long run but i would have to run experiments or go back and keep track. if you copy pasta the extensions and understand how to use them then they are a great weapon to have. i love this dude cuz i just learned something new
I think the biggest problem of storyboards is the over usage of them. Someone put EVERY view controller in the main storyboard and this approach makes the storyboard itself totally unusable. It’s a common usage put table view cells directly in the view controller, so storyboards contains cells too. And segues in my opinion are evil.
My approach is to have several storyboards that contain related view controller, single xibs for cells and custom reusable views. Then I created a library to have more uiview properties in interface builder (shadow color, rounded corners etc) so I have always a good idea of what I’m drawing.
Finally I don’t use segue.
Thanks Brian. God bless, Proverbs 31
Please sir, make a full tutorial on blogging from start to end. I would love it if it will be a series and it should include how could earn from blogging?
I don't blog though, unless you count this channel.
i think it has always been a series of Scrollable and non scrollable parent views with Sectioned Nested StackViews.
So I made a Generic Project Template I can always use, where the things I only need to change are the data model, the cell properties, the XIB of the cell, the request parameters and just handle all the events and business logic in the view controller.
I Inconsistent placement of our codes and having to jump from one file to another until we forget what we were actually looking for is one of the major reason we tend to become slow.
Not only that is our code becomes spaghetti code and un maintainable which in turns App not scalable enough to last atleast 5 years.
For me, I think the best way is to invest on creating a template that you can always reuse. Right now, I just kept copy pasting my codes however complex the ui is because everything are already setup using behavioural driven mvvm pattern.
Just sharing my opinion, hoping anyone might find this helpful and at the same maybe I'm wrong and someone can help me :)
再次大感謝~ 太神拉~~~~
没事儿 没事儿
Are you chinese?
Why do have more than one viewcontroller?
Pure cod ! Cool
Isn't this kind of skewed because you had to create the app before the video for the example. Therefore the method you used for the example would be quicker because you had already done this project in that format once before. Still great video, just picked up on this flaw while watching.
Well, the functionality in the app isn't anything new or advanced. I've built this out both in code and storyboard a ton of times and its just a bunch of busy clicking for me now. Anyhow, the idea is to show people how little code it takes to put things together very cleanly.
Okay, that makes sense. If a person is an expert at a specific thing, then it truly does show the advantage to one method over another (I am, also, a programmatic iOS dev - not a fan of storyboard).
I do want to say, I really appreciate you responding to my comment. It shows real integrity and a true belief in the work that you do. I have always liked your videos, but now I have a much greater respect for your work. Great job Brian!
Brian taught me to hate storyboard.
use of unresolved identifier companies on return companies.count and also cell.textLabel?.text = companies[indexPath.row].name
Have you had a chance to figure this one out?
After experiencing with React Native, I don’t wanna go back. 😁
After years of React Native and experimenting with Swift, I don't wanna go back. No Android support out of the box but hey.. at least it's lightning fast on iOS! And there's not as many styles as before. Yay!
lets not forget that coding is also way cooler!
The thing is with storyboard, you write less code.
Writing less code isn't necessarily a good thing. For example, code revisioning is much easier this way.
Less code, less bug. The storyboard (or xib files) itself hides so much code (rendering things, auto-layout handlers, properties settings, etc.) Now, what you do is to re-write what the storyboard hide. I used to think on your way in my previous project. The result is : writing is faster, but end up with tons of code. In my current project, I do opposite by conversing all codes to possible bindings in storyboard or xib. As result, code is short, looks clean and easy to maintain. Of course, each approach has pros and cons. 100% agree with you : "code revisioning is much easier with your way", but the trade-off is we have to write tons of code.
In a lot of larger projects, your code repo will contain a ton of reusable components for your lists and cells that follow company styles/guidelines. These components will take 2 seconds to create in code and will be much easier to edit en masse compared to opening each and every storyboard file. You'll start to understand this once you start working at a sizable software organization.
Each reusable component as you said can be implemented in xib files. Even, better by using IBDesignable, you can embed one xib into another xib file. As result, another component can be created, based on a component which is implemented by using xib files. Opening a xib file, you can see right away what the component looks like. Other developers can read and understand your code better. I never say your approach is wrong. Anyway, I admit that it's good sometimes.
Yep, I think I use XIB files more now since they're much easier to look at and understand when I go back to edit the UI. Keeping the view files isolated in IB is quite nifty.
i always code all, i never use the storyboard usin c++ and objc ☺️
*Jony Ive
Oh yeah, that's his name I always forget the y.
Lets Build That App also I think his last name is pronounced like “I’ve” not “ivy” but I’m not 100% sure on that
This dude has the trickiest name
Lol "john ivy" it's pronounced jonny i've
+1 to the real hackers going pure code