I'm working on an iOS app in Swift. The other app I created was one I did in Objective C and release around this time in 2014. Storyboards seem to have made UI stuff both easier and more complicated at the same time, so I'm trying to figure out current best practice in terms of view development.
Size classes and constraints seem like almost a necessary timesaver at this point for multiple screen sizes. Back in 2014, this was less the case, and programmatically keeping track of UI layouts as CGRect code made programmatically mucking with UI layout much simpler and better for code reuse vs creating a whole new view controller for just adding new UI elements to much the same view. Doing the same thing with constraint code seems less appealing, but also necessary if I want more code reuse there.
So I'm wondering what the current practice is here as I'm just thinking in terms of code reuse. Programmatic constraints just seem less elegant than storyboard defined ones, but I'm not sure they're the end all be all for UI code since they seem problematic for programmatically updating the UI on the fly.
Is the best strategy at this point to enclose everything in layout preserving superviews and keep most of this storyboard centric or would it still make sense to do swift programmatic code for these layouts since I'd have to for iPad and iPhone specific changes anyway? On that subject would it still make sense to split drastically different UIs into multiple storyboards (e.g. 2 different iPad and iPhone storyboards as that was a default at one point)?
Thanks in advance for answers to this. Device specific stuff just seems to not always be code reuse, but I just want reuse to be relatively simple I guess. Otherwise I'm just creating more swift classes than I strictly need.
This is inherently opinion based. Everything from no Interface Builder to only StoryBoards is likely being used in production applications, and you can make just about anything work.
My personal tendency is to use Storyboards for everything other than TableView/CollectionView cells. I find it removes almost all interface boilerplate code from my classes and makes it so I only need to handle the interface between my ViewControllers. Here are the guidelines I generally try and follow: (again...opinion)
Use multiple storyboards organized in a useful way:
Large storyboard become hard to maintain and performance while editing suffers noticeably. We have the option to use StoryboardReferences, so might as well use them.
The more Scenes and ViewControllers, the better. (within reason)
This makes things more maintainable and re-usable. E.g. a header that could be used in multiple Scenes. It can be a bit annoying to have to use containerVCs and deal with segues everywhere, but I rarely regret separating something into it's own ViewController.
Don't use separate interface files for different sizes.
It's more code to maintain and will force you to swap ViewControllers in-out if you want to support resizing on iPad (or any future devices). Not to mention going forward it's clear Apple is assuming you're using size classes rather than swapping ViewControllers and is clearly where the future is headed in Apple platforms development
When you need animations, try and narrow it down to changing a single constraint.constant
This greatly simplifies your code and usually avoids having to deal with size-classes anywhere other than the storyboards. It's not always possible for complicated animations, but you can do a surprising amount if you're willing to mess around. It makes it possible to narrow down a toggling action to 2 lines of code, which is quite nice. Using StackViews can also help with this a lot.
The other thing to focus on is avoiding as much of the stringly-typed nature of IB as possible. This is much easier in Swift and there are some decent solutions using string-backed enums and extensions, but specifics are probably out of the scope of this question.
Related
This question already has answers here:
Adding Views. Storyboard VS. Programmatically [closed]
(2 answers)
Closed 6 years ago.
Is it more efficient to add views and subviews programmatically than using a storyboard to add them ?
What is be the best practice ? Does the best practice depend on the situation ? If so, when is it preferable to use the one method over the other ?
Storyboard vs Code comes up an awful lot. And I think looking at it as which is better often starts flame wars. So instead I'll list out pros and cons for each, then you can hopefully make an informed decision.
This is by no means an exhaustive list. I'd love to see edits or comments adding additional bullet points.
Storyboard Pros
Storyboards are great for getting a concept working quickly.
They're great for seeing your actual app and previewing it on multiple devices.
They make it really easy to customize appearances and explore whats possible.
They're fantastic for beginners as they remove one barrier and let you focus on code for your app rather than some boiler plate UI.
Storyboard Cons
Storyboards and Xibs are not great for merging. Its possible to read the XML and make decisions about merge conflicts, but its certainly not enjoyable.
Overtime as you customize your app and build the custom parts that make it special, Storyboards can't keep up. This means that the benefit of seeing and previewing your app as you see it on device slowly loses its value as more and more of your app is done in code out of necessity.
Storyboards don't have a huge performance hit for actual users, but they definitely slow Xcode down on even the fastest machines.
You can't customize everything in Interface Builder that you can in code, so its inevitable you'll have some code and some Storyboard customization. Later when you want to change something, you'll have to check at least two places for the right place to change it.
If you're using the same fonts and colors throughout the app, its easy to change in code in one place. In Storyboard you'll need to change it for every single label or view you've set up. You can easily set fonts and colors in code while using Storyboard for the rest of your layout, but over time you'll find your storyboards represent less and less of your actual app.
While its possible to have pixel perfect designs in Storyboard, drag and drop isn't as precise as entering specific numbers. Storyboard does support entering those numbers, but you need to navigate to multiple places and if you drag it later the numbers are all reset.
Reusing views typically involves copy and pasting them. These causes issues later when you need to make changes.
Showing and hiding views at certain times is doable, but again leaves your storyboard in an unrealistic state compared to your actual app.
Programmatic Pros
All your code is in one place making it easier to debug or change later.
Subclasses and custom properties are no different from first class views and properties. Your customizations will be easy to manage.
Views that are reused throughout the app only need to be created once.
Merge conflicts are often easy to understand and make decisions.
Dependency Injection is one of the safest ways to instantiate UIViewControllers and ensure necessary information is passed in, its not possible with Storyboards leading to less straight forward and more bug prone code.
Programmatic Cons
The additional complexity can be a stumbling block for beginners.
Writing a few lines of code can take longer than clicking a few checkboxes.
When working with layouts, you'll need to visualize it in your head or run your app to see what your layout looks like as you make changes. This can be difficult or slower for some.
Storyboard exposes checkboxes and buttons for many customizable properties like background color, font, etc. This makes it easy to see at a glance what you can customize. (Though as mentioned above its not everything) In Code, you'll need to look at documentation or headers to understand what you can customize.
My doubt is very simple.
I want to develop one big iOS (iPhone) app of say 30 screens.
One my friend advice me to develop whole UI in coding only and do not use XIB's or storyboard.
I want to ask that, is it feasible for me to develop whole UI in coding instead using XIB and story board?
Will that affect my iOS app processing?
Will that affect my iOS app execution speed or not?
Please suggest me the proper way weather I use XIB and Storyboard of develop UI by Coding only ..... !!!!
Thank you.
Firstly, tell your friend not to give you advices again.(Just kidding! :)) You can develop the whole app programmatically but it's just a pain in the gut. Apple introduced the storyboards to ease the waste of having multiple xib files in your product.
For my personal opinion, use xibs in case of having lots of teammates working with you because of the pain of conflicts. If you're working solo, then storyboards would be the best fit.
Yes, there is no silver bullet that will solve all of your problems, every project is specific and your ability on predicting project requirements will enable you to decide. Here are some pros and cons of both approaches to help in making a decisions:
Storyboards/XIB pros: Very visual, Beginner friendly, Easy autolayout, MVC separation is straightforward on view side
Storyboards/XIB cons: SCM conflict are almost always unresolvable, not all parameters are configurable from IB so you still need to know how to do some stuff in code
Pure Code approach pros: Full control over entire presentation in code, conflicts resolvable easy as it can get
Pure Code approach cons: Might need more experience to master
My judgment would be:
Using storyboards/XIB is better solution for small to medium projects that consist of basic/stock UI elements.
Introducing visually complex solutions and non standard transitions will require that you start writing layout code more and more and stuff becomes easier without XIBs in your way.
From my experience if you are part of the bigger dev team, Storyboards and XIBs are a big NO..
I prefer not using IB at all even for smaller projects as pressing CMD+R after writing bunch of code, and seeing it come alive is very pleasing.. :-)
To answer your question literally: yes, you can make an app without any storyboards or xibs. I think with iPhone 6/6+ you have to have at least one because they check it to see if you support the bigger screens, but that's it.
In fact, my first app in 2013 had almost no Xib UI design. It was iPhone portrait only, I coded with frames and was happy with the precise results I got-- I also think I learned a lot. I think with Auto Layout, especially if you learned Visual Format Language (albeit that's not a easy thing to do) creating a robust interface entirely in code is doable.
That said, not using interface builder is not doing things "the Apple way." And not doing things the Apple way is usually -- not always, but usually -- going to be more difficult. On one level, WWDC videos, guides and sample code all assume you are using IB. Creating every label, subview and view controller in code is going to take several more lines, each, than using xibs or storyboard. You will be swimming against the current.
It's worth noting IB can be immensely frustrating at times. But generally it's worth it, and you learning how to relate it to the code is learning iOS programming. Also about IB , the files it generates are just XML files, it won't have any significant effect on size or performance- I'd be wary of advice from someone who told you that.
An all-code app is doable and would be a challenging way to learn, but this is not advice I would give anyone or second.
I am new to iOS and was wondering which is the best to learn. I have read some of the answers here and SO, but some people say use Storyboards will others say learn XIBs first. Is there any real benefit to learning XIBs? Are XIBs easier to understand and will help with storyboards?
There is benefit to learning both approaches.
Apart from the historical value in the xib approach, xib's also provide modularity. Perhaps you have a library of code or wish to share a useful widget you made. Taking the xib approach would facilitate that sharing and reuse.
The xib approach also allows you some greater flexibility in terms of your own code. For example, iOS 5 contained a bug with UITableView and Accessibility/VoiceOver support that would cause -dequeueReusableCellWithIdentifier: to return nil despite being documented otherwise (see this blog post for further details). To dynamically load table view cells from xib provided the ability to work around the bug.
While the table and tablecell support in Storyboards is wonderful and provides support for what most people need to do in a table, sometimes you have to color outside the lines, you might need lots of different cells, and again, dynamically loading from xibs can be your solution.
One big advantage of Storyboard is the ability to view your entire application's GUI flow. Zoom out and you can see how everything interconnects and flows. With xibs, while the modularity is nice, it's tougher to envision how everything connects and flows together. This can be a useful feature for yourself, or if you have a larger team to share with, to allow others to see how the app flows.
There's value in both approaches, and it's good to know both so you can pick the best tool for your task at hand.
Update 2014-10-06 - Since I wrote the above, I've been involved in more projects. Some with xib, some that could use storyboards.
Storyboards have matured a great deal (we're at Xcode 6 now), and there's a great deal with them that's so nice. I really love how so much more can be done within a storyboard that is a bit more complicated in a xib-approach. A couple examples:
One is when working with UITableView or UICollectionView how much you can work with prototype cells directly in the storyboard. A lot of nice and easy setup, most of the heavy lifting can be in the storyboard, less code. It's quite nice. Trying to do this in the xib approach is certainly do-able, but there's a lot more work to make it happen.
Another is how nicely you can transition between UIViewControllers with the regular segues then go back with unwind segues. All right there in the storyboard, with minimal code. It's just so handy.
But the one thing that still kills storyboards for me is trying to use them in collaborative environments. It's just not going to merge well. And in some regard, it's not even if you're working on a team of > 1 person. If you yourself take advantage of version control, use a good branching and merging model for your own personal workflow, there may come a time where some change is going to have to be made in some branch that has to be brought into another branch, and oh the pain. To me, this is what kills storyboards.
As time and work has evolved, what I'm finding for myself is storyboards are great for prototyping. The ability to get things going quickly is a huge benefit of storyboards. There's much speed in using them. But the speed comes at cost. When it comes to writing the "real" code for some project, I'm just going to stick with xibs because while it may be more work, it's a more flexible route that just works better in larger teams or over time.
Update 2015-04-07 Another update, because the projects of the past some months have forced me to use storyboards, which has provided more insights.
First, some things will mandate one approach or another. For example, apparently there were some edge case bugs when working with size classes in xibs that didn't exist doing the same thing in a storyboard. So if you get affected by bugs, that may force your hand one way or the other. Another is to remember that storyboards generally work on the UIViewController level, so if you need to do something like have a UIView or a UICollectionViewCell to load, that's probably going to be better served by a xib.
Second, and I don't know why this didn't occur to me at first, but there is nothing that requires you to use a singular storyboard for your entire project! I think the nature of storyboard enables people to gravitate that way, but we have to remember nothing mandates that (that I'm aware of).
What I've found works well is to generally approach each "view grouping" per storyboard. That is, often your ViewControllers tend to be isolated and wind up being 1 per storyboard (or xib). But you might have a situation where you have two closely-related ViewControllers, and it makes sense to put them into the same storyboard, especially because then you can easily hook things up between them, such as segues.
The main advantage to multiple storyboards? Working in teams. This way Fred can work on his storyboard and Wilma can work on her storyboard, and there's no strong worries of merge problems or work coordinatinon! The use of multiple storyboards (and generally 1 ViewController per storyboard) has been a huge help in the use of storyboards on a multi-person dev team.
It's pretty evident Apple wants us to prefer storyboards, and I'm embracing them more these days. Using multiple storyboards, but still using a xib when needed, is working fairly well now.
Update 2015-09-21 Now that Apple's released Xcode 7, there's even more reason to adopt storyboards, as Apple works to overcome the shortcomings.
The most important improvement is storyboard references, which allow you to create in one storyboard a reference to another storyboard. It's dead simple to make, and now you can have cross-storyboard segues (both entrance and exit). I've used this a few times already on a new project and it's just a joy.
Another improvement is that you can create stand-alone UIView classes within a storyboard. However, as of this writing I've had mixed results with it. Simple cases work out ok, but some more "complicated" stuff did not. For example, I had a UIViewController with a UITableView within it. Since it was to be a simple table with 5 static cells, I merely instantiated the 5 UITableViewCells as a part of the ViewController in the storyboard. Seemed to work, but then at runtime nothing would actually load and show up; moved the UITableViewCells into a xib, and all worked. I'm not sure if I was doing something wrong or what it may be, so YMMV. But still, even if there's just some quirks, in time I'm sure Apple will resolve them and then another barrier against storyboards will fall. I would say that if you need such support, you should try it and see how it goes for you. There's great promise.
More and more, storyboards are shaping up to be excellent.
There are things you can do with a storyboard that you can't do with a nib. A storyboard lets you create segues between view controllers, and it lets you design table view cells in-place.
There are things you can do with a nib that you can't do with a storyboard. In a nib, you can create references to the File's Owner placeholder. You can create multiple top-level views, edit them, and create connections between them. See this answer for an example of why you'd want to do that. You can add external object placeholders (a rarely-used feature).
Storyboards have the drawback that they collect a bunch of different, loosely-related objects into one big file. If you're working on a project with several developers, you are much more likely to run into merge conflicts if you're using a storyboard than if you're using xib files.
You should definitely learn about nibs at some point. Whether you want to start with them or start with a storyboard is probably not too important. Just find some tutorials you like and work through them with whichever type of file (nib or storyboard) they use.
As a beginning iOS developer, which approach allows for quicker more efficient development?
There is no right answer to this. For someone who's been developing with Xcode for 2-3 years, the old programmatic way is more efficient, and storyboards feel alien. This is the situation I am in personally. For someone who is just starting out with Xcode or iOS development today, Storyboards will probably make more sense and pose a shorter learning curve. I can get my work done quickly by avoiding storyboards, but that's because I am too set in my old ways. Do whatever "feels right" to you, and adapt as the IDE evolves.
Creating a basic layout using Storyboard Paradigm is faster then do it programmatic.
However the best way is to combine all three ways (nibs, storyboards, programmatic) depending on what you have to do.
Because basic layout with little or no customization does not sell.
I use storyboards just to create a skeleton diagram to show it to the clients and to check if the flow of the views feel right.
Storyboards in my opinion seem harder to customize later using code, because is harder to access the inner elements.
Nibs are nice to speed up development by creating dummy views to avoid time calculating everything in code.
Code for doing customization and animations using Quartz.
I would go for the third option: Nib files. In my honest opinion, I think I have more flexibility with them than with Storyboards. I do think as well than in a near future I will be using Storyboard, but not at the moment, for me it's not a mature "approach" yet. Although sometimes I have the need to create some UI components by code, if I would do everything by hand I would be doomed.
In terms of speed you are probably not going to have a massive time difference. I do suggest however that you start using nibs and move on to storyboards. I guarantee you will come across code that will use nibs and possible (if not probably) manual reference counting. A colleague of mine runs a iOS training course and still teaches nib's and manual reference counting, then moves on to StoryBoards and ARC. It might take a bit longer to learn, but it probably will save you time in the future. I suggest If you are considering doing quite a bit, or serious iOS dev that you do take this approach.
New to iOS, coming from the Java / Swing world, where I'm used to creating UIs programmatically, letting components size themselves and using various clever layout managers to arrange things.
It already seems clear that the iOS way is to make heavy use of Interface Builder, with a lot of fixed sizing and positioning. I'm not sure IB is ever going to come naturally, but I guess fixed layouts make sense given that you're working with limited space and a fixed window size.
It still seems like I'm writing a lot of boilerplate, though, and violating DRY, and so on.
Can somebody point me to a good primer on laying out iOS UIs, particularly programmatic UIs?
You don't really need to use IB to write MonoTouch apps. I almost never do. The CocoaTouch API is fairly simple and straightforward to develop on.
I haven't really found any writeup on UI development other than the apple documentation (which is really good, by the way, worthy reading), so here goes a couple of tips, based on my experience:
Inheritance is key to maintaining the code clean. You can inherit from basically any class in the API, like buttons, controllers, views, etc. Inherit and add your customizations in those classes. Don't shove everything in the AppDelegate like many examples show. You'll thank me later on.
Have I mentioned inheritance already?
The one thing iOS doesn't have is a layout manager, so if you're used to Java like you mentioned, this will sound a little strange. Different from what Java people think, this is not a big deal. UITableViews help tremendously with this (vide next point).
A lot of iphone apps are built on top of the UITableViewController, even apps that don't look like tables. It's a great framework to do anything related to scrolling. Learn to use it well. Almost anything that scrolls vertically is a UITVC. Follow the guidelines that define when you create and when you dispose cells and objects.
Be careful every time you add a Frame location in your control. Instead of setting hardcoded values, try using offsets from other locations (x+40, for example) whenever possible.
Make sure you add your views to the proper container as necessary. For example, if you're adding a global "Loading" view, add it to the Window object, while if you're adding a image on the left side of a table cell, use the ContentView. iOS changes those special views automatically all the time (resizing screen to fit "on call" bar at top, or rotating phone).
Miguel de Icaza has created a great framework for managing forms and tables, called MonoTouch Dialog. Take a look, and enjoy.