I am an enthusiastic beginner in iOS development and I have faced some questions that may occur to many other beginners as well. Please note that I am not asking for opinion or suggestion, instead need some clarification to use the best option that I am offered.
Speaking of designing the apps interface via Swift. We have three options which are : programmatically, StoryBoard or Xib file. The question is, can employ more than one of these three for the same project or even the same page(screen) in my app?
When I am using Storyboard I can drag and drop different objects and use them. How ever I either need to set my own constrains for every single one of them or I can select all and click the set required constrains and they will be all set. But how come although I've defined the constrains my view is not responsive on various devices? Based on my understanding the only way to get the responsive in all the iOS platforms to set the constrains programmatically! Feel free to correct me if I am wrong.
It may not be the best practice but I personally am more fond of back-end comparing to the front end. Is it possible to design all the back-end first and set all the constrains at the very end!?
1.Speaking of designing the apps interface via swift . We have three options which are pragmatically , Story Board or Xib file . The question is can employ more than one of these three for the same project or even the same page(screen) in my app ? ]
You can use storyboard for UI designing and also Xib's also you can use for example if you want design custom alertviews. This is just an example.
2.When I am using storyboard I can drag and drop different objects and use them . How ever I either need to set my own constrains for every single one of them or I can select all and click the set required constrains and they will be all set . But how come although I've defined the constrains my view is not responsive on various devices . (Based on my understanding the only way to get the responsive in all the IOS platforms to set the constrains pragmatically!! Feel free to correct me if I am wrong . )
First understand the Autolayouts in iOS. This is very powerful tool for iOS developers for responsive layout.
We can do Autolayout in either ways i.e., programmatically or Storyboard. But I can suggest for storyboard is better. In Some cases we can use programmatically.
Follow these links:
Autolayout for beginners
Introduction to Autolayout
3.It may not be the practice but I personally am more fond of back-end comparing to the front end . Is it possible to design all the back-end first and set all the constrains at the very end !?!
As per my view, First design responsive UI, Check in all devices. In latest Xcode, We can even check UI in all screens.
Dont use multiple storyboards for every iOS device. Use Autolayouts for desgin UI with single screen in storyboard
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 7 years ago.
Improve this question
So I'm new to iOS development and I found it easier to write the views all programmatically. So my views have UIViews, ScrollViews, UIButton, UILabel all created and positioned programmatically. (So I never used AutoLayouts).
I've now pretty much finished my app and want to make the iPad views, and realized maybe it was a bad idea to do it like this.
Is this bad practice or should I really be using auto layouts as much as I can?
If it's ok to do it how I'm doing it right now, what is the correct way to add different views for iOS and iPad? I've seen this answer below on how to find the device, is a simple if else statement sufficient? - iOS: How to determine the current iPhone/device model in Swift?
I am using programatic views in a live app and its awesome. A bunch of people I know us this as well.
Here is a little algorithm I use to choose between the two methods:
Are you building a fast app for a client or a hobby? Use storyboard with autolayout.
Are you building an open source project that will be used by many people? Use programatic UI
Are you building an app for the long run? (1+ year) Use programatic UI
Its also harder to make an app thats supposed to be rotated without autolayout. Because doing that with code takes much more work than autolayout. Most good apps dont use this feature anyways so I don't see much problem.
A good tip is never to use constants while writing programatic UI.
If you are going to make a button thats 100px in width, do not type in 100px anywhere in the code. Instead figure out the screen sizes and place the main views according to screen sizes. Then place the subviews or secondary views according to the position of the main views. If you do this correctly you will have more powerful multidevice layout support than autolayout.
Here is a little library I wrote, please inspect and play with the code on how I place the view: https://github.com/goktugyil/CozyLoadingActivity/blob/master/CozyLoadingActivity.swift
Also here is a good article I like about this:
http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code
This is only fine, If you have enough time, patience, good skill on calculations and relationship configurations between different UI elements.
However, using Auto Layout is pretty useful and low time consuming than manual calculations.
We can easily create a dynamic and versatile interface that responds appropriately to changes in screen size, device orientation, and localization with minimal effort.
Read Adopting Auto Layout,to implement the Auto Layout in your existing application
TL;DR
It depends
Longer version
Clearly one size does not fit all. AutoLayout is pretty powerful both in Interface Builder and code (be it visual language format, or simple constraint setting), but sometimes it just seems like you're "rubbing your right ear with your left hand" - that's when adding views programmatically comes in. But beware of not having it different in each view controller - you don't want to introduce too much complexity in your project, right?
I personally like using AutoLayout as much as I can and whenever I can't use it anymore, or the StoryBoard View would get too messed up with millions of constraints, I try to separate views into containers - have the container be resized by AutoLayout and have the subviews handled by code.
Example would be a custom Media Player - maybe I want to have two stripes below and above the video - I could have the video and two UIView extended stripes handled by the AutoLayout. But the subviews (controls) in the stripes themselves would be added by code. It gives me the control over my code but still it doesn't introduce too much complexity.
First of all - if you want to develop for iOS you have to learn Autolayout. There are already a lot of different devices with different resolutions and maybe will be even more in future.
Secondary - if you want to work effectively with IB you have to read guide / watch tutorial videos and have some practice. It could be difficult to start but then you will realize that IB is powerful, fast and often the best way to develop GUI. Often, but not always!
Code advantages:
Easy to copy-paste and reuse GUI. It could be critical if you have
several similar views or want to reuse some old code.
Easy to resolve merge conflicts and check commits.
Easier to make styles - like the same font for all labels depending on the country.
More powerful (there are things that could not be done with IB) so you have to use it sometimes.
IB advantages:
You can see your GUI during development for different resolutions/localizations so you do not have to compile and run a project on different devices/simulators to check is GUI ok or not. Also IB will show you warnings if you forget some Autolayout constraints or there are conflicts. Saves a lot of time if you have a complex GUI with non-trivial Autolayout constraints.
It is much easier to understand someones else code if it is developed in IB. Especially important for complex GUI - not so easy to find a required label or button in a few hundreds lines of code.
Small bonus - if you want to use a custom control developed via code you can make it IBInspectable and use it without problems in IB
Just to summarize - if you do not need IB benefits (for example GUI is quite simple and does not use Autolayout) developing GUI via code could be easier and faster. But in case you have to support different resolutions and/or you have hundreds lines of GUI code in each view controller I strongly recommend to try IB.
I want to have in my app some nice slide navigationmanu just like in SWRevealViewController. My problem is that SWRevealViewController needs iOS 7.0 and ARC and in my project I have iOS 6.0 without ARC. Is there any way to use SWRevealViewController in my app or maybe there is any alternative to it?
You might want to take a look at ViewDeck https://github.com/Inferis/ViewDeck
It is compatible with iOS 6 and non-ARC.
I cannot tell about SWRevealViewController without ARC or iOS7 (thus I cannot directly answer your question), but I would put a lot of weight behind the following :
Over 80% of all iOS devices currently run iOS7 or greater. ARC has been available since iOS5, which is several years ago.
The mobile market is a quickly evolving one. Not upgrading will quickly lead you to a dark path where you'll end up fighting a losing battle. I understand that your project probably has limitations, but converting right now and keeping up with new technologies will save you a lot of trouble (for instance, trying to make a newer component work with your specific setup).
I would add, the same goes for AutoLayout. If you aren't using it already, you should start, NOW. Rumor has it the next iPhones will vary in size, and the legacy way of handling visuals cannot scale correctly (perhaps the whole reason AutoLayout was created is to prepare this change).
So in short, I wouldn't recommend adapting a new component to your old project, but rather updating your old project to make it modern. You'll end up saving a lot of time.
I'm developing an app/game that contains few UIViews:
An user/pass form
A title menu
A configuration menu
1 MapView that will be the main view
4 UIViews that i will show dinamically and with animation using the "animateWithDuration" function
2 alert UIViews
I've never worked with Storyboards so I would like to know what is the best solution:
Use Storyboards to keep control of the navigation flow (it's posible to use animateWithDuration in this case?)
Show/hide the UIViews programatically as I was doing until now
To use a combination of both (if it's possible)
Other
for iOS 5, i agree with Kaelin's answer: better organization all in one place, and i have projects in which there are items that don't fit within the storyboards that can still be added programmatically by loading .xib files later.
however, for any iOS 4.x or earlier support that you are required to do, storyboard won't help you. it is not supported in iOS 4.x or earlier.
Storyboards provide a convenient way to organize and present the navigational structure between your UIViews. The Segue mechanism for passing state between UIView transitions also encourages better organized and more maintainable code. IMO, there is little reason not to use Storyboards in modern (e.g. targeting iOS 5 or later) iOS apps.
All of the scenarios you have described are straightforward to implement while using Storyboards. You are in no way "locked in" to using segues between all of your views. You can mix and match as makes sense for your application.
Are there any guidelines on when to use storyboards in an iOS project and when to use XIBs? what are the pros and cons of each and what situations do they each suit?
Near as I can tell it's not that clean to use storyboard segues when you have view controllers being pushed by dynamic UI elements (Like map pins).
Update 1/12/2016: It's 2016 and I still prefer laying out my UIs in code and not in Storyboards. That being said, Storyboards have come a long way. I have removed all the points from this post that simply do not apply anymore in 2016.
Update 4/24/2015: Interestingly Apple doesn't even use Storyboards in their recently open-sourced ResearchKit as Peter Steinberger has noticed (under the subheading "Interface Builder").
Update 6/10/2014: As expected, Apple keeps improving Storyboards and Xcode. Some of the points that applied to iOS 7 and below don't apply to iOS 8 anymore (and are now marked as such). So while Storyboards inherently still have flaws, I revise my advice from don't use to selectively use where it makes sense.
Even now that iOS 9 is out, I would advise against to use caution when deciding whether to use Storyboards. Here are my reasons:
Storyboards fail at runtime, not at compile time: You have a typo in a segue name or connected it wrong in your storyboard? It will blow up at runtime. You use a custom UIViewController subclass that doesn't exist anymore in your storyboard? It will blow up at runtime. If you do such things in code, you will catch them early on, during compile time. Update: My new tool StoryboardLint mostly solves this problem.
Storyboards get confusing fast: As your project grows, your storyboard gets increasingly more difficult to navigate. Also, if multiple view controllers have multiple segues to multiple other view controllers, your storyboard quickly starts to look like a bowl of spaghetti and you'll find yourself zooming in and out and scrolling all over the place to find the view controller you are looking for and to find out what segue points where. Update: This problem can mostly be solved by splitting your Storyboard up into multiple Storyboards, as described in this article by Pilky and this article by Robert Brown.
Storyboards make working in a team harder: Because you usually only have one huge storyboard file for your project, having multiple developers regularly making changes to that one file can be a headache: Changes need to be merged and conflicts resolved. When a conflict occurs, it is hard to tell how to resolve it: Xcode generates the storyboard XML file and it was not really designed with the goal in mind that a human would have to read, let alone edit it.
Storyboards make code reviews hard or nearly impossible: Peer code reviews are a great thing to do on your team. However, when you make changes to a storyboard, it is almost impossible to review these changes with a different developer. All you can pull up is a diff of a huge XML file. Deciphering what really changed and if those changes are correct or if they broke something is really hard.
Storyboards hinder code reuse: In my iOS projects, I usually create a class that contains all the colors and fonts and margins and insets that I use throughout the app to give it a consistent look and feel: It's a one line change if I have to adjust any of those values for the whole app. If you set such values in the storyboard, you duplicate them and will need to find every single occurrence when you want to change them. Chances are high that you miss one, because there's no search and replace in storyboards.
Storyboards require constant context switches: I find myself working and navigating much faster in code than in storyboards. When your app uses storyboards, you constantly switch your context: "Oh, I want a tap on this table view cell to load a different view controller. I now have to open up the storyboard, find the right view controller, create a new segue to the other view controller (that I also have to find), give the segue a name, remember that name (I can't use constants or variables in storyboards), switch back to code and hope I don't mistype the name of that segue for my prepareForSegue method. How I wish I could just type those 3 lines of code right here where I am!" No, it's not fun. Switching between code and storyboard (and between keyboard and mouse) gets old fast and slows you down.
Storyboards are hard to refactor: When you refactor your code, you have to make sure it still matches what your storyboard expects. When you move things around in your storyboard, you will only find out at runtime if it still works with your code. It feels to me as if I have to keep two worlds in sync. It feels brittle and discourages change in my humble opinion.
Storyboards are less flexible: In code, you can basically do anything you want! With storyboards you are limited to a subset of what you can do in code. Especially when you want to do some advanced things with animations and transitions you will find yourself "fighting the storyboard" to get it to work.
Storyboards don't let you change the type of special view controllers: You want to change a UITableViewController into a UICollectionViewController? Or into a plain UIViewController? Not possible in a Storyboard. You have to delete the old view controller and create a new one and re-connect all the segues. It's much easier to do such a change in code.
Storyboards add two extra liabilities to your project: (1) The Storyboard Editor tool that generates the storyboard XML and (2) the runtime component that parses the XML and creates UI and controller objects from it. Both parts can have bugs that you can't fix.
Storyboards don't allow you to add a subview to a UIImageView: Who knows why.
Storyboards don't allow you to enable Auto Layout for individual View(-Controller)s: By checking/unchecking the Auto Layout option in a Storyboard, the change is applied to ALL controllers in the Storyboard. (Thanks to Sava Mazăre for this point!)
Storyboards have a higher risk of breaking backwards compatibility: Xcode sometimes changes the Storyboard file format and doesn't guarantee in any way that you will be able to open Storyboard files that you create today a few years or even months from now. (Thanks to thoughtadvances for this point. See the original comment)
Storyboards can make your code more complex: When you create your view controllers in code, you can create custom init methods, for example initWithCustomer:. That way, you can make the customer inside of your view controller immutable and make sure that this view controller cannot be created without a customer object. This is not possible when using Storyboards. You will have to wait for the prepareForSegue:sender: method to be called and then you will have to set the customer property on your view controller, which means you have to make this property mutable and you will have to allow for the view controller to be created without a customer object. In my experience this can greatly complicate your code and makes it harder to reason about the flow of your app. Update 9/9/16: Chris Dzombak wrote a great article about this problem.
It's McDonald's: To say it in Steve Jobs' words about Microsoft: It's McDonald's (video)!
These are my reasons for why I really don't like working with storyboards. Some of these reasons also apply to XIBs. On the storyboard-based projects that I've worked on, they have cost me much more time than they have saved and they made things more complicated instead of easier.
When I create my UI and application flow in code, I am much more in control of what is going on, it is easier to debug, it is easier to spot mistakes early on, it is easier to explain my changes to other developers and it is easier to support iPhone and iPad.
However, I do agree that laying out all of your UI in code might not be a one-size-fits-all solution for every project. If your iPad UI differs greatly from your iPhone UI in certain places, it might make sense to create a XIB for just those areas.
A lot of the problems outlined above could be fixed by Apple and I hope that that's what they will do.
Just my two cents.
Update: In Xcode 5, Apple took away the option to create a project without a Storyboard. I've written a small script that ports Xcode 4's templates (with Storyboard-opt-out option) to Xcode 5: https://github.com/jfahrenkrug/Xcode4templates
I have used XIBs extensively and completed two projects using Storyboards. My learnings are:
Storyboards are nice for apps with a small to medium number of screens and relatively straightforward navigation between views.
If you have lots of views and lots of cross-navigation between them the Storyboard view gets confusing and too much work to keep clean.
For a large project with multiple developers I would not use Storyboards because you have a single file for your UI and cannot easily work in parallel.
It might be worth for large apps to split up into multiple storyboard files but I have not tried that. This answer shows how to do segues between storyboards.
You still need XIBs: In both of my Storyboard projects I had to use XIBs for custom table cells.
I think Storyboards are a step in the right direction for UI implementation and hope Apple will extend them in future iOS versions. They need to resolve the "single file" issue though, otherwise they won't be attractive for larger projects.
If I start a small size app and can afford iOS5 only compatibility, I would use Storyboards. For all other cases I stick to XIBs.
Storyboards were created to help developers visualize their application and the flow of the application. It is alot like having a bunch of xib but in a single file.
There is a question similar to this located What is the difference between a .xib file and a .storyboard?.
You can also create custom transitions via code that will change dynamically if needed, much like you can with .xibs.
PROS:
You can mock up flow of an application without writing much, if any code.
Much easier to see your transitions between screens and your application flow.
Can also use .xibs if needed with storyboards.
CONS:
Only works with iOS 5+. Does not work with iOS4.
Can get cluttered easily if you have a very view intensive application.
There really isn't a right / wrong when to use one or the other, it is just a matter of preference and what iOS versions you are wanting to use.
I will just state 4 simple reasons why you should use storyboards, especially in a productive environment where you have to work in a team of product owners, product managers, UX designers, etc.
Apple has GREATLY improved working with Storyboards. And they encourage you to work with them. Which means they will not break your existing projects with updates, they will ensure that storyboards are future proof for newer XCode/iOS versions.
More visible results in less time for the product owners and managers, even during the creation phase. You can even use the storyboard itself as a screenflow diagram and discuss it in meetings.
Even after an app is done (and that's generally where its life-cycle begins) – in the future it will be faster and easier to apply small adjustments. And these could very well change multiple aspects of your layout at the same time, which you probably want to see in a WYSIWYG manner. The alternative would be hand-writing UI changes in code and switching back and forth between the IDE and the simulator to test it out, each time waiting for compile & build.
Non-developers can be taught to set up layouts in storyboards and create the necessary hooks for the developers (IBOutlets and IBActions). That's a very big plus because it lets the devs focus on the logic and the UX designers apply their changes in a visual manner, without having to write any code at all.
I won't write up any CONS, since Johannes has already listed probably all the viable ones in his answer. And most of them are definitely not viable, especially not with XCode6's major improvements.
I don't think there is a right answer for your question, it's just a matter of personal experience and what you feel more confortable with.
In my opinion, Storyboards are a great thing. It's true, it's really hard to find out why your app is misteriously crashing at runtime, but after some time and experience you'll realize it's always related to some IBOutlet missing somewhere and you'll be easily able to fix it.
The only real issue is working in team under version control with storyboards, in the early stages of development it could be a real mess. But after that first stage, UI updates that completely changes the storyboard are very rare, and in most cases you end up with conflicts in the very last parts of the xml, which are segue references that usually autofix themselves when you re-open the storyboard. In our team work we prefered to deal with this instead of heavy view-controllers with tons of view code.
I've read many comments againts auto-layout. With XCode5 it got really improved, It's really good even for autorotating layouts. In some case you'll have to do something in code, but you can simply outlet the constraint you need to edit and, at that point, do what you need in your code. Even animate them.
I also think that most of the people who dislike storyboards didn't fully try to understand the power of a custom manual segue, where you can totally customize (in a single file) the way you transition from a way to another and also (with some tricks) even reuse a previously loaded view controller by just updating it's view contents instead of fully reload the whole thing.
At the end you can really do the same things as in code, but I think you have a better separation of concerns with storyboards, but I agree that in many things they lack of features (fonts, image as color background, ecc...).
I am not using StoryBoard or XIBs in my any of the app.. but creating everything programmatically.
∆ Benefits :
√ You can create any complex kind of UI or transition animations for UIView's.
√ Support all iOS versions. No need to worry about < iOS 5.
√ *Your app would support all iPhone/iPod/iPad devices within your code.
√ You're always updated as you know the code that'll always work.
√ *Will work on any (new) device launched – No need to change in code.
√ Everything is upto you. At certain place you want to change something – No need to look into storyboard or xib. Just search for it in particular class.
√ Last but not the list – You'll never forget that, how to manage everything programmatically. This is the best thing as you know a control very deep then anyone.
I've never find a problem by not using SB or XIBs as I'm good with this.
* if you've set UIKit's object frames according to screen size.
P.S. If you've still not done this thing – you may faced difficulty (or may feel boring) but once you get familiar with this – its really a Candy for you.
If you are about to care about Storyboard performance, watch WWDC 2015 Session 407
Build Time
When interface builder is compiling a storyboard it's doing two things
first, it's trying to maximize the performance of your application and
secondly it's also minimizing the number of nib files created.
If I have a view controller with a view and a bunch of sub views,
interface builder, the build time is going to create a nib file for
the view controller and create a nib file for the view.
By having separate nib files for both the view controller and the
view, this means the view hierarchy can be loaded on demand.
Run Time
When you allocate a storyboard instance using UI storyboard, API,
initially all you are allocating memory for is the UI storyboard
instance itself.
No view controllers no views yet.
When you instantiate your initial view controller it will load the nib
for that initial view controller but, again, no view hierarchy has
been loaded yet until someone actually asks for it.
I have been working on a reasonably sized project (>20 scenes in storyboard parlance), and have come across many limitations and have to repeatedly go to documentation and google searches for doing things.
The UI is all in one file. Even if you create multiple storyboards, you still have many scenes/screens in each storyboard. This is a problem in medium-large teams.
Secondly, they do not play well with custom Container Controllers which embed other container controllers etc. We're using MFSlideMenu in a Tabbed application and the scene has a table. This is almost impossible to do with a storyboard. Having spent days, I've resorted to doing the XIB way where there is complete control.
The IDE does not allow to select controls in zoomed-out state. So, in a large project, the zoom-out is mostly to get a high level view and nothing more.
I would use storyboards for smaller applications with small team sizes and use XIB approach for medium-large teams/projects.
If you want to reuse some UI in multiple view controllers then you should use XIBs