7 ms·

Surprises When Designing An iPhone App

103 points by troubleden 14y ago

mrclownpants 14y ago
FWIW, I just downloaded the app that's referenced here, and it's quite nice. Well done.
10dpd 14y ago
"there must be an iOS equivalent of the tag, right? Apparently not." Just use three labels, with the middle label set to bold.
- unwind 14y 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 14y 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 14y 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 14y ago
 If the app were to be displayed in other language it would mess up the word spacing.
 - muzzamike 14y ago
 At least you wouldn't need a new image for each new language.
- chrisdevereux 14y ago
 In iOS 6 at least, UILabel supports attributed strings. I have no idea what took so long either.
 - potatolicious 14y 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 14y 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 14y 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.
  - BenSS 14y 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.
    - chj 14y ago
      +1 on Testflight. May that day never comes.
- k-mcgrady 14y 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.
- richardwhiuk 14y 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.
richardwhiuk 14y 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.
lazerwalker 14y ago
"there must be an iOS equivalent of the 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.html http://docs.nimbuskit.info/group___nimbus_attributed_label.h...
- staufman 14y ago
 Agreed. I actually wrapped this library with a simple HTML parser that can understand basic tags (, , <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 14y 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 https://gist.github.com/29dabe4b6e762ee221df
 - andrew_k 14y ago
 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 14y ago
 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 https://github.com/vmg/sundown
Groxx 14y 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.
- prawks 14y 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 14y 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.
flixic 14y 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 14y 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 14y 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.
prawks 14y 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 14y 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/ http://bjango.com/mac/skalapreview/ [1]: http://bjango.com/articles/ http://bjango.com/articles/
justjimmy 14y 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 14y ago
Yes, bolding word is not easy but we can draw it in Quartz... http://pastebin.com/vwcsz31Q http://pastebin.com/vwcsz31Q
hayksaakian 14y 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.
BenSS 14y 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 14y ago
For bolding text, create an attributed string and draw it with CoreText. http://stackoverflow.com/questions/8322020/display-nsattributedstring-using-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 14y 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 14y 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.
muzzamike 14y 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 14y ago
I like how every time is 4:20.
burnblue 14y 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 14y 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-text-in-a-single-uilabel 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...

103 points by troubleden 14y ago

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

10dpd 14y ago

"there must be an iOS equivalent of the tag, right? Apparently not." Just use three labels, with the middle label set to bold.

unwind 14y 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 14y 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 14y 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 14y ago
If the app were to be displayed in other language it would mess up the word spacing.
- muzzamike 14y ago
  At least you wouldn't need a new image for each new language.
chrisdevereux 14y ago
In iOS 6 at least, UILabel supports attributed strings. I have no idea what took so long either.
- potatolicious 14y 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 14y 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 14y 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.
- BenSS 14y 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.
  - chj 14y ago
    +1 on Testflight. May that day never comes.
k-mcgrady 14y 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.
richardwhiuk 14y 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.

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

lazerwalker 14y ago

"there must be an iOS equivalent of the 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.html http://docs.nimbuskit.info/group___nimbus_attributed_label.h...

staufman 14y ago
Agreed. I actually wrapped this library with a simple HTML parser that can understand basic tags (, , <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 14y 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 https://gist.github.com/29dabe4b6e762ee221df
 - andrew_k 14y ago
 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 14y ago
 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 https://github.com/vmg/sundown

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

prawks 14y 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 14y 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.

flixic 14y 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 14y 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 14y 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.

prawks 14y 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 14y 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/ http://bjango.com/mac/skalapreview/ [1]: http://bjango.com/articles/ http://bjango.com/articles/

justjimmy 14y 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 14y ago

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

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

BenSS 14y 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 14y ago

For bolding text, create an attributed string and draw it with CoreText. http://stackoverflow.com/questions/8322020/display-nsattributedstring-using-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 14y 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 14y 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.

muzzamike 14y 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 14y ago

I like how every time is 4:20.

burnblue 14y 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 14y 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-text-in-a-single-uilabel 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...