Surprises When Designing An iPhone App

http://jackg.org/iphone-design

by troubleden • 14 years ago

103 53 14 years ago

jackg.org

mrclownpants• 14 years ago

FWIW, I just downloaded the app that's referenced here, and it's quite nice. Well done.

10dpd• 14 years ago

"there must be an iOS equivalent of the <strong> tag, right? Apparently not."

Just use three labels, with the middle label set to bold.

unwind• 14 years ago

Doesn't that make you "too" responsible for the spacing? Is it as easy to get the distance between two labels to be exactly one space? Or can you include trailing/leading spaces in the strings, and have them automatically laid out?

Note: I (obviously) don't program for iOS, but the above recommendation would be non-trivial in the toolkit I know best (GTK+) which is why I'm curious.

div• 14 years ago

It does. Starting from iOS 6, UILabels can display attributed strings out of the box. If you need to support iOS < 6, the best approach is to use TTTAttributedLabel or NIAttributedLabel.

bennyg• 14 years ago

Sure it makes you responsible, but this is a very, very easy solution to the problem. Obviously, for dynamically iterating, an NSAttributedString is the "best" solution.

You just line them up in interface builder and use your eyes and the arrow cursor to get it right. For static text on a non-changing screen like this, this solution is probably the best.

duopixel• 14 years ago

If the app were to be displayed in other language it would mess up the word spacing.

muzzamike2• 14 years ago

At least you wouldn't need a new image for each new language.

chrisdevereux• 14 years ago

In iOS 6 at least, UILabel supports attributed strings. I have no idea what took so long either.

potatolicious• 14 years ago

Or, really, how thick the API is around it. Attributed strings won't see very wide adoption until someone (preferably Apple?) gives us an easy to use markup language around it.

Manually screwing around with NSRange's is not the way forward.

jamesjguthrie• 14 years ago

> Provisioning and distribution is a nightmare

I fully agree. I threw myself in at the deep end - never spent any length of time on Mac OS and only working from tutorials for Xcode, it was atrocious trying to figure it out!

bingoturdbell• 14 years ago

And since it's a closed ecosystem, there's no way for a startup to come along and make the process easier. It all lies on Apple.

BenSS2• 14 years ago

Testflight has made it a LOT easier, granted Apple could change things entirely one day and leave them dead in the water. XCode has significantly improved in auto provisioning too, still painful when something breaks, but not as bad as it was.

k-mcgrady• 14 years ago

Admittedly the first time I wanted to run an app on my device it took a while to figure everything out but this was back in 2009. Since then it's become an awful lot easier to provision and distribute. It's still much more difficult that it should be (Android and Windows 8 are much easier) but once you get the hang of it it's the same process every time.

richardwhiuk2• 14 years ago

It's deliberately hard, because developers are trying to implement a use case which Apple has tried to prevent.

The are four different options:

a) Developer builds which have to be installed using Xcode for each phone. That won't work for anyone able to install.

b) Ad-Hoc builds, which must be specified for each phone. Again that doesn't scale.

c) Enterprise builds, which install on a unlimited number of phones. This is fine, but everyone who installs them must work for the same company, and this is contractually required by Apple.

d) App Store builds, which obviously must be submitted to the AppStore.

What developers want is the ability to do an AdHoc build to anyone. This is restricted for the precise reason that it would allow someone (not Apple) to create a rival store.

Having said that, the error messages you receive could be a lot clearer when you mess the signing process up.

lazerwalker2• 14 years ago

Great overview!

A few sidenotes:

b) TestFlight (https://testflightapp.com/) makes ad-hoc distribution marginally better. Adding new users to the build still requires grabbing their UDID and mucking around with the provisioning portal, but installing/updating to the latest build is infinitely easier for your users.

c) As long as you're not blatantly flaunting Apple's rules and bringing in hundreds or thousands of users, you can most likely get away with using enterprise distribution for beta testers. I've gotten invites to a half-dozen iOS apps built by friends who release their friends-and-family beta using an enterprise profile to avoid manual provisioning hell.

ef4• 14 years ago

> Ad-Hoc builds, which must be specified for each phone. Again that doesn't scale.

It's not strictly one-to-one. You can stick all your test devices into one provisioning profile, and then all your builds will work on all the devices.

So the hardest part is asking your test users for their UUIDs.

richardwhiuk2• 14 years ago

Is it me, or is the tagline (“Your ticket to every ticket.”) near illegible? Black on dark blue seems like a terrible choice. I'd try white if I were you.

lazerwalker2• 14 years ago

"there must be an iOS equivalent of the <strong> tag, right? Apparently not."

It's not a silver bullet (it can sometimes give you a bit of a performance hit), but the Nimbus library has a UILabel subclass that makes bolding a substring a lot less painful than manual NSAttributedString munging: http://docs.nimbuskit.info/group___nimbus_attributed_label.h...

staufman• 14 years ago

Agreed. I actually wrapped this library with a simple HTML parser that can understand basic tags (<strong>, <b>, <a>, etc.) and translate them into calls to Nimbus.

At some point, I'd love to incorporate a Fireball markdown parser so that authored and styled content from our servers can just be pulled from our app.

SeoxyS2• 14 years ago

You might be interested in something I plan to open source at some point: a native Markdown lexing / parsing engine meant to be used to stylize markdown for Core Text / NSAttributedString.

Here's the meat of it in a gist: https://gist.github.com/29dabe4b6e762ee221df

michaelmior• 14 years ago

I found NIAttributedLabel to work quite nicely for this and it's pretty straightforward.

Lalabadie• 14 years ago

The typical solution where I work is, if I recall correctly, a TTTAttributedLabel: https://github.com/mattt/TTTAttributedLabel

Groxx• 14 years ago

For provisioning woes, do as much as you can within XCode (you can provision a LOT from the organizer). It takes care of a lot of the 'download this, then that, install these, don't forget X, etc' steps. Most tutorials on the interwebs won't send you down this route though, because it's relatively new (version 4.something).

tl;dr: open the Organizer, go to Devices, click Provisioning Profiles in the top left, and click the '+'. It does 90% of what you'll need.

If you need more, pick someone, and have them read every piece of official documentation they can find. It's all explained quite well, lots of troubleshooting tools are linked to and explained, definitely worth the day it'll take to have at least one person who understands it. But it will take a day. ONLY THEN should you go to Stack Overflow for remaining questions for this one - there's a lot of misunderstanding and too-old answers and "solutions" that only work for a single-developer business, all of which will just leave you in a semi-broken state that you don't understand enough about to get out of.

prawks2• 14 years ago

> have them read every piece of official documentation they can find

Ditto. Apple's documentation really is top-notch. Having a doc-guru handy is always a boon to productivity, at least in my experience.

Aqua_Geek• 14 years ago

While I agree with most of your points, I discourage doing everything from within Xcode. Yes, the Organizer will get you up and running and at least get your app onto a device, but anything beyond that it quickly breaks down.

flixic3• 14 years ago

I'm designing iOS and Android apps full-time for over a year now. A couple of tips from me:

- He's very right about previewing on the device. I like xScope better than Silkscreen, because it can stream anything, both file, or screen region, and overall it's a nice designer's utility belt. There's nothing like that for android, at least I haven't found anything that works, and Android needs this even more, because it usually uses OLED, not LED screens.

- Unless you have plenty of time and very little UI, you shouldn't optimise for @1x design. The key is to design @2x assets that are ALWAYS even. Everything has to be 2 pixels or even-sized, every line, button size, coordinate and so on. To achieve crisp, 1px lines on Retina, you can do 1px strokes (for example, on button), but you have to make sure they are inside evenly sized (round-)rect, and twice as "strong" (darker, lighter, etc.), so that when PhotoShop resizes that 1px line, its darkness is mixed with the next pixel inside the button, and looks right on standard resolution.

- Another app I highly recommend: Slicy. Saved me many hours of work, and can automate the whole process of exporting assets.

- Keep the asset naming consistent, that will make developers happier and more productive.

- Learn at least the basics of iOS and Android app development. Basics are easy, and you will learn how developers layout the interfaces. That will get you thinking while designing, what assets will allow developers to make the design easiest and simplest to implement. In many cases, a well-prepared PNG can save many lines of code.

eddieroger• 14 years ago

Can't agree enough with Slicy. It has saved me hours of time and headaches, as well as my designer. I think it's the kind of tool that has to fit your workflow, but if it does, absolutely worth it.

rpwilcox• 14 years ago

Absolutely agree with the last point. While I wouldn't expect a designer to throw down much Objective-C quickly, the "move this element 5 points to the right" game can be played by a designer.

Add 5 minutes of guidance from a developer and some forethought (subclasses for common button idioms in your app and how to apply them to elements; storyboard overview; a hand from a developer to hook up a table view cell nib, etc) could save the developers a lot of time. Even gawds, understanding the naming conventions around assets.

ed209• 14 years ago

Previewing on Android: There is this http://code.google.com/p/android-ui-utils/

flixic3• 14 years ago

Did you manage to get it working? Because me and a fellow android developer couldn't.

nwh• 14 years ago

I've found that Skala Preview is also a very solid app for live previewing. Somewhat different to others, it integrates with Photoshop for live retina previews. I've no association, its just a great app.

http://bjango.com/mac/skalapreview/

cageface• 14 years ago

Slicy is a gift from god. Not only does it save time but it makes it easy to do a full batch export of all assets, at 1x and 2x resolutions.

gdilla2• 14 years ago

My designer works in indesign, designs for 1x and scales up. As long as you know that images are 50%, it's much faster then doing everything in even pixels.

flixic3• 14 years ago

I can't imagine how app design in InDesign should work. Yes, InDesign has some effects, but they are not the same quality and power as PhotoShop's, and overall many of the tools lack pixel-precision that is needed.

Sure, it can work 90% of the way, but I'd recommend designing only in PhotoShop - it is the tool, best optimised for that.

prawks2• 14 years ago

You never know what it’ll look like until it’s on a phone

Add to that "You'll never know how it performs until it's on a phone". Not sure if it's exactly a surprise, but if this is your first app it may not be glaringly obvious.

whalesalad• 14 years ago

I highly recommend using Bjango's awesome Skala Preview app[0] on your Mac and iPhone when designing your interfaces. It essentially mirrors your current Ps canvas to the device and let's you see how it will look in native form. It's invaluable for a multitude of reasons. 1) things really do look much "better" on the retina than for example my thunderbolt or MacBook Air display. 2) a lot of people have a hard time with the initial jolt of designing for 2x the standard dpi. Most of the 1px lines you'll draw for the web need to be 2px in photoshop to appear as 1px on the device.

I have an equally long list of things I would love to share as a long time web developer who moved into iOS and wanted to do things "the right way". This post from SeatGeek and all of the Bjango articles[1] are excellent resources for someone getting started with this

[0] http://bjango.com/mac/skalapreview/

[1] http://bjango.com/articles/

justjimmy• 14 years ago

I never design an interface without checking with the developers I work with. Is this possible? What's the time frame? How hard would it be to iterate? Can we do this nifty slide and layering action?

Then check with the product team/manager - is it worth it? Do we have the time/resources for the extra level of 'coolness'?

Then check with the DB/Backend guys - would this flow work, these values, these sort orders, creating of these groups, how does it fit with legacy entries?

Then check with the test users with interactive mock ups/wireframes - does it fit together? Does it flow? Are there confusion anywhere in the sign up process? I see you are entering this ridiculously long user name that is going to break the design? No, don't go ther - back to the drawing board.

If you have OCD like me and your math is off (ie trying to retain a 1px border on both retina and non retina of a shape that consist of multiple strokes is just asking for trouble), you can spend ages tinkering. Luckily, and hopefully, non retina iOS will be phased out soon.

As you get better, you'll slowly learn to see ahead and anticipate all the moving parts but dang, it can be a tricky journey. Lots of learning to go for me.

ie: I've yet to come across a app that previews my mocks up to my iPhone nicely. ATM I'm using Box. Dropbox doesn't work cause they, for some reason, wants to destroy the file by compressing it while on a mobile device.

frytaz• 14 years ago

Yes, bolding word is not easy but we can draw it in Quartz... http://pastebin.com/vwcsz31Q

hayksaakian• 14 years ago

A lot of rough designs can be done in HTML with something like Ratchet. When you can commit to a mockup, start thinking about how to implement that in obj.c.

BenSS2• 14 years ago

Great rundown of the process for your first app! I do disagree that knowing web UI instantly qualifies you to build an iOS interface. I've seen some bad app designs from people very good at the web.

Generally, I think the problem is not respecting the minimum touch sizes, and not allowing yourself to use more screens and popovers. You can learn a lot just by reading the HIG, and looking at other apps though.

sandofsky• 14 years ago

For bolding text, create an attributed string and draw it with CoreText. http://stackoverflow.com/questions/8322020/display-nsattribu...

If you only support iOS 6, you can use a UILabel and set the "attributedText" property.

I notice a lot of new iOS developers jump to open source libraries to abstract away important frameworks. It might save an hour, but I think it's counterproductive to not do things by hand the first time.

nicw• 14 years ago

Adding a little more detail: To stylize your content, you create a 'mask' by specifying the character ranges that you want to change, and then applying attributes to the string

Snippet to take a gray-colored string "Hello World", and then make "World" show as a black color (from memory):

  NSString *theEntireLineOfText = @"Hello World";
  UIColor *boldColor = [UIColor blackColor];
  UIFont *myFont = [UIFont fontWithName:@"Helvetica" size:12.0];
  UIColor *baseColor = [UIColor grayColor];
  NSDictionary *subAttrs = [NSDictionary dictionaryWithObjectsAndKeys:
                              myFont, NSFontAttributeName, boldColor,NSForegroundColorAttributeName, nil];
   NSMutableAttributedString *mainText = [[NSMutableAttributedString alloc] initWithString:[NSString stringWithFormat:@"%@",theEntireLineOfText] attributes:@{NSFontAttributeName:myFont,NSForegroundColorAttributeName:baseColor}];
  // Make the word "World" black"
  NSRange range = NSMakeRange(0,[@"World" length]);
        [mainText setAttributes:subAttrs range:range];

jcromartie• 14 years ago

sigh

This just reminds me how I'm still trying to convince some devs (and customers) of the importance of having Retina graphics at all, let alone starting with @2x and then supporting @1x later.

muzzamike2• 14 years ago

I'm pretty shocked you didn't use TestFlight or some equivalent. Did you manually build test versions of the app on all your tester's devices? How did you manage getting them updates promptly?

I know TestFlight can seem a bit daunting but MAN is it worth it in the long run.

ryguytilidie• 14 years ago

I like how every time is 4:20.

burnblue• 14 years ago

I designed at 2x (even pixel sizes) for a long time. Now I design at 1x using vector shapes. With vectors you can double the size and remain perfectly crisp. My workflow is now MUCH faster.

Bonus: 1x comps are better sized for clients to view on non-retina screens anyway. I always got complaints showing giant 640px wide mockups…

epaga• 14 years ago

Getting bold and non-bold text in a UILabel with NSAttributedString seems like it's just one Google -> StackOverflow search away: http://stackoverflow.com/questions/3586871/bold-non-bold-tex...

Don't know which "experienced" iOS developers they asked, but it does not seem like that should take very long to accomplish...

Surprises When Designing An iPhone App

Related Stories