The odd case of the iPad app

When launching our UK mobile current accounts in May 2017, we chose the two dominant mobile platforms - iOS and Android. Additionally, we decided to focus on mobile phones exclusively, building a banking app that would fit seamlessly into our customers’ mobile lives.

When it came to iPads, we didn’t need to adjust the app. We simply let it run on iPads in so-called ‘compatibility mode’, which is effectively an iPhone ‘simulator’ on iPad in the middle of the screen.

In the latest release of the iOS app, we’ve moved from ‘compatibility mode’ to a full-screen app - a change that I want to explain. I’d also like to share our reasoning behind this update and elaborate on constraints that affected us along the way.

Software & hardware limitations

iOS and Android run on tablets as their secondary hardware platform. Having the same operating system and application frameworks for smartphone and tablet is beneficial because you only develop the product once, but deploy twice. The software layer is not an issue. How about hardware?

Every year, Apple introduces progressive new hardware technology on the iPhone. Models of the iPhone introduced in 2017/2018 brought us features such as wireless charging, FaceID and the A12 Bionic machine learning chip. These new features are usually absent on iPads at the time of their introduction. Apple is however relentless on maintaining hardware feature parity across its mobile device families. The latest iPad Pro introduced in November 2018 now has FaceID. It’s clear hardware feature parity is also not a problem on iOS.

From Starling's perspective, these advanced capabilities do not matter at all. There are only two requirements for your device:

1. The ability to connect to a mobile network, i.e. to host a SIM card
2. A front-facing video camera for biometric authentication

As part of setting up or logging back in to the Starling app, we need to be able to send a registration code via SMS, which requires connection to a mobile network. The front-facing camera is part of the Identity Verification process - we do not have to see you in person; instead, you only record a short video and send it to us.

When Apple releases a new iPhone, it guarantees it will run future iOS versions within the next three to four years. This year's iPhone XS will be able to run iOS16. Likewise, when it releases a new iOS version, it guarantees it will run on past devices from the last three to four years. This year's iOS12 runs on iPhone 5S or higher.

For historical reasons, the app supports iOS versions from 9.0 up to the latest 12.1. That means any device capable of running iOS 9 can also run Starling. And the oldest device models to do so are iPhone 4S and iPad2. Although these models are both seven years old (already!) and positively ancient by today's standards, they both have the minimum required hardware - a SIM and a front-facing camera.

True, there are wi-fi-only iPads without a mobile wireless connection, but this is not much of an issue for us because all our iPad customers have either an iPhone as their primary device or an iPad with mobile connection. That means they are able to receive the SMS code during sign up or login.

How about user experience & design?

Both the iPhone and the iPad are highly mobile devices. The iPad, however, does not support the one-handed ultra-mobility of the iPhone. You don't have it readily available in your pocket anytime you need your bank. Its larger screen is in that sense a "liability" as it prevents you from performing one-handed ultra-short 5 to 15 second interactions with the product.

If your card is declined due to insufficient funds and you need to hastily take out £20 from a Goal, this won’t be so easy (or subtle) on an iPad.

Apple, by getting rid of the Home button last year on iPhone X, started moving towards gesture-only user interaction. On iPads, this will require a more stable posture while you interact with the screen so that you can use both hands. This excludes banking while you walk on the street or stand in an overcrowded commuter train. All these constraints make it a bit more challenging to use iPads on the go.

Where iPads really shine is in the following use cases:

1. within more stable environments with the user not moving much or at all
2. performing medium-to-long-lasting user interactions
3. where a larger screen provides a substantial business/customer advantage while using the product

Let's talk a bit more about larger screens. There are now seven different physical iPhone screens and six screen resolutions we support. The lowest iPhone model capable of running iOS 9 and Starling app is iPhone 4S with a 3.5-inch screen. For a comprehensive guide to iPhone resolutions, have a look at PaintCode’s website.

We programmed the app to have a flexible (stretchable) user interface (UI) and occupy the largest available area. That means it scales to screens ranging from 3.5 inches up to 6.5 inches. How well the UI works from a user experience (UX) perspective is a separate question and I’ll touch on that point a bit later. Scaling to a larger iPad screen is a much trickier proposition and design challenge though.

Even though iOS UI frameworks provide ample means for UI elements stretching, various interactive pieces of information naturally lend themselves to their optimal sizes within the available screen area. For example, if you stretch a button horizontally to fill the void, it often doesn't look right.

What if it’s a collection of the same data types instead? That’s easier to scale up, and it works well for certain types of content (image collections, maps). But sometimes, when you merely increase the quantity, what you get is diminishing returns. Our brains always look for patterns or unique stimuli. For example, if you quadruple the number of visible bank transactions from seven to 28 that will not increase the usefulness of the user interface four times. You’ll just see more of the same items, and, unless some new insight emerged, it’s not a dramatic difference.

Apple recognised this when it was preparing iOS to run on iPads, and it provides developers with a component called UISplitViewController. It allows splitting the content of the screen into two sections. Later, it also introduced the option of running two apps at once.

In its Human Interface Guidelines, Apple explains how to implement flexible elements and resizable screens. But that’s basically all there is. Even eight years after introducing the iPad, besides ‘splitting the screen,’ Apple has never published more sophisticated UI patterns and strategies to nurture the design community and help to make the large screen real estate more usable. This is surprising, given the revolution it brought about by putting design at the centre stage of product development.

Applying these adaptive techniques might as well be the right formula for the majority of businesses. For some, it might not work well enough. If you want a highly advanced, bespoke iPad user interface, you’re on your own. A good example is the World Wildlife Fund iPad app; the designers did superb work, particularly how the UX pulls you in into an unrushed, focused experience.

Does the Starling app scale?

To scale the UI, we use a framework called Auto Layout. In select cases we make additional tweaks tailored to a particular screen. (For example, the vertical position of the card in the Card screen is tweaked to each of the seven supported screen sizes).

When we design the app, our reference screen size is the iPhone 6 with a 4.7-inch screen. How are we doing when it comes to other iPhones screen sizes? The following table shows the overall quality of the UI and UX reflecting qualities, including proportions, aesthetics, usability, layout and ergonomy.

Size of screen	Model	Quality
3.5 inch	iPhone 4S	Poor
4.0 inch	iPhone 5/5S/SE	Limited
4.7 inch	iPhone 6/7/8	Optimal
5.8 inch	iPhone X/XS	Optimal
5.5 inch	iPhone 6+/7+/8+	Good
6.1 inch	iPhone XR	Optimal
6.5 inch	iPhone XS max	Good

Scaling to larger screens up to 6.5 inches seems to be working well. But the 4-inch screen of the iPhone 5/5S/SE requires a fair amount of manual tweaks.

The real trouble starts with iPhone 4S. It’s impossible to design our UI so that it would scale down well to the 3.5-inch screen. There is scarcely enough screen space to position content on it. Everything feels cramped and our bespoke custom UI elements such as the Pulse, the payment sheet and the Goals transitions do not work well on it.

What makes all this even more complicated is a quirky fact that when Apple reviews our release candidate builds, it uses iPads and runs the app in compatibility mode which effectively means our app is reviewed on a 3.5-inch screen. (In iOS 12 Apple finally changed this to 4.7 inches). Apple reviewers effectively get the worst possible Starling experience. We had a number of rejections in the past because Apple’s reviewers took issue with minor glitches like an element failing to layout correctly etc. This disrupts our release process and costs us time and momentum.

Taking all this into account, we have a number of options when it comes to iPad support, see the image below.

A bespoke UI and UX would certainly be a nice design challenge. Designers would have to rethink layouts, flows, address usability issues and figure out how to fit more information on a larger screen.

It would also mean changing our Information Architecture which would then have two branches - one for each device family. This would potentially double the amount of digital documentation present in our customer support systems. It would require more staff training and it would increase complexity of the whole Customer Service operation.

After careful consideration, we decided on running the app in full-screen. This will help us eliminate Apple review rejections and also improve the overall user experience for iPad customers. Plenty of space is still better than not enough space. The FullScreen+ approach means we will do a tweak or two once in a while to achieve improvements with negligible input, for example, the number of columns in Goals is now set to four on iPad.

What’s next?

We will also explore improvements such as running the app in landscape or so-called Slide Over and Split View modes. As a result, our overall development and support costs will remain the same. This change brings Starling customers an experience that is a bit closer to a desktop experience, all without having to rethink our security model. We are treating this very much as an iterative process; it opens the possibility of developing a more bespoke UI in the future.