Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Currently we use Storyboard over xib in all projects. But in my view if you want to make reusable view (custom view or Tableview cell) which can be re-used in different view controllers, you must use xib files as in storyboard there is no way we can make single view object separately.
Note that I am using Storyboard for workflow (view controllers with segues all around) of entire application. Only for reusable tableview cells I am using XIB.
I have searched in lot of apple documents as well as WWDC videos but I could not find any concrete proof from Apple developers which says that XIBs are here to stay or you should use XIB for custom views.
If any of you guys have any kind of links which gives somewhat confidence that we can still use XIB without fear of apple removing it, it would really be appreciated.
Storyboards are recommended when you don't reuse views.
Once you want to reuse something in multiple views/storyboards, then you need XIBs. You already mentioned the example of custom cells. That is something I need quite often and I want to use the same cell in multiple table views. I do the same with charts. I create a chart view in which I set colors etc. and I reuse it everywhere, only putting different data in it. This saves me a lot of code in respect to style/appearance and makes the app easily maintainable. In case of change (e.g. because of new iOS version), I need to change everything on a single place.
Furthermore, I want to have views (e.g. cells) for iPhone and iPad and let the system determine which one to use. For this, again, I need XIBs. I use the notation with ~iphone or ~ipad at the end and I don't have to write code for retrieving the correct view.
This are two things that you simply cannot do without XIBs. So, following the Apple guidelines, my approach is to use storyboards whenever possible and XIBs only when I need them (mainly because of reusability). But there are real cases when one needs XIBs! Simply ignoring them is not a good practice for sure. Actually, in each project I have storyboards as well as XIBs.
Edit: I just found a great post explaining the disadvantages of storyboards. There are plenty of things that I was not aware of.
Also, you don't have to use either exclusively. You can still use XIB files even if most of your work is in storyboard. And using either also doesn't restrict you from creating a view that isn't built in IB at all.
Storyboard has plenty, plenty of advantages. Particularly when you start bringing new people in on the project. Without getting engulfed looking at hundreds of thousands of lines of code, a new developer can look at the storyboard and in 30 minutes or less get a quite good idea of the flow of the app.
With that said, you should never limit yourself to anything. Limiting yourself to just storyboard and never using XIB or building a view completely in code is like saying "We're only going to use NSArrays, and never NSDictionary or NSSet". Instead of a silly limitation, you should always just be sure you're using the right tool for the job.
My opinion is use which one is appropriate for that context, here is some guidelines:
When to use nibs
Modularity is key to well designed nib files
Use nibs to store views, subviews, custom controls or repeated views
There’s no way to represent the relationship between screens of related content
When to use Storyboards
Storyboards are best used to represent screens of content and the connections between those screens
Give due care and attention to the prepareForSegue:sender: method
Modularity is still applicable when designing storyboards
General Guidlines
Decompose your projects into nibs and storyboards
Views, subviews and custom controls should be contained within separate nib files
Use storyboards when designing full screen content and there are clear relationships between scenes
Consider whether the interface needs to be static or dynamic
Use separate storyboards to encapsulate reusable sequences of scenes
Use separate storyboards for unrelated scenes
Table view cells that can be reused across different controllers belong in nib files
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm building a few information screens and they have different layout/design (ie. can't be generalised), since they are all information screens I've put them in one storyboard, however they are not connected by any segue, it's just based on response I show different information screens.
I'm a bit uncertain that if it's a good practice to do this? I can't think of another way for doing this which is better, separated XIBs? different storyboards? Or a single screen with dynamically updated layout/content based on design (this sounds like a bad idea)?
The only downside I can think of, is that the storyboard won't have a initial screen, which feels a bit against the purpose of storyboard - you are telling a "story" by screens in a navigation flow.
Am I thinking correctly, is there a better way to do this?
Thanks!
Here are two good reasons not to put independent scenes in a single storyboard:
A larger storyboard takes longer to load and save.
If this is a multi-person project, you’re more likely to run into merge conflicts.
Here’s one good reason to put independent scenes in a single storyboard:
You will often need to modify several of the scenes at once.
Usually it’s simpler and lighter-weight to use individual XIBs unless you actually need storyboard-specific features like segues.
One advantage of adding the screens in a storyboard is, you can connect them via storyboard references.
It is not always necessary for a story board to have an initial controller.
Actually it is more of a personal choice to choose story board vs xib in your scenario.
Let's just stipulate, shall we, that having multiple screens but not representing them through multiple view controllers and their views is just dumb. View controllers exist for a reason; use them. So your choices for making a view controller's view are:
Create the interface entirely in code
Use a xib file
Use a storyboard
You are asking to choose between the last two. But as far as you are concerned, there is nothing to choose between, because:
A xib file is a way of generating a nib. So many xib files give you many nibs.
A storyboard is a collection of nibs (i.e. it's multiple nibs in one) — with the added feature that you can include segues.
If you don't use segues, a storyboard is many nibs and that's all it is — just like having many xib files. So if you are not going to use segues between view controllers in your storyboard, then there is no advantage or disadvantage one way or the other: it just depends on your personal style.
Personally I think the storyboard interface is a pain to use, plus if you want to instantiate a view controller from a storyboard without using a segue, you have to give it an identifier and cast to the view controller class, whereas if you instantiate a view controller with an eponymous xib, you instantiate it by class and it loads its view automatically, which is far neater.
So I'd lean towards using separate xib files, but it's a matter of opinion / taste, and de gustibus non disputandum.
I know this is a question that has been asked quite a bit, but it's iOS 9 and I still don't have a clear idea about what to do. For starters, here is what I seem to be surmising from all the data available:
Storyboards let you create segues. [I've never been a big fan of this answer because segues are often the least harrowing part of creating the UI layout for me.]
Xibs can let you create multiple top-level views. (Storyboards vs. the old XIB way) [I don't think I've ever used this much, though it seems rather helpful.]
Storyboards - Creating UITableViewCells is easier. [In my opinion, it's cleaner to create xibs for the cells and just invoke them in cellForRowAtIndexPath].
Storyboards can turn into one giant ultramassive file that is hard to edit. [I've seen this happen in practice and it is a big drawback, but at the same time...]
Storyboards let you arrange all your Views in one place with the layout shown as well. [This seems to be a big help for me. But then, over the years I've found doing this in code much easier. Which brings me to my final question.]
What is the performance aspect of both of these two things. My app is essentially the following :
A top level hierarchy of interconnected view controllers, not more than 5.
A large number of disparate, independent view controllers that range from Scroll Views to TableViews to static Imageviews.
Autolayout, size classes, the works.
For each of these view controllers, what is the performance of creating a storyboard for each of them vs. creating a xib for each of them. More importantly, what would be a good way to lay out an app like the one I've mentioned.
You definitely want to use storyboards for laying out view controllers - simply because you get access to topLayoutGuide and bottomLayoutGuide which the XIB editor won't give you.
For other views, it's a matter of preference. I tend to use XIBs for table view cells simply because I tend to reuse them on different screens and prefer to have them in their own files.
I would actually advise against manually writing view code where possible simply because it's much harder to read and work out how views are laid out, especially for developers who didn't write the code originally! For simple, dynamically sized things this can be fine, but if you're trying to lay out view controllers with different constraints depending on the size class it's going to end up a bit of a mess.
Yes, it's a pain to deal with merge conflicts of these files, but with iOS 9 you can split up view controllers into different storyboards a lot more easily using view controller references. Personally I find the inconvenience of merging storyboards/XIBs the lesser evil of having to write everything in code.
It sounds like a Storyboard is the right thing for your current project. However, my experience has been that Xibs and Storyboards are problematic in the real world, for these reasons:
extremely idiosyncratic from developer to developer, so it is tricky to build good storyboards as a team
black boxes, so they require a tremendous amount of knowledge to master (unbelievable amount of hidden behavior). Only the most superficial semantics are covered in the documentation.
internationalization is made much harder by being split up, especially if you have internationalized messages not contained in the Storyboard/Xib.
backwards compatibility breaks annually / deprecation guaranteed over time. This is especially difficult if you try to maintain compatibility with older devices.
As soon as more than two devs started touching our code we rewrote everything to avoid Storyboards and Xibs altogether, and we became much more productive.
If you have to deal with any of those real world situations, I heartily recommend programmatically creating all of your views. There is even an app that makes this easier (and is way more scalable). I have no relationship with this company or product, but it is hands down a better solution.
http://www.paintcodeapp.com/
Is Multiple Storyboard in single project is better than single storyboard??if yes then why??
Which is better Single Storyboard or Multiple Storyboard??
Any one please clear me the above queries.
It depends on the project requirement. If you are good enough with the size classes and auto-layout and also if the requirement flow is almost similar for all the devices then go with single storyboard.
By default in Xcode 6 or later, recommending to use single storyBoard.
If you have a bigger app and/or not only one man team:
You should NOT use single story board. Like its name says, it is a "STORY" board. You should have one Story in one Board. This keeps the readability and maintainability of the storyboard.
If you have a team, it is a nightmare to "merge" one single story board if 2 made changes in it at the same time. It is more or less impossible. But if you have for each story a corresponding storyboard, even in a scrum team you can manage to work on one storyboard only one person, that you do not need merging.
There are a lot usefull documents and workshops in internet if you google "ios storyboard git merge ...."
When to Use Storyboards
Finally, while Storyboards are best used for scenarios involving multiple view controllers, it’s also defensible to use a Storyboard when working with a single table view controller for three reasons:
The ability to design table cell prototypes in-place helps keep the pieces together.
Multiple cell templates can be designed inside the parent table view controller.
It’s possible to create static table views (a long awaited addition that’s unfortunately only available in Storyboards).
When Not to Use iOS Storyboards
A few cases:
The view has a complicated or dynamic layout, best-implemented with code.
The view is already implemented with NIBs or code.
When to Use NIBs for iOS UI Design
A subset of all uses cases would be:
Modal views
Simple login and registration views
Settings
Popup windows
Reusable view templates
Reusable table cell templates
Meanwhile…
When Not to Use NIBs
You should avoid using NIBs for:
Views with dynamic content, where the layout changes significantly depending on content.
Views that by nature are not easily designable in the Interface Builder.
View controllers with complicated transitions that could be simplified with Storyboarding.
Apple's docs say that you may have multiple storyboards. Unfortunately they don't go into any real detail on how to do that. As you've found out, Interface Builder won't help you, so you'll have to do it in code. It works much like loading XIBs:
[UIStoryboard storyboardWithName:#”MyNewStoryboard” bundle:myBundle]
Having said that, if you don't "want one big/bloated storyboard" as then XIBs really are the way to go. That 'bigness' is the benefit: all the transitions between VCs are laid out in one place. Having multiple storyboards is really so that you can support multiple different and unrelated flows through your app: for example, one storyboard for a complex configuration flow and another one for the main user flow.
I have read a lot about creating a lite and a paid version with Xcode and in my app I am using multiple targets and preprocessor macros as described in this Stackoverflow post. However, I don't know how to handle different targets with a Storyboard.
For example, in my storyboard I have a table view controller with static cells. In the paid version it has four cells, in the lite version has one extra cell whereas the rest of the storyboard remains unchanged. Is there a way to achieve that kind of behavior?
(Creating a new storyboard for the lite version (or duplicating it) is not an option for me as I have dozens of view controllers and 98% of the views and UI elements are identical in both versions. It would make the project difficult to maintain.)
For example, in my storyboard I have a table view controller with static cells. In the paid version it has four cells, in the lite version has one extra cell whereas the rest of the storyboard remains unchanged. Is there a way to achieve that kind of behavior?
If you hadn't boxed yourself in by using a static table, this problem wouldn't have arisen in the first place; you'd be configuring the table in code, which can be conditional — end of issue.
As things stand, you'll need two different scenes in the storyboard, one for the paid version, the other for the lite version. Then:
If this scene is reached by a segue, you'll need two different segues that reach this scene, and you'll decide in code which one to trigger (and trigger it in code, not automatically).
If this scene is the initial view controller, you'll need to instantiate it initially in code rather than letting UIApplicationMain do this for you. Or, in that case, use two different storyboards for just this one scene, and then segue to another storyboard.
(And do keep in mind that multiple storyboards are a great way to organize your scenes in any case. I don't necessarily mean multiple alternative storyboards; multiple sequential storyboards can keep your storyboard from becoming overly complex. It sounds to me from your question as if all you need to do is understand how storyboards work - they are not magic, you know - and be more nimble in your use of them. Your entire deer-in-the-headlights fear of duplicating your storyboard - "I have dozens of view controllers" - suggests you've already gone way too far down the wrong road. Programming is like solving a Rubik's Cube: if you're in the middle of it and your response to someone trying to change something is "don't touch it!", you're doing it wrong.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The question is simple, I guess.
I'm looking for general rules of thumb.
I was even wondering if it's possible to create a view controller with a view described in code, but designed in a xib. (Makes sense?)
Closing the question
Although #mckeejm gave an answer where he thinks he had no choice but using code instead of a xib, the question hardly has only one correct answer and it is also very hard for one person to give a response with all the possible correct answers in it, therefore I'm voting to close my question.
But thanks anyway.
One thing you can do when you create views without a .xib file is have views that are derived classes of other custom views. For example, in the application I'm working on now, we have the concept of "cards" where cards have a corner radius and shadow setup prior, with a plain UIView *contentView for the actual content of the card to be placed in. If we want to make a new card, without reproducing that code, we simply create a new class that inherits from CardView and then manually position its content via layoutSubviews. I personally like having a .xib for constraint positioning and things like that, but I couldn't find a way to use our CardView as a base class for the new card style control unless we did it programatically.
Yeah what you can do is make a UIViewController in the storyboard file and connect that to a UIViewController class of your choice. Make the basic design in the builder then in the code you can go through and "customize" it to your need. I.e: when a button is pressed change an image. Does that answer your question?
#crimsonchris is right, this question is too open.
I will say this though: I've built apps that utilize storyboards, xibs, and flat out code. I've always found that writing things out in code is simply the fastest, most lightweight solution. BUT it has to be done correctly. My particular method to get ahead is by subclassing.
Typically, you have a consistent style guide in your app and can reuse a lot of ui elements throughout your app. The downside to writing everything in code is that it requires so much redefinition of object's attributes (font, text color, etc). If you subclass a baselined ui class of say a UITableViewCell you can use it everywhere and don't have to deal with the xib/storyboard nightmare. Not to mention the massive speed difference...
If you are a member of linkedIn, there is an IOS developer group that you can join that is probably more appropriate for questions of this type (coding styles). In the linkedIn group the discussion for this same question is already several pages long.
Personally, I use the XIB for its basic layout capability so I can visually gauge if the view looks good or not. Interface builder is not always an answer specially if you have dynamic screens with several layers - in which case I sometimes use a temp IB just to get the coordinates but build the view via code. Take note:when you use a XIB, the objects in the screens are instantiated by the XIB and is a black box to you - so if I have dynamic views with several objects that appear conditionally, using a XIB will create all those objects before your viewDidload whether or not those objects are eventually useful or not. Necessarily it will affect the way you debug, specially if the problem originates from within the XIB.
storyboards allow you to prototype without typing any code, which means you can show your boss how the app should look like within a few hours, I find it limiting in the way I am able to pass values and embedded class instances between class to class so I hardly use it. It is extremely useful if you can work within its boundaries.