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.
Related
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.
if mono touch is available than why we should use mac environment(sdk,xcode+Interface Builder)?
what are the disadvantage of monotouch compare to xcode?
I always prefer working in the language that is most philosophically aligned with the platform I am developing for.
That is to say, the frameworks the whole platform is built around were written for and in Objective-C. As such, if you are working in Objective-C yourself for a while you understand why things are built the way they are, and can also anticipate calls that might exist or behaviors.
Just as I would not develop for Windows Phone 7 in anything but Silverlight, I would not program the iPhone in anything but Objective-C in order to get the most out of the platform. New language? That's a benefit as people should learn new languages now and then anyway. And it's not like it saves you that much time to use a language you already know since a large majority of your time will be spent learning the frameworks (which MonoTouch lets you call into).
I feel like this needs an answer from the MT camp, too.
Why eat fish, if you can have meat? Why speak German, if English is understood? Why watch CNN if there is FOX? Why vote vote for the Republicans if there are the Democrats? Why...? And so on.
It is your choice! If you have worked with C# for a long time and want to have quick results on iOS, go MonoTouch. Especially if you have a collection of APIs or methods you can reuse, MT is the way to go. If you want to learn a new language (ObjC), go for it. Even if you use MT in the end, knowing ObjC is somehow crucial because it helps you understand why things work as they do.
Hello here is my personal opinion,
I've also been on .Net world for a while, when iPhone launched the ability to create native apps, it called my whole attention and i really tried to learn objc, i took 2 books and started trying and trying and trying like for a month and then I left iPHone programming due to you had to make tons of things than on .NET was a line away for example the GC.
When Miguel de Icaza launched MonoTouch i gave it a try and i realized that most of my previously done code was fully funcional (i've always tried to separate ui code from business code) and this is really the point of .NET on the iPhone, to bring most of your already done business logic to the device.
Also on objc you wont find anything like LINQ or var keyword, consuming web services on MonoTouch its just a few clicks away etc.
If you want to target the Android platform there is also MonoDroid (monodroid.net) wich its coming out later this year the stable release, you can give it a try right now on the beta state. Also if you want to target Mac OSX there is MonoMac. So you can share class libs between all this 3 platforms (also al mono/.net supported ones) without hassle not to mention it will work on windows too and viceversa (when possible) (Also dont forget about WP7).
The only thing you will need to worry about its the UI but most of your business logic should work. here is a complete list of .NET Assemblies supported in MonoTouch http://monotouch.net/Documentation/Assemblies and also MonoTouch exposes a C#/CIL binding to all the CocoaTouch APIs.
Also the support of the MonoTouch team is awesome you can just get on IRC ans ask a question and it will be answered right away, mailing list too :)
I really enjoy MonoTouch, i know that no language is perfect for all tasks, and Objective-C is no exception.
Every example, tutorial, and piece of documentation will be written in Objective-C, and mono will just be calling into Objective-C code under the hood. If you really feel like C# is worth mentally translating everything, and adding an extra layer in your code, go for it I guess.
As a C# developer, I've found Objective-C to be horribly painful to become confident with. It's taken about two months, and two excellent resources to get to this stage.
Get your Visa card out, you'll need to spend a total of $54.
1. The free Stanford "Developing apps for iOS" lectures.
Pure brilliance, and it makes learning Objective-C very clear.
http://itunes.apple.com/us/itunes-u/developing-apps-for-ios-sd/id395631522
2. The iOS Apprentice series.
This is where you'll need to cough up the $54. It teaches you, step by step, how to program in Objective-C, and the apps you build are actually pretty impressive. Part 1 (of the 4 parts) is completely free, so you can give it a go before parting with any cash.
http://www.raywenderlich.com/store/ios-apprentice
I've yet to find any iOS books which match the clarity and friendliness of these two resources.
Finally, don't buy any books unless they specifically say that they're for iOS5 and XCode 4. This latest version of XCode is simply too different to make them useful.
Disclaimer: I don't work for any of the resources mentioned in this thread !
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).