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 3 years ago.
Improve this question
I am new iOS development, I used storyboard and Interface builder to design my application UI. But now I am seeing that many people are using SwiftUI. I searched about SwiftUI and found some points about it as SwiftUI works seamlessly with new Xcode design tools to keep our code and design perfectly in sync. But I am not able to compare it with Interface builder & Storyboard. What are the advantages & disadvantages of SwiftUI over Interface Builder and storyboards?
Is SwiftUI will completely remove Interface Builder and storyboards?
In the interface builder like storyboard and xib you can see what you are doing. You take a component and then add it to the storyboard and that's how you design the UI, but if you do the same thing programmatically then it gets a lot harder as you can not see anything and you have to be experienced to do so. Every time you have to build an app to see the changes in the UI but SwiftUI solves this issue as it gets updated constantly as you write code. To solve this, Apple came up with SwiftUI which helps you to see what is going side by side. Anyone can move from Storyboard to SwiftUI.
Personally, I have started from Storyboard then moved to XIB and then I went to Flutter which was quite different and SwiftUI is quite inspired by Flutter. You have to keep in mind that SwiftUI support starts from iOS 13. You have to start from storyboard and then when you have gained experience then you can move to SwiftUI.
Update: Also, there is an another way of developing UI's and that is via programmatic UI coding. I have been developing UI's programatically for a long time now and personally it helps to understand the concepts of UI more and you can start adding a lot of extensions which will make your project easy to maintain at a later stage. When you develop in a group then interface builders throw merge conflicts a lot of time which becomes a pain very soon. (30 Oct, 2020)
Related
This question already has answers here:
Storyboards vs. the old XIB way
(2 answers)
Closed 7 years ago.
what are the pro's and con's of each, and what would be the proper way to responde to a question like this in an interview :
When would you use Storyboard vs Nib/Xib vs Coding from scratch?
This is a very objective question to answer. But I will give you my take on it. When I am creating basic UI navigation which is also using the stock UI controls then I use Storyboards.
There are certain scenarios where I am either using a third party component or I am developing a user control from scratch. In those cases I use coding from scratch. If you are coding from scratch then you can also utilize and control the look and feel of the different UI components much easily. Of course you can also do that from Storyboards by inheriting from the TitleLabel instead of UILabel but that approach is quite restrictive.
Unfortunately, there is hard and fast rule of choosing one or the other. It all depends on the situation.
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
I'm learning iOS and I've gone through a few tutorials now, and one or two of them had you draw all the controls in the IB, and one or two of them had you create them all programmatically.
This leads me to wonder whether I can safely mix and match these approaches. I know the answer is yes, of course, since it would make no sense otherwise.
But what are the advantages/disadvantages? Particularly with regard to proportions and sizing for different screens, that bit is still an obstacle to me as a beginner.
This is mainly a matter of taste. I like to make my controls in code others prefer the Interface Builder. I see the following advantages for the Interface Builder:
More visual. You can see how you interface will look like while you put it together.
You can use the Preview assistant editor and see you interface without compiling.
You don't have to remember what the options are called because you can scan the checkboxes for what you are searching.
You can faster prototype with storyboards.
Maybe your designer can learn to build the interface using storyboards.
The advantages for code are:
No context shift. All you do is coding.
Still you have less merge conflicts when you are working with a team on a project.
All the options are in one place. In Interface Builder you have to click through all the inspectors to find what you are searching for.
It's easier to post code than screenshots in case you need help on Stackoverflow ;).
If you finde code on github you can see without downloading how the interface is build.
I had a few times that a project could not be opened by Xcode when I opened it in a beta of Xcode because the Interface Builder file structure had been changed.
Code is easier to refactor than storyboards (Thanks #Spectravideo328 for the suggestion in the comments).
It is impossible to inherit from a storyboard scene. I code you can easily make subclasses to reuse code. Using a storyboard you have to make two scenes even if they share 90% of their UI elements.
One thing which is very important: Don't put all you screens in one storyboard. Try to keep the storyboards small. Something between 1-6 screens is working for me with good performance.
There are no such thing like advantages or disadvantages. Just take a example. if you already have those controls to use it via Xcode. why will you code it. We only code things when we need to make special controls or you can edit your controls by connecting your controls to the code(you can google it "how to connect buttons in iOS"). In short, you only create controls when its kind of a special control which is not pre build in Xcode.
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 9 years ago.
Improve this question
As you know, soon we will have the new iOS7 release, and then we are supposed to adapt our App's to the new flat style.
My question is: does anybody know which is the best practice to have a temporary coexistence of the iOS 6 (skeuomorphic) and the iOS 7 (flat) design?
The best for me would be the possibility of 2 different Storyboards per device-screen-size, and "preprocesor directives" for retrieve the iOS version...
What do you think?
NOTE: I know that if you adapt your app to iOS7 (and you configure it properly), you can run it on iOS6, the problem is that the changes that you will do to adapt to iOS7, would make your app look ugly in iOS6...
We updating our app from Old Type graphics in iOS6.1 to a new style Flat ever in iOS6.1 when the iOS7 Stable is ready we can update the core with functionality but the graphics style is so new see my screen:
Before on iOS6:
After a WWDC on iOS7 we make an update with this style:
The correct question is what you want to do after the iOS7 is Ready? if you want to update your app only for iOS7 or create an update retroactive from iOS6.1 to iOS7 is only your strategy.
Hope my think is good :)
I think that one approach is to rely heavily on
Auto Layout (to deal with different sizes of controls and text)
UIAppearance (to change backgrounds and tints depending on style in a single place depending on the OS version)
Then just check for the availability of new features like UI[REDACTED] and [REDACTED]Kit before using them in your app. (iOS 7 is still under NDA).
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 9 years ago.
Improve this question
Apple introduced storyboard which saves lots of coding time. It seems that it doesn't support iOS4 and below. So is it mature enough to use storyboard for development now? How are other application doing?
Storyboards are only supported in ios5. Mainly because they support segues
I can recommend you using storyboards just because it brings your project screens to something logically bound, so if random developer sees it he can quickly figure out everything.
Coding layouts is time thrown to trash. Your time and time you'll support the project, and time you'll spend trying to find bugs in this code, and time of other people that would be very much demotivated when they see the code for layouts.
In storyboards you are also forced to use MVC, so u'd never create a separate view for anything but tableview cells. (like you can do in XIB)
You should be sure that you have more than 2GB of RAM to use storyboards, because they usually contain more than 5 screens and DO lag on slow computers. The monitor size is also better be big or you'd be forced to scrolling over things all the time.
Yes story board is okay to use. Just set your deployment target above 4.0. If you do that you should be fine.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am trying to learn some of the basics about creating views and view controllers on iOS. All the samples and documentation I've come across use the Interface Builder and NIB files to create UIViewControllers and UIViews. How to create the controller and the UIView programmatically and not use the interface builder?
You may do that, that's for sure. But you should see the pros and cons here;
You create and manage everything in code, neat huh?
Well this means, you will retain/release everything yourself.
You will write lots of boilerplate code just to create a complex view with more than one layer of component hierarchy.
You will not see the properties you may change, instead you need to see the Class Reference document for each component.
You need to play with pixel values a lot, i cannot emphasize how long this "a lot" will eventually be.
So, consider Interface Builder, it is easier to keep everything seperate, and then bind them as needed. Code maintenance is much more important in the later phases, as the app becomes mature.
I have been through both ways, and my vote is +1 for Interface Builder, and override stuff only when needed. That is in practice less than like 5% of your UI development time.
The short answer is that yes, of course you can create views and view controllers programmatically.
As someone who had this same feeling when I first started out, let me impart this short bit of wisdom: Do not try and remove all .xib files from your project until you know a lot more about what you are doing!
There are tutorials out there on how to remove the .xib files entirely from your project, and remove dependency on MainWindow.xib. In my experience it is definitely not worth your time. Just leave the .xib files in your resources folder, close it up and pretend they don't exist.
Eventually, you may even be happy they are still there.
Yes,
You can create UIViewController and UIView programmatically,
See the Apple documentation for UIViewController and UIView, there are many function which start with init, used to create programmatically.
Suggest you to invest some time reading Documentation.