

Surprises When Designing An iPhone App - troubleden
http://jackg.org/iphone-design

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

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

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

~~~
guelo
Has worked really well for me, nice and simple.

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

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

------
lazerwalker
"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...](http://docs.nimbuskit.info/group___nimbus_attributed_label.html)

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

~~~
SeoxyS
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>

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

~~~
SeoxyS
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>

------
whalesalad
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/>

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

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

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

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

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

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

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

------
sandofsky
For bolding text, create an attributed string and draw it with CoreText.
[http://stackoverflow.com/questions/8322020/display-
nsattribu...](http://stackoverflow.com/questions/8322020/display-
nsattributedstring-using-coretext)

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

------
epaga
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...](http://stackoverflow.com/questions/3586871/bold-non-bold-text-in-a-
single-uilabel)

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

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

------
burnblue
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…

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

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

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

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

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

------
ryguytilidie
I like how every time is 4:20.

