Surprises When Designing An iPhone App | Hacker News Reader

Surprises When Designing An iPhone App

jackg.org

103 pointstroubleden53 comments

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.

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.

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.

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

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

Has worked really well for me, nice and simple.

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/

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.

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.

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.

I'm just an amateur, but I like to design as much as possible in vector graphics (I use inkscape) and then switch to bitmap (gimp for me, photoshop for most I guess) for the finishing touches. Makes it so much easier to scale stuff.

PS is really heavy. It's powerful, but cumbersome for app design. Indd is way faster if you're designing up flows. You can change a color universally, embed things in different files in one command, you can set styles for type so every header, subhead, paragraph, etc, is the same, and you can change that all at once across all you files/design. And if you make a style guide, it's a lot faster.

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.

> 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.

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.

"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...

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.

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

Thanks a lot for the link, I was going to write Markdown -> NSAttributedString library myself, because I couldn't find one. Right now I'm just using DTCoreText and convert Markdown to HTML on the server.

You might also want to look into GitHub's Sundown library. It's an awesome library and being written in pure C, you can use it natively.

The reason I wrote myself is that my use case was more markdown highlighting than markdown parsing. I needed to preserve the markdown source untouched, which Sundown doesn't support.

https://github.com/vmg/sundown

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

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

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/

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.

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

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

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.

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.

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.

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

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

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

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.

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.

> 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!

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.

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.

+1 on Testflight. May that day never comes.

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.

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.

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.

> 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.

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.

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.

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];

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...

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.

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…

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.

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

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.

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.

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

I like how every time is 4:20.

Reply on news.ycombinator.com