I’m gonna start this off being super 💯 with you guys. Since it released 6 years ago, I’ve never ever been jealous of anyone working on porting their iPhone app to the iPad. Never. Not once. (Did I say never? Yes? Good.)
I’ve witnessed the frustration and panic it can induce, both first hand working on various freelance projects and “day job” stuff at Apple and Twitter—and with coworkers and peers in our community. The truth is, while the iPad can be a magical, inspiring device…when it comes to actually making stuff for it, it’s simply not kind to designers and developers.
I know it’s been discussed ad nauseam, but even the most forgiving types of content can be difficult to fit into the constraints and limitations of the iPad’s ‘one-app-at-a-time, always-focused’ user experience. It often isn’t for the faint of heart — especially for an app like ours, which has a completely custom, gesture-rich interface, and whose content is literally just text.
So, with that on the table, I wanted to give a bit of color about how we got to this release, and talk about a couple of the challenges we faced and things we’ve learned along the way — not only from a design standpoint, but from product and business standpoints, as well.
Now on to the fun stuff.
1) Text is hard, navigation is hard, and something, something about the Romans.
The struggle is real when it comes to designing great reading interfaces, you guys.*
Truth be told, text-centric surfaces actually have less in common with modern software, and much more in common with another centuries-old interface…the printed page, and the bound book.
In the early days of the Roman Empire, printed text made the move from cumbersome papyrus and animal skin scrolls, to the single-edge bound book — which brought with it a tremendous leap forward in the portability, storability, and general ease-of-use for accessing texts. It was a huge jump in the fidelity and intuitiveness of navigating and traversing text.
The ‘book’ as an interface has now existed for nearly two thousand years, and yet, with the advent of these little ‘pocket screens,’ in many ways we’ve tried to reinvent the wheel, or “reinvent the book” I guess I should say. The fact is, there are generations of fundamental, learned interaction patterns at work when you read a book, so rather turn our backs on them, we decided to learn from them.
With NeuBible, we leaned into the book metaphor. No, not by putting in skeumorphic page turn animations and parchment textures (Hi iBooks 👋). Rather, we wanted to provide a simple, accessible structure that allows you to easily understand where you are, focus solely on text while reading, and effortlessly navigate when you need to.
Much like the spine of a book, or Leo’s spinning top in Inception, the colored spine along the left edge of NeuBible is your totem, always letting you know where you are. And also, just like a book, your content always lives to the right of that spine.
* This wasn’t necessarily isolated to the iPad, but it was definitely exacerbated by it.
2) Life in a really big sandbox
I have a rule of thumb, that whenever I start a new project, I try to understand the known, baseline constraints as quickly as possible. Having a sense of just how big the sandbox I’m about to play in is usually pretty vital to the overall ease or difficulty of a project, at least early on.
I imagine it’s obvious to just about anyone that having too many constraints, (a tiny sandbox), in any kind of creative endeavor can be stifling, but to have none? Well, that’s just inviting madness. Madness I tell you!
The same forces are at play when you sit down in front of a blank sheet of paper to write (or draw) when you start a constraint-less design project. When you can do all of the things, it makes it hard to do even one of the things. Our sandboxes need boundaries.
In a way, screens are a kind of visual sandbox…and the iPad, especially the Pro, is a big one when you consider it’s UX and UI constraints.
Full disclosure, we got lost in that giant sandbox pretty early with NeuBible. The general structure and navigation of the app, which makes a ton of sense on the constrained, portrait-oriented screen of the iPhone, completely fell apart on the iPad. Obviously no one wants book cells stretched across a 10" or 13" screen, and things like the physical distances digital UI elements had to travel in the analog space were so over-pronounced that we nearly started to worry about inducing motion sickness.
In the end, after a metric ton of iterations on how to implement the general structure of the app, we landed on simply letting the content and navigation coexist . It may seem obvious when you see the app now, but know that it actually took quite a bit of thinking and experimenting to land where we did.
Side note: While I was initially worried our approach was going to feel busy or distracting — not great for an app that promotes focus—I now believe it ultimately helps provide a better sense of place within the app, even when compared to its iPhone counterpart.
3) To sync or not to sync…
One of the biggest product consideration we had to make during development was how we were going to implement iCloud Sync across multiple device types.
When we originally implemented iCloud Sync, it was mainly as a way to make sure that you never lost your highlights timeline if you happened to switch devices or get a new phone. Once we started iPad development, though, we realized we had some considerably deeper considerations to make — namely how to handle the syncing of reading position, text formatting, themes and bookmarking.
We had some initial thoughts on how and why we would sync everything, but as we started using early builds of the app, we quickly realized that the contexts in which we used our iPhones and iPads were very different.
For example, let’s say you’re reading Facebook in line at the bank, then, later in the day you’re checking Facebook again on your couch at home—here, where you’re using the app doesn’t greatly affect it’s experience, as you’re still using Facebook in both places. Sure, you may feel more relaxed at home, and may spend longer reading or watching videos on the couch, but at the end of the day it’s the same content and the same experience, no where you are.
But for something like a Bible app, those behaviors don’t necessarily hold true. With NeuBible, we believe that content and context are very closely related. For example, say you’ve been reading through Psalms during the week at home — then, at church on Sunday, reference and read verses in Romans and Matthew. If your reading position was synced, you’d lose your place entirely on your iPad. This type of scenario makes deciding what to sync very tricky.
Truth be told, when we set out to build NeuBible, we wanted to build a simple app that provided what we call “beautiful, simple utility” — an app to use in church to quickly reference and navigate the deep, complex text that is the Bible, but that “beautiful, simple utility” isn’t quite as apparent or clear once you start using NeuBible for iPad.
Instead, what you get is a much more immersive, focused experience. Couple that with the fact that, generally, most people use their iPads either at home, the office, or in a coffee shop, and you start unfurling the potential drawbacks of syncing things like reading position and text formatting.
So, to summarize…I think the easy thing would have been to just sync “all of the things,” but we felt the right thing for the NeuBible reader was to just sync highlights.
4) Split View & Multitasking
One of the newest features introduced for the iPad with iOS 9 is multitasking and Split View. It’s a compelling, useful feature for many apps, but at the moment, for us, it isn't.
We know many of you will throw up your hands, gnash teeth and call us heretics, but know that when we set out to reimagine the Bible for the screen, we had a very specific vision and plan for what it would eventually become — and the Split View / multitasking experience Apple currently has implemented simply doesn’t fit that vision. We built NeuBible to be a focused, simple experience, and to that end we wanted to create something that takes you deep in to God’s Word and keeps you there—and stapling a giant notepad to the side of it isn’t part of that vision.
We do have a fantastic idea for notes in NeuBible, but until we can build it, we want to stand by our mission and not simply ‘tack something on’ that we don’t see as the best experience for users or the app.
All is not lost though. With Slide Over, you can always swipe over from the right and take notes in your favorite app, no matter what we build. It will always be there. We’re just not supporting Split View.
5) Lessons learned & making the move back to premium (aka “the business part”)
What no one really tells you is that deciding to build and release an app is starting a business in the same way that deciding to open a coffee shop is starting a business, or deciding to start a band because you “just want to make music” is also starting a business.*
Apps are products. Software is a product. That’s it, plain and simple. I think, in a lot of ways, it’s easy to forget this, both because of most people’s understanding of software, and the opaque nature in which apps are designed, built, marketed, and delivered to all of our devices. It’s almost as if the processes by which we consume and use them has become a bit too easy. Maybe it’s how small and ephemeral the things on our screens feel; maybe it’s Apple driving people’s perception of the value of apps to basically zero through App Store pricing — whatever the reason, it’s become easy to forget that there are actually people behind all of the great software and services we use every day.
When Aaron and I set out to build NeuBible two years ago, I don’t think either of us really grasped the road that was ahead. The idea for the app was born out of wanting to build something that we would want to carry and use every day, because none of the other apps out there seemed to be built for people like us. That was it. Simple intentions.
And yet, here we are…we just set out to release a little app, and we’re now neck deep in learning how to build a real business, (on the fly). It’s been an exercise in education, perseverance and patience. We’ve learned a lot over the course of the past couple years, (one of which we’ve been in the App Store), but we’ve also made a lot of mistakes. Truth be told, I think most of our mistakes have come when we’ve been reactionary, and not true to our original vision for NeuBible.
The prime example of this is when we went free just a couple months after we launched last March. For over a year we’d never questioned that we were going to launch as a paid app, and stay a paid app. We knew this would mean that our audience would likely be a small, but passionate group. We’d done the math and were ok with it. If we somehow came out of the gate stronger than expected, great, but it was more likely that we’d start modestly, and slowly grow the app (and business) from there. And yet, just a couple months in, when we saw how much difficulty we were having showing up in search (mainly because of Apple’s broken search algorithm) we knee-jerked and went free to try and get our download numbers up.
At the time we were seeing IAP numbers north of 30% for our (at the time) one available licensed translation, the NASB, and themes. We figured if we went free, despite making less than 20% off of most of the licensed translations, when we launched more translations, coupled with the fact that the barrier of entry was now zero, (free), we’d be fine. Only that’s not how it worked out.
Once we went free, we saw our download numbers pick up as expected — only our IAP numbers completely tanked, bringing in somewhere between $3 & $30 a day, and that’s before we pay out anywhere between 60%-80% for both Apple’s cut and the licensing fees we pay on our translations.
So we stand at a crossroads — continue to offer NeuBible for free and maintain our roughly 30 (free) downloads a day, making just enough revenue to support rolling out updates every 6–8 months, or make the shift back to premium and even though we’ll most definitely tank our download numbers, cross our fingers and hope we at least start bringing in a bit of revenue so that we can continue to invest in the future of NeuBible and make it a better app.
As you can imagine, we decided to go with the latter. So starting with today’s update, NeuBible will be priced at $4.99.
Don’t worry, if you’ve already downloaded the iPhone app you don’t have anything to worry about — it’s a free update. We aren’t playing the game of separating the builds and charging you again.
This honestly could all be a huge mistake. By going back to premium we could completely tank, but it’s a risk we’re willing to take. We care about NeuBible too much to let it just languish and fade.
*That came up in a conversation Aaron and I had with our friend Sam the other night, and it blew my mind. I’d never ever considered ‘bands as businesses’ before.
So to wrap it up, thanks for taking the time to read. In many ways this was difficult to write. Being honest about some of these things, admitting it’s a learning process and facing the challenges that come along the way isn’t easy — but if you’re a designer, developer, or are even thinking about building something in the future, I hope reading about our experience so far can help you in some way.
And I really do hope you love NeuBible on the iPad as much as we have. When you open the app for the first time and think to yourself, “Hmm, this just looks like a big version of NeuBible,” remember that it took a ton of thought, care and difficult decisions to get it there.
You can grab NeuBible on the App Store here.