2

I'm currently working on an iOS project which has tons of labels/buttons/controls spread over dozens of scenes. Most of those controls were created using Interface Builder.

So, it's now my job to make sure that every control (especially the labels) is formatted with the correct font family, which is not the case at the moment because many devs simply forget to change the font (our font must be set programmatically since it's not included in IB) after adding the control in IB.

Is there a way to change the system font temporarily so it's easier to see where font-settings have been forgotten?

I've searched for:

  • Changing the system font programmatically
  • Changing the font in Xcode somewhere
  • Changing the font in the iOS simulator (maybe as a debugging option)

But I was unsuccessful so far. I can't be the only one with this kind of problem - it's just naturally tedious to set every single control font programmatically.

The only thing I could imagine is like overriding the base UILabel's drawing method with a custom font (wingdings anyone?), but that seems a bit excessive?

JiaYow
  • 5,207
  • 3
  • 32
  • 36

1 Answers1

0

You can try creating a category, which overrides the systemFontOfSize: method of UIFont or use method swizzling (you can find out more about method swizzling here: http://cocoadev.com/MethodSwizzling). Both are extremely ugly and shouldn't be used in production, but should be fine for testing purposes.

Here is an example category of UIFont:

@interface UIFont (SysFont)
@end
@implementation UIFont (SysFont)
+ (UIFont *)systemFontOfSize:(CGFloat)fontSize {
    return [UIFont fontWithName:@"YourFont" size:fontSize];
}
@end
Ivan Genchev
  • 2,746
  • 14
  • 25
  • Yea i wanted to avoid swizzling and had hoped there would be like a debug option somewhere, but using a category seems like a reasonable compromise. Should've thought of that myself. Thanks :-) – JiaYow Nov 29 '13 at 16:08
  • 1
    Update: Using this category would result in undefined behaviour (overriding an existing method with a category). Swizzling would be the only choice with this approach. I've still accepted your answer, since swizzling seems to be the correct answer. – JiaYow Nov 29 '13 at 16:17
  • Yes, according to the docs it may result in undefined behaviour and that's why I said they're both ugly and shouldn't be used in production. However you can suppress the warnings for that category with a simple macro: #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wobjc-protocol-method-implementation" // method goes here... #pragma clang diagnostic pop – Ivan Genchev Nov 29 '13 at 16:22
  • 1
    Suppression of the warning does not fix the undefined behaviour. However, I've now used your solution together with http://stackoverflow.com/a/12572483/886407. Implementing your category (hardcoding the fontsize to 50) and swizzling it did the trick beautifully. I even overrode fontWithName:size so it only returns a good-looking font when my particular font was used, thereby preventing screwups :-) Thanks! – JiaYow Nov 29 '13 at 16:48