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.
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 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)
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
For example, if you do it all programmatically, are you less likely to run into trouble?
if you are designing UI with code (not using Xib/Stotyboard) this will be good when you create UI dynamically so then you need not to spend more time on changes. what ever we use for development (Code/Xib/Storyboard) nothing will be changed in performance. As per user/developer comfort we will go for it. Suppose there are lot of UI need to be displayed few at the time viewdidload and rest after some button action then usually at the initially stage itself Xib and Story board will load all of them and hides un wanted and as per actions it will show the hidden UI. i feel coding is better for me.
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
I should create an app compatible with the screen sizes of the iPhones 4 and 5. On the web I found some ways to organize my project. The best ways to do it are to:
create two storyboards,call one when screen size is 568 and the other when screen size is 480
use autolayout and have an unique storyboard
I don't know how to use autolayout and I should learn its implementation in my project.
Then in this situation, I want to know by your experience what's the best approach.
I think that first approach is very intricate and slow, with two storyboards you can make mistakes and don't have the same situation in each device.
In my experience I used xib files, and I used two xib file for each viewcontroller, a solution which is very very noisy.
Then, what can you tell me about these approaches?
AutoLayout will make it easier to adjust your UI for both screen size, but even with the old UIViewAutoresizing you will be able to get everything working.
I would suggest that you do not use 2 storyboards or NIB for that mater, because if a some point an other screen size is introduced you need to create a third storyboard/NIBs.
You can even use the UIViewAutoresizing in NIB and in code.
Just set the autoresizing mask correct to grow/shrink with the screen size and you will be good to go.
Well , if you want to make app that run on both iOS 7 and iOS 6, than its better to use Autolayout, because it is easy to use, and also too much flexible.
Because your other options are too much complex and time consuming as well.
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 needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
is there any code difference between ipad and iphone? How can we convert iphone application to ipad application?
Codewise, the main difference is in the very different screen sizes leading to different user interface considerations. But there are a number of differences. For example,
Some classes, such as UIPopoverController and UISplitViewController, are only usable on one type of device.
Some classes behave differently, for example UIActionSheet doesn't come up from the bottom on iPad and doesn't display the cancel button (as cancelling is done by touching anywhere outside the bounds of the sheet).
Some methods don't work right on one or the other device. For example, some of the methods for presenting a UIActionSheet should only be used for iPad, and others should only be used for iPhone.
Some behaviors are only available on one or the other device. For example, UIViewController's modalPresentationStyle is ignored on iPhone.
Most of these are documented, some only show up as warnings in the console when using the "wrong" method, and some you just have to figure out they don't work right. Fortunately, UI_USER_INTERFACE_IDIOM() makes it easy to tell which device your code is running on so you can easily handle these differences.
It is exactly the same except for the dimensions of the screen. There are still some code changes though to enable iPad mode if you are writing a cross compatibile app.
Resource:
http://iphonedevelopment.blogspot.com/2010/04/converting-iphone-apps-to-universal.html