As a beginning developer I'm wondering what the pros and cons are of using Storyboard vs. .nib files to build app interfaces.
I'm aware that:
Storyboards supposedly streamline the process of creating interfaces
Apps created with storyboards are not compatible with devices running pre-iOS 5
However, I'd like to ask people with experience what the unforeseen drawbacks or advantages may be to using one method over the other, and what experienced developers recommend starting out on. (I'll be developing both for personal and commercial use.)
Thank you very much!
Just starting out, I would stick with Storyboards till you are comfortable with iOS's style of Model-View-Controller.
Once you are more experienced, be sure to play around with individual nibs because you still might need to use them in conjunction with a Storyboard for things like PopOvers on an iPad.
The only drawback I've found with Storyboards are when you use them in a team setting. Only one person can ever be working on it at a time, because no version control software I've found merges conflicted Storyboard (I've tried SVN & Git) well and you usually end up with a broken Storyboard.
Personally, I find storyboards much easier to use than nibs. Especially because segues take out a lot of silly repetitive code to change view. Then there's the whole pointing out the obvious that it makes it a lot easier to get an overview of what your app looks like view-by-view all in one screen.
In all my developing so far, other than incompatibly with pre-iOS 5, I've found no drawbacks with storyboarding.
Related
I'm an experienced C/C++ Windows developer writing my first real iOS application. Since I don't really have to worry about backward compatibility, I decided to jump in and use the new Storyboard functionality in XCode 4.3. What I'm finding is that, while storyboarding holds out the promise of laying out all the screens in your application including segues and gestures without writing any code, the reality is that anything but the most trivial of programs don't work when you run them, usually failing unceremoniously with a very unhelpful error message. Worse yet, you can't step through the code to see what is wrong, because there is no code.
So my question is this: Should a new iOS developer develop without Interface Builder and Nibs and Storyboards at first as suggested by this article?
UPDATE 2020-04-03:
It looks like SwiftUI bridges this chasm nicely and will probably be the way to build iOS apps going forward. In SwiftUI you do have code to step through, and it gives you real time feedback in Xcode showing how your app will look when it is run. As of this writing, there is a great free 100 day course (no affiliation) that I've been enjoying which includes an intro to Swift. Recommended.
Yes! You should definitely use Storyboards to build your applications. One of the neat things about Interface Builder is that it doesn't abstract away the underlying concepts - you are still working with the same types of objects as you would in code (UIViewController, UIView, etc.).
This lets you still learn how UIKit works but experience the benefits of building your UI using a tool.
There is a WWDC presentation from last year that outlines the basics of using Storyboards in your apps:
https://developer.apple.com/videos/wwdc/2011/?id=309
This is quite subjective but I definitively agree. If you want to learn how iOS works definitively start the UI code first. Interface builder is useful to position elements quickly and accurately, but like the article mentions you'll be much more productive after you understand how the views and controllers work together.
My question is... Can we use Xcode to create a tweak for jailbreaked iPhone? Foe example if I want to add some button in the lock screen how can I do? How can I mod the GUI of the default iPhone applications?
This is a really old question, but David is actually incorrect on most counts.
You can add custom UI to jailbroken devices, create tweaks without Xcode, hook into anything you wish, and more, without even having the source code for SpringBoard or wishing for it to be extensible.
MobileSubstrate is a code replacement platform that literally allows you to do anything. You don't even need to be an expert, but admittedly, having at least a moderate grasp on programming and Objective-C concepts helps a lot.
What you're talking about cannot be done. You're assuming 1) that you will have the source code for Springboard (lock screen), and 2) that those programs are extendable.
Without having the source code (it's proprietary), you cannot make "Tweaks" to the lock screen. You have nothing to compile into the lockscreen.
While you can mod them by editing the internal plists (simple things like show title bar or disable rotation), you will not be able to add functionality using XCode.
To create "tweaks" you would have to rewrite the lock screen entirely, or insert very low-level hooks into the Springboard/iOS. This is not possible via Xcode alone, since Xcode is not capable of even installing iOS-level apps (all installed apps are user-level).
You need expert knowledge of the private framework calls, and possibly be capable of disassembling and reverse engineering the specific program you're trying to extend.
I believe a lot of people have heard of and even used three20 library for building their apps. What's the pros and cons of using it? what's your experience so far - starting from ramping up, app design, building, to approval, and future maintains...
I am interested in picking it up, attracted by the UI elements that not easily get from the official SDK.
I've started developing a new app with Three20. Little note: I've started iPhone Development about one year ago.
I was attracted by the UI elements too, so i thought I'll give it a try.
Downloading the source is strait forward, but when it comes to integrating Three20 to an App it gets difficult. I think I've need about half a day to get it running. The big problem was, that I'm using XCode 3.2.3 with iOS SDK 4.0 and the source I've downloaded was set to run on iOS 3.2. After I read a lot of blog-posts and stuff like that, I finaly managed to run my app on the Simulator and on Device.
The next steps were kind of easy. You can use the UI-Elements and Core-Functions of Three20 easily. Build your app using the URL-based-navigation is great. So Three20 does at lot of things you normaly have to care of yourself. E.g. normaly you have to alloc and init your ViewController, push it to your NavigationController and release it. In Three20 you only have to "call a URL" and the rest is done by the library.
From this point of view Three20 is really great. The next problems I faced was, when you want to customize or change the standard-build-in-components. I've spend a lot of time reading through the class documentation on Three20.info until I've managed to build my own TableCell. I've faced the same Problem, when I want to load my data a different way to a TableView.
Until now I haven't got any problems with some other libraries in the same project.
I think Three20 is great and easy. On the other side it can be quite difficult. If you like the UI Elements, you should give it a try.
The main problem with Three20 is you have to take all of it or none of it - you can't easily just choose a part you'd like to use.
It's worth searching out other projects that do things you might want Three20 for - like photo browsing.
I used it for a few time. The main con is that you must develop the entire project with the three20 library else some bugs will appear.
I inherited a project that had Three20 integrated just for the networking and the message controller. I don't like it. If you just use the functionality it provides, it works, but when you want to modify something you find yourself drowning in spaghetti code. You also discover a lot of bad coding practices – my favorite was a BOOL value being cast to an object pointer. Some of it looks like it was ported from Javascript. I set an intern to work finding all the parts we don't ever call and commenting out as much Three20 code as possible, and at least I no longer drown in compiler warnings. Now we're spending the time to write our own message controller, and I am looking for a different networking stack.
I have to do some XCode/iPhone SDK work tomorrow, and i would like to know how I can prepare on Windows. What is the closest I can get to XCode and/or Objective-C developer experience, ideally IOS or similar Objective-C GUI.
Can also be say an interface-builder that works in a similar way.
I know Hackintosh/Vmware solutions, I think it would take a bit to long, especially since i have an AMD laptop with not to much RAM (i do have an Intel netbook)
Remark 1
I might actually have access to an old Power-PC Mac (i saw in some other threads that this might be possible). Though the question still stands.
Xcode, iPhone and IB are substantially different development platforms to anything I have seen on Windows, in both large and small ways. You have practically zero chance of gaining any insight into Xcode/iPhone programming by tomorrow without using the real thing.
The little time you have would be best spent reading up as much as you can online.
I agree with Marcelo, your time would be best spent reading. The iPhone Dev Center is a good place to start. I suggest starting with the Objective-C primer and moving on to the iOS Application Programming Guide.
For an introduction to the tools (Xcode, simulator, etc) the iOS Development Guide is a pretty good overview.
The closest you can get is GNUstep and its associated tools. It's emphatically not the same as Apple's environment, but it's derived from the same lineage. Cocoa was derived from the OpenStep frameworks, as is GNUstep (and GNUstep tries to track Apple's additions, though they lag a lot). Xcode and Interface Builder evolved from the OpenStep Project Builder and Interface Builder, which were also the basis for GNUstep's ProjectCenter and Gorm. Gorm can even open Interface Builder's nibs.
I'd agree with Marcelo without a Mac OS running somewhere your chances will be very limited.
You can probably start trying out some ObjC with GNUStep for Windows. But i actually did not try it.
http://www.gnustep.org/experience/Windows.html
I have an iPhone app and would like to create iPad version of it. What is the best way to setup the project when you want an iPhone and iPad version of the app?
I don't see that I'm able to use the same code base since the iPad version will have features in it that the iPhone version doesn't. It seems as though maintenance is going to go up with two similar code bases for the same app.
Refactor the common portions out and create a new target. You're the only one who really knows what the best way to do that is.
I just went through this thought process this week myself, having a published iPad app which I wanted to create an iPhone version of, and I decided on using the universal app approach. I found it worked extremely well for my needs. Once you get past the project setup issues, and the tactics of design decisions of where and how you are going to split up your iPad/iPhone specific code, the universal app framework is pretty fabulous.
Along the way, I created a reusable universal app project template, which I then used as the starting point for my universal app. The code is open source, hosted on github, I encourage you to take a look at it as one way to approach your problem, knowing that it is a tested solution that worked for me. (Additionally, I welcome any contributions from anyone wanting to help make it a more useful project)
The github link is: http://github.com/ryanscott/rcloudlib/tree/master/Samples/rcuniversaltemplate/
In terms of maintenance, I am extremely happy with the minimal added work it takes to support both devices. Sure, it's more work than supporting just one or the other, but it is significantly less maintenance than two separate codebases, where the business & app logic is almost identical.
In summary: I strongly believe that using a universal app is the best approach to creating an app that runs on on both the iPad and the iPhone.
Since the features should be similar but the layout is separate, code base s/b ok but the ib should change - making things far simpler; now v4.0 is a different answer :)
Maintenance would go up a bit. But if you have your app written abstractly enough, it should be fairly easy to port it to other devices. (For example, if you never assume that you will always know the screen size, you should be able to change that fairly easily).
For other things, it may be a bit difficult. However, if you use the Model View Controller (MVC) paradigm of thinking, you should be able to develop both apps simultaneously with only about 1/3 of the extra work. (Keeping the same model and controller, and only swapping out the view, alternatively, you could include the controller in there, but I wouldn't).