I've done a bit of iPhone development (3 apps in the appstore currently) but the interface has been pretty plain. I've used the stock components for the most part (UITableViewController, etc.) with a little bit of customization, but for the most part everything looks pretty generic. I'd like to get started developing apps with a richer user interface, but haven't found any good resources to get me started.
What resources have you all come across that outline how to create more advanced iOS interfaces (both iPhone and iPad)? Books? Blog entries? Just looking at the apps I have installed right now, some of the interfaces I've been very impressed with are the ESPN Score Center, XFINITY TV, Facebook, etc.
What about 3rd party interface component libraries? Are there any you recommend that provide more advanced interface components than those in the stock iOS library?
I'd love to take a look at any resources that you recommend for getting started.
I love Ray Wenderlich's tutorials. He's got one on Core Graphics which allows you to draw your own Table Views with headers, buttons, and bezier-curved footers!
Here's a little secret that often gets overlooked: a lot of the cool UI elements you see are stock Apple elements that have been customised to the brink of no return.
The main reason for this is Apple have put a lot of time and effort into making components that just plain work. A UIScrollView, for example, has had many more combined hours of testing than any app you write could hope to achieve.
The trick is to know exactly how to customise elements. A UITabBar is a good example: I've seen several apps that use their own custom tab bars. The problem is, often they don't handle edge cases particularly well. You might have issues if somebody tries to hit two items at the same time (I've actually seen an app that used their own implementation of a tab-bar crash if you pressed two items at the same time).
But if you use Apple's UITabBarController and either subclass, categorise, or otherwise overload it to get the customisation you want, you get a lot of the low-level event handling stuff for free.
You would be amazed with what you can do with a UITableViewController, and you get things like view recycling for free (some of the apps I've worked on have things like independent cell resizing, customised animation of cells, horizontal implementations of a tableview, etc).
Not a particularly useful answer, I grant you, but the point I want to get across here is once you've designed your kick-ass UI step back and consider what can be achieved with the existing toolset before rolling your own. You'll thank me when you come to bug fixing!
I also like Three20. Until now I didn't use it in my projects, but I played with it. And there's some really cool stuff in it. ;-) I think that's one way to extend your standard User Interfaces.
Another really cool part is designing your own elements. I like this really. Because you then have in your App something nobody else has. :-D
I've started looking into using Opacity for Mac, it's a pretty neat desktop application where you can generate your own graphical elements (buttons, switches, icons, etc) and then automatically generate the CocoaTouch / Quartz2D classes and headers to drop in your app ... Some elements work best when they're natively drawn on the device, rather than stored/loaded as pngs, or whatever. Moreover, you get #2x Retina display support for free. While not an interface dress-up framework, the fact that it generates Quartz2D code for you makes this a real contender for anyone who's remotely graphically creative but short on complex 2D programming skills.
Speaking of beautiful interfaces, if you're looking for inspiration or actual graphical elements to put in your interface, I frequently get some great ideas at 365psd ... they actually provide the Photoshop documents to reproduce some eye dropping UI goods, for FREE. Some places may just give you a PNG, but this does little good if you want to scale it (#2x or iPad) or customize it to fit your needs. It's like open source for graphical UI design.
Related
I'm a totally blind developer who would like to do iPhone development. From what I've heard most of Xcode is accessible with voiceover, the screen reader built into the Mac. My understanding is that the interface builder is mostly to completely inaccessible for blind users. Assuming I can not use interface builder is there an alternative way of creating simple to moderately complex user interfaces? I really don't want to spend $600 on a Mac to find out that it will be nothing more then a paper weight for me.
You don't necessarily need Interface Builder. In fact, some friends who work at Apple say they mostly code the interface. If you can code so far, i'm sure you can code the interface as well.
I'm also a blind developer. Over Christmas I purchased a second hand Mac, and spent 2 weeks on exactly this.
It was certainly possible to develop a complete app without Interface Builder. I used tricks like setting the text in a label, sizing the label, and then programatically calculating the absolute position for the next control by adding some space between controls.
Probably like yourself, I've always wanted to create things myself as it's more fun, and you can experiment more quickly. There's also a certain amount of pride - if you can do it yourself, who needs to hire help.
But what I realised is that my UI was pretty functional, but not at all esthetically pleasing. Most iPhone apps don't just have UI controls on a plain background - there's often a lot of colorful icons and pretty backgrounds involved.
The deal braker for me, personally, was reading the Apple guidelines and seeing that you need icons which conform to some pretty stringent guidelines, in at least two different sizes. The application icon is important as this is much of how people choose whether to download something.
So, if I have to hire a designer to make my icons, I may as well get them to lay out the UI.
Ideally, Interface Builder would be accessible enough to drag controls onto a view (not possible today), and bind them to code. We could then develop an application with no regard for how the controls were layed out, hire a designer, let them do whatever they want with the xib and our code would continue working.
Just my thoughts based on personal experience - there are many resources for learning to create UIs without IB if that's the route you choose.
Interface builder is provided as one way to design user interfaces, but it does not do anything that can't also be done in code. It's a way of building object archives containing (mostly) user interface objects, which can be un-archived and used at run time. But the same objects and properties could be set up in Objective-C and would work just as well.
Apple usually does a better job with accessibility. If Interface Builder is not accessible, I suggest filing a bug at http://bugreport.apple.com/ about it.
Are there any major advantages/disadvantages I should take into consideration when developing an app which and deciding whether to creates parts (styled menus, pages with content with complex layout etc.) in HTML/UIWebview or doing it all native?
I would like to hear people's experiences with this.
Personally, I find that I tend to dislike web apps that are (usually) disguised as iOS apps. I tend to notice a lot of inconsistencies between the UI of a web app and a 'native' app, and most of the time, it bothers me (my biggest pet peeve is tapping a button and seeing it highlight with a little translucent black box around it like a link). Now, I don't represent the major user demographic, which probably won't care, but that's my personal opinion.
In terms of programming, I've never written a web app before, but I assume that it's going to be slightly less structured than a native app just because writing HTML, Javascript, and CSS doesn't force you to assume a certain project structure, unlike iPhone apps that have distinct views, controllers, and the like. Depending on what you want to write, this might be liberating, but can also get tangled very quickly.
As middaparka said, you can also use a mixture of the two systems if you'd like. I mean, I'm assuming you're just as good a web developer as you are an iOS developer. If you are stronger in one suit than the other, then I say that you should lean towards heading in that direction. I'd much rather see an excellently written web app than a badly written native app, and vice versa.
I suspect the major advantages/disadvantages relate to the user experience - a "native" UIKit based user interface will feel a lot more natural than manipulating items within a web view. (It'll also mean you can use more "standard" components like navigation controllers, tab bars, etc.)
That said, there's no reason not to use a mix of the two, with the main UI being implemented via the various UIKit objects and the content being provided via a web view.
I would also add that the biggest issue I've found with hybrid frameworks is that you add another dependency to your app.
For example, take a big iOS update. If your chosen framework breaks, your app breaks and you won't be able to fix it until the framework is fixed.
Also, right now there are many frameworks and you have to pray that the one you chose isn't flushed down the toilet or drops support for one of your target platforms.
Another issue is that in a web based app/component you are missing out on platform specific technologies and frameworks like core data, GCD (or any other threading model - which in web you might have do with e.g. Ajax),uitableview with caching etc.
Should you hit a wall when it comes to performance or storage,then you have many more options in the native framework.
I have a friend who is a graphic designer & user experience designer who will be collaborating with me to develop an iPhone app. He does not have previous iPhone experience. What is the best way to work with him on developing the user interface, i.e. custom colors for UITableViews, UIButtons, etc? We've looked into Photoshop mock ups, but that depends on me (the developer) implementing what he drew in Photoshop, which might get tricky.
Most of the methods I've thought of have long turn around time, i.e. he uses Photoshop, sends me the image, I develop, send him a test build of the app, he doesn't like it, rinse, lather, repeat.
Do you think it's feasible to set him up with Interface Builder so he can modify XIB files? Potentially, he could build and run the app in the simulator...
Does anyone have experience doing this? Any suggestions?
Thanks much,
-dan
This goes for a developer or designer. The best way in my opinion is to mock up designs in photoshop, debate on what is good and what is bad, then send the final mock ups to the developer.
The reason you want to do it this way is because your designer can't do everything he wants to do by simply using the IB. You need to allow your designer to express his creative freedom without the burdeon of figuring out how to use a piece of software correctly.
You can find plenty of templates of iPhone and iPad components on the web. Having those components will make it very simple for your friend to put together concepts. It will also keep things consistent so you can have an easier time implementing them.
A Great Collection of iPad Resources
iPhone Materials
One suggestion is to start with the elements that do not need graphic design but you know they will be there, this will be things like table views, tab bars, any UI element provided by UIKit or even custom UI elements that you make...I would say you will probably have most of your app made by this approach and will look VERY plain...once you have that basis you should be able to work with the graphic designer and identify where and what he needs to make, it should also be pretty easy for you to integrate it since it will probably be mostly images or textures, things like animations and such will have to be handled by you anyway...just a suggestion, hope its helpful
Omnigraffle is your best bet for quickly mocking out UIs. It produces nearly photorealistic mockups. It's easy for non-artist to use but can also utilize imported images of arbitrary complexity if he needs to do something fancy.
If you want my advice, keep the graphic designers away from the app until it is fully functional logically. They should only be brought in at the end of the process to tweak the UI.
They cause train wrecks if they come into the process early. Everybody in that field has been trained first and foremost to create visuals that attract attention. In an UI, that always translates into flashy, non-standard elements that turn into annoyance with repeated use. A good UI is essentially invisible to the user. Ideally, they should notice it only because they notice that they don't notice it. (It's all very Zen.)
People trained to attract attention in the blizzard of competing images of a media saturated world don't make invisible interfaces. They make "in your face" and "look at me!" interfaces that get old in a hurry.
Don't get me wrong: a good graphics person can really enhance an interface by the skillful and subtle use of proportion and color. Unfortunately finding a good UI graphics person is a challenge. Be prepared for fights over what works transparently versus what looks cool and draws attention the first time you see it.
Is there any reason to not write iphone apps without useing the interface builder?
(or in other words, is it ok to write apps without the builder?)
Personally, my applications use no NIBs within them, but that's more of a matter of how I started doing development than anything else. I transitioned over from doing Mac development (where I use Interface Builder almost every day) to iPhone from when the first beta SDKs were released. Initially, there was no Interface Builder, and even when it came you couldn't do a lot of things with it, so I never took the time to really get to know it on the iPhone. It's more a matter of me doing what I'm familiar with.
Jeff LaMarche makes a convincing argument in his article "Don't Fear the Interface Builder" for you to use Interface Builder wherever you can, and I encourage new developers to learn to use it first before dropping down to programmatic user interface generation. It saves you a tremendous amount of time for interfaces using standard elements.
Some people have argued that there is a performance benefit to be had using purely programmatic interfaces, but Matt Gallagher ran a series of benchmarks and found that this speedup is only typically on the order of 5-10%. If you really want to shave that last bit off of your application's startup time, you might be able to have the best of both worlds with Adrian Kosmaczewski's nib2objc, which generates Objective-C from your NIB files.
However, there are plenty of times that you'll need to manipulate interfaces programmatically, such as for custom views and animations. This code can exist in parallel with Interface Builder without too much confusion. Again, it's more of a matter of personal preference at this point, but my recommendation is to use Interface Builder due to the time it can save you.
I've never written an iPhone app that uses Interface Builder (.xib files), but that's just personal taste: I like applications to be 100% code.
The reason is that I don't like applications that require design-time tools if you need to change something later on. It creates a dependency that may not be a problem today or next month, but it can become a problem in 3 years time.
So, the answer is: yes, it's fine to write iPhone apps without using Interface Builder.
Sure, it's absolutely fine to write apps without IB. It takes a little bit more setup (I believe there are some modifications you have to make to your Info.plist file), but it's certainly possible, and people do it all the time.
Personally, I prefer using Interface Builder for most tasks, but usually just to get the basic layout in place (so I don't have to deal with calculating rects, etc). Any further customization I prefer to do in code.
You can edit .XIB files by hand if you want to. They're XML, after all. Can't help having at least one of them in the project. Alternatively, you can create all your controls from code. The latter takes less typing, as far as I can tell.
Then, there are some apps where a XIB file would be of no use. I'm talking about games, where artistic/design considerations beat the convenience of having native widgets.
So yes, it's OK on both design level (no native widgets) and implementation level (yes native widgets, but sans IB).
How do you design a UI like Facebook?
Is it hard to implement a custom skin into a iphone app? How is it done?
Do I need to follow apple's guideline? What if I don't want to?
How do you design a UI like Facebook?
Facebook's iPhone app appears to be built around using UITableView in various guises. It looks like it adheres to the Apple Human Interface Guidelines.
Is it hard to implement a custom skin
into a iphone app? How is it done?
Skins are just graphic elements that are designed to have their image components swapped out. They are not difficult to implement.
Do I need to follow apple's guideline?
What if I dont want to?
Apple will not penalize you for a non-standard interface. The only interface restrictions are (1) some issues of obscene content and (2) you can't create the illusion that the device itself is broken, has crashed or otherwise failed.
A bit of advice. Don't use non-standard interfaces.
Good interfaces are almost by definition standardized so that users don't have to think about them. Novel interfaces slow users down even if they have no problems otherwise. Just try switching rapidly between Mac, Windows and Linux sometimes. None of the interfaces has major problems per se but having to stop and think how to do something in each particular interface is a pain. You can create the same problem by using a good but non-standard interface within an app.
That is assuming of course that you can actually create a good interface. There are far, far more ways to make bad interfaces than there are to make good ones. Most interfaces fail even those designed by interface gods. The standardized interfaces are the result of tens of thousands of hours of testing and years of experience. You're unlikely to whip out something really new and useful your first time out.
If you try something novel I suggest you mock it up first and then test let people test it without giving them any instruction. You'd be surprised how complex it can get. We used to just make photoshop mockups and then ask test users what they thought each element did or which element they would choose to accomplish a particular task. We were surprised at how poorly our (the developers) perception of the interface overlapped with the perception of the users.
In sum, a novel interface is more likely to hurt your app than help it.
With regard to how to build an app like Facebook, check out Three20. In particular, the TTLauncherView is the class that implements the Springboard-like grid of icons.
3- You don't need to follow the AHIG. But be careful if you don't, because it's very easy to go wrong doing so. Users like to not have to learn anything new. They know the typical Apple software UI, so if you use it, users will know how to use your app as soon as they buy it. If you don't use it, it is important to make sure that the UI is exceedingly easy and intuitive, and looks good to an iPhone user's eyes (and fingers).