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.
Related
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.
I'm learning many features of ios programming, but since I'm a beginner I don't know if it's better to design my appearance programmatically or graphically.
For example, should I make a view in code or should I drag it to my storyboard?
Should I set its size and position programmatically or graphically?
Which one is actually used in projects?
Specially considering the new Auto Layout and Size Classes feature in Xcode6
For auto layout and layout constraints it is best you use graphical tools because it is definitely future proof. You can do the same thing with code but it takes a whole lot of time to do things when compared to the graphical way of doing it. At the end of the day it all comes to the developer's comfort zone and the app's requirements.
A Small Point About Universal Apps:
Universal app building is very comfortable when you choose graphical storyboarding and have separate stuff for iPhone and iPad (also there are bigger screen iPhones and iPads coming). If you choose to do all the UI stuff with code for an universal app you would end up writing a lot of if-else statements, like below
if ([[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPhone) {
//Do iPhone stuff.
} else {
//Do iPad stuff.
}
Help from Interface Builder for Autolayouting
The easiest way to add, edit, or remove constraints is to use the
visual layout tools in Interface Builder. Creating a constraint is as
simple as Control-dragging between two views, or to add multiple
constraints at once, you simply use the various pop-up windows.
Quote from -https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/WorkingwithConstraints/WorkingwithConstraints.html
You always have tools to save you even when you have messed up a lot with the constraints.
Some real good stuff,
http://carpeaqua.com/2014/05/09/why-you-should-use-interface-builder-with-auto-layout/
http://www.raywenderlich.com/51992/storyboards-vs-nibs-vs-code-the-great-debate
If you're looking into iOS development as a bit of a hobby then I'd recommend sticking to the graphical tools. These are faster to learn and will let you build your app in a shorter time if you are just beginning.
If you want to work on a large project in a professional environment or in a large team, then a 100% code project is usually desired.
If you pull apart some of the largest apps on the AppStore from huge companies, you'll see they don't use interface builder (IB) files. Take a look at Facebook, Spotify, Dropbox etc etc.
Some reasons include (but not limited to):
Ease of flow: A complicated app UI in interface builder can seem like a blackbox sometimes, whereas code is usually easier to follow
Simpler merging: If you have multiple developers working on the same UI file, merges can be a nightmare and more difficult compared to a source file
Finding problems: If a problem exists in a pure code project then the problem is right there in the code. Locating problems in an IB file can be tough, depending on how buried it is. Also Xcode's 'find' tool doesn't search through IB files
Code runs faster: You probably wont notice the speed but it is an advantage
Some boast the speed of coding using the graphical tools, and it's true that initially it will take you much longer than the code you're not yet familiar with. If you stick with it then you'll be able to write apps just as fast.
This question already has answers here:
When to use Storyboard and when to use XIBs
(9 answers)
Closed 9 years ago.
I am new to iOS development (No apps created yet), but I ask for advice from my friend that has really high rated apps on the market. He said not to use storyboards.
As much as I want to take his advice, they seem really helpful.
Is this something that can cause problems for my app in the future?
Is there any reason I may want to not use storyboards?
Coming from an Android background, I don't see why I should use them.
I tend to avoid storyboards for anything apart from perhaps a quick prototype. If you know you have a very simple app which isn't going to get complicated, and you're the only developer, storyboards might be ok.
Here are a few blog posts that detail some of the pain points when using storyboards:
http://toxicsoftware.com/uistoryboard-issues.html
http://blog.waynehartman.com/archive/2012/01/07/uistoryboard-on-ios-5-the-good-the-bad-and-the.aspx
Both of the above are a bit dated, but I believe the pertinent points still hold true.
Note that in theory you need to use a storyboard(s) to get static tables, which can be useful. To get this benefit, you could put only the static tables in storyboard files (note: you can have multiple storyboard files in an app) and use xibs or just code for the rest of the UI.
I'd recommend against using either storyboards or Interface Builder.
You'll learn Objective-C faster if you spend more time using it. Switching between IB and code, you'll have two things to learn. The context switching will still slow you down later on.
Nibs and storyboards are big XML files that don't play well with source control; if you're working on one at the same time as someone else, you will get merge conflicts.
You can't see everything that's going on at once in IB, so it's hard to track down things like layout problems.
You can't search or replace in IB the way you can in code
Nibs and storyboards put your view logic in your controllers. Whether that's a problem for you depends on how much of an MVC purist you are.
If you want to port your apps to/from Android, IB will make it much harder.
This all comes from experience. I started out running a small software team developing iOS apps using IB (storyboard wasn't out yet) and within a year it had caused so many problems that I'd had to forbid its use. Our productivity went way up when we stopped using it.
I think it's not important to use it or not,the most important is how your application is?(quality, beautiful, fast...).
StoryBoard is great for beginner to shorten design time and understand.
But when to become professional developer, you will love to draw your interface by coding because typing more faster than graphic.
I don't think this question is really answerable. There are pros and cons of any technical decision and this one is no different.
Pros:
Visual, so you get a much better idea of what your app will look like more quickly
Less code
Autolayout can be easier
It's not all-or-nothing. You can build the "base" in Storyboards and finish it off in code
Cons:
A big hairball of an XML file makes merge conflicts pretty nasty
Less flexibility than code (no inheritance, etc.)
If you have lots of screens in your app, using a single storyboard can get pretty difficult unless you have a vast screen!
It depends only on you. If you developing your application alone, storyboards are very useful. If you work in a team, it's better yo use .xibs because there is less problems with merging them with svn in comparison to storyboards
Very broad question. There are times when storyboards are great and other times when they are a hassle. Depends on the requirements and compatibility needs of your app.
See this answer for a great explanation of when to use storyboards and when to use XIBs:
When to use Storyboard and when to use XIBs
I'm in the process of developing an iPad-only survey-app using MonoTouch. With monotouch.dialog (mt.d) I found that building these interfaces can come quickly, which is awesome.
However... I also found that mt.d only does about 80% of what I want. Makes me wonder: should I invest in extending mt.d to my needs or should I choose something differently over mt.d?
Some of my requirements:
Radiogroups without transitions: I like the options to be
presented right away (there's more than enough space on the iPad
screen)
A rating UI control, such as
http://www.cocoacontrols.com/platforms/ios/controls/dyrateview
Mixed radiogroups: like 3 predefined elements and a fourth which
allows for manually added content
What are your thoughts on this? Can this be done easily (I'm a trained programmer, but quite new to both C# and iOS development)? Do you guys know of any online repositories of custom UI components with C#/MonoTouch bindings?
Thanks a lot!
This is of course a subjective opinion, but my take on it is that if you believe you can do your UI in UITableView (which MonoTouch.Dialog is based on), then you should go for MonoTouch.Dialog. If UITableView will not fit your needs, you should look for a different approach. MonoTouch.Dialog is quite flexible, and open-source, so if you need anything to be different you can just use the source code and modify it at will.
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.