Custom vs native fonts in apps

Gili Sharrock
May 23, 2018 · 8 min read

A while back Trade Me had a custom brand font created by Klim Type Foundry, named Story Sans. Off the back of this, the question arose, what about the native apps? Do we use our new custom brand typeface or do we use each platform’s respective font, San Fransico for iOS and Roboto for Android?

The contenders

To inform our decision we carried out a load of research to determine the benefits and challenges of going custom or going native. Finding this information however, proved to require a lot of digging around. So, in the light that it might help some of you out there, here is a break down of our findings.

Android system font (Roboto)


  • Faster loading times
    Using a system font means that the font does not need to load before rendering text.
  • Designed for different screen resolutions
    Roboto has been refined to work across a wide set of supported platforms, screen sizes and resolutions. Using Roboto means that the app will inherently gain any improvements/changes Google makes to the typeface.
  • Type scaling (dynamic type)
    A typographic scale has a limited set of type sizes that work well together along with the layout grid. These sizes and styles balance content density and reading comfort. Type sizes are specified with sp (scaleable pixels) to enable large type modes for accessibility.
  • Automatic line heights
    As stated in the material guidelines, to achieve proper readability and appropriate pacing, line heights have been determined based on each style’s individual size and weight. Line wrapping only applies to Body, Subhead, Headline, and the smaller display styles. All other styles should exist as single lines.
  • Similarity to custom brand font
    In our case, Trade Me’s custom brand font has comparable metrics to Roboto and San Francisco, hence it is probably not distinctly visually different to most users. This means that we may not be losing out on as much brand presence as anticipated, yet we are gaining a lot for free.
  • Support for alternate languages


  • Brand presence and feel
    Ensuring that there are other means of strengthening the visual brand identity.

Android Custom font


  • Brand presence
    Using a custom typeface strengthens visual brand identity.
  • Consistency
    Using a custom font would mean that no matter what platform or device a user is on they will observe a consistent font.
  • Doable in small places
    Implementing a custom font system wide on Android is hard, but small doses is doable. There are places that we could use the brand font for bold titles/ brand impact (For example, on-boarding or zero states).


  • No support for alternate languages
    Unlike Roboto, most custom fonts won’t support alternate languages within the app. This may not be an issue initially, but means that the app will not be future proofed against enabling users to swap languages.
  • Personalization
    Android phone operating systems allow the user to choose a custom font for the device that essentially overrides the app font. This is completely out of the apps control and is pretty common amongst android users. As a consideration, this means apps (particulary Android) shouldn’t rely heavily on communicating brand through type.
  • Loading times
    Loading time for the app will increase as the font has to load before the text can be rendered.
  • System response to custom fonts
    Widgets are not all built the same way hence some will not respond as well as others to a custom font.

iOS system font (San Fransisco)


  • Dynamic type & features that save dev work
    As explained by Apple, San Francisco has a lot of features that make it highly legible. The font family named “SF” is used for iOS/Mac and “SF Compact” is used for Apple Watch. You can see the difference in round shaped letters like ‘o’, ‘e’. SF compact has rather flat vertical lines than that of SF.
  • San Francisco optimizes the typeface dynamically. The system will automatically switch the Display/Text fonts according to the text size as well as automatically implementing thoughtful tracking across different sizes and weights.
  • Using dynamic type allows designers to establish a type hierarchy such as “header” “header 1” etc rather than state specific point sizes. This means that apple will automatically deal with type relatively, layout fluidly and does not require a custom lookup table.
Source WWDC video Introducing the New System Fonts
  • Future proofing
    Using native fonts will future proof the apps in terms of changes and features that Apple add in the future.
  • Supports alternate languages


  • Brand presence
    Ensuring other means of strengthening the visual brand identity.
  • Future Fonts
    Using the system font in iOS doesn’t just mean using ‘San Francisco’ it means using whatever Apple defines as the system font going forward. This means that if Apple change the system font it could cause minor issues with app layouts.

iOS custom font


  • Brand identity
    Using a custom typeface strengthens the visual brand identity.
  • Custom Kerning
    There are kerning attributes for custom fonts in iOS, but has to be done manually.


  • No dynamic type unless we dedicate dev time
    Dynamic type is not supported by custom fonts. This means that if a user has a larger/smaller font size setting on their device, this will not be honoured within an app with a custom font. Users that use this feature are usually of an older demographic and utilize this tool for accessibility purposes. This will also create a jarring experience as all other apps on the device will appear in a larger font. It is possible to apply dynamics to custom fonts but this would require a lot of developer, design and test resource.
  • No support for alternate languages
    Unlike San Francisco, most custom fonts won’t support alternate languages within the app. This is may not be an issue initially, but means the app isn’t future proofed against enabling users to swap languages.
  • Rendering difficulty
    Custom fonts on iOS often have difficulty rendering at different sizes and may become unclear. Additionally, fonts may render with incorrect baselines and glyphs.
  • Jarring feedback
    With the keyboard set in San Francisco, directly above, the letters look completely different as you type. There are also platform interactions such as push notifications, alert views, share sheets and 3D touch menus, that are set in San Francisco and can’t be changed. Watch notifications are also set in San Francisco.
  • Point sizes across typefaces aren’t equal
    Point sizes across typefaces aren’t equal (i.e. 17pt SF won’t match 17pt so-and-so typeface), so there needs to be a bit of wrangling to find the right equivalents for all the system sizes.
  • Loading times
    Loading time for the app will increase as the font has to load before the text can be rendered.
  • Custom tracking
    Requires new code to be written and it’s a bit of a hack.
  • Inconsistencies with standard UI components
    Many components in UIKit are not easily customized. For instance, section headers and action sheets provide no documented way to alter their font. So unless these standard components are recreated, there isn’t a way to not have a mix of System and Custom font.

Final thoughts and considerations

These conclusions are based on Trade Me’s use case.

  • Considering value vs effort
    From this investigation it seems, that although possible, the effort that will need to be put into development is significant. We already have a massive code base so a lot of backtracking will need to be done if we were implement a custom font.
  • Similarity
    Because the Story Sans font metrics are heavily based on Roboto and San Francisco, we have to ask ourselves, is there any value in putting a large amount of effort into having a custom font that is not distinctly different? Are users likely to be able to tell them apart? Potentially something to user test.
  • Use of custom type for brand impact
    It will reduce the amount of development work significantly if we were to use a custom font in the app sparingly on specific pages for brand presence. This will allow the apps to have the best of both worlds.
  • Time boxing a first best effort
    If we are to investigate more into using a custom font in the apps, it has been suggested that we time box a first effort and see how far we can get and what challenges occur. From there a more informed decision can be made.
  • Where to invest our time
    There are other things that we can do on top of what we get for free using native fonts. For example, ensuring that our layouts respond well to using dynamic type and wrap fluidly, or ensure that we are doing all we can to make our typography as accessible as possible. This may be time better spent rather than trying to wrangle what we could have gained for free by using native fonts within the apps.

Going forward

As a result of this research it was concluded that for Trade Me, using a custom font didn’t make sense in the native app context. Spending time and resource solving problems around language and experience seemed more logical than having a consistent typeface across all of our platforms. It became obvious that in order to implement a custom font there would have to be compromises in terms of typographic detailing and most notably accessibility, a value that personally I hold very closely.

Currently our apps both use their respective native fonts. In the future we will potentially look to implement Story Sans on pages that have high brand presence such as zero states and on boarding.

Good reads & resources

@GiliSharrock on twitter if you’d like to get in touch

Default to Open

Life lives here. Stories about how we're building Trade Me.