I guess I’m going to have to address this issue at some point, so here we go.
Apparently one of the more controversial decisions we made with PocketBible for the iPhone was to follow the other major eBook reader software like Kindle and eReader and present the text a page at a time rather than continuously scrolling. That is, to move through the text of a PocketBible Bible or book, you swipe right to left (or just tap on the right side of the page) to “turn the page”. The new page enters from the right.
The alternative is to present Bibles and books as a long stream of continuously scrolling text and allow you to use drags and flicks to smoothly scroll the text. This method is followed (with some variations) by some other Bible software programs.
You Only Think You’ve Seen Continuously Scrolling Text Everywhere
People tend to point to applications like Safari, which lets you flick around on a Web page to scroll up, down, left and right, and claim that “all iPhone apps let you flick to scroll”. This is true when you have a limited amount of text, but not when the text is virtually unlimited. For example, a Web page is a finite amount of text (and images and whatever). It can be rendered once into an in-memory buffer, then portions of that buffer can be moved onto the screen as needed. More importantly, the overall dimensions of the page are easily determined. The programmer can tell the iPhone “I’ll be scrolling around on a 1391- by 3287- pixel image of this page.” That way, the iPhone knows when you’ve hit the “top” or “bottom” of the page and can do that cool “bounce” animation it does when you try to go past the edges.
Even large scrolling lists — like your list of contacts or PocketBible’s search results list — have bounds that are easily determined. It’s easy to count your contacts or your PocketBible search results, multiply by the height of one contact or search result entry in the list, and tell the iPhone the result. So 25,000 search results times 80 pixels is 2,000,000 pixels. If you go past 2,000,000 the iPhone knows you’re at the end and stops asking for more (in this case it actually stops because you’re looking at the 25,000th item, but down inside the code it’s animating the end-of-list behavior based on the y-coordinate being greater than or equal to 2,000,000).
The iPhone needs to know how tall your view is going to be. The problem with the text in PocketBible is that it’s practically infinite in length, and the time it would take to calculate the height needed is probably measured in hours (or at least in minutes), not the milliseconds you expect when you open a book or change the font/size you’re using to display text. The iPhone needs to know this height and we can’t calculate it in a timely fashion.
There are ways around this, but because we can’t calculate the height in advance we’re violating a built-in assumption the iPhone has about scrolling views. So that means we have to code our own scrolling view or at a minimum do some nasty jury-rigging to fake the iPhone into believing it has a finite-length view when in fact it doesn’t.
You’ve probably run into apps like Facebook which shows you 25-50 items in a list then allows you to press a button to load more. Again, you think you’re seeing a long, continuous list but in reality you’re seeing a short, finite-length list and you have an option to see a longer, finite-length list. You just think it’s an infinitely long list.
When To Load the Text?
Because the text of the Bible or a reference book is so long, it’s impractical to load the whole thing into memory at once (both to determine its size and to have it available for continuous scrolling). So we use techniques that allow us to load the text in pieces. (In our case, one paragraph at a time.) The problem, of course, is that it takes just as long to load the whole book one paragraph at a time as it does to simply load the whole book into memory. To get around this, we make use of idle moments (such as while the view is “coasting to a stop” after a flick) to load some more text. Normally the processor isn’t doing anything during this time, so you don’t notice that we’re loading text at that time.
The problem is that it can take longer than that time to load a paragraph. And you may be furiously flicking through text, not giving us time to do any loading. In these cases, we end up using time that is normally spent to recognize your input gestures. As a result, the system seems to be slow to recognize your gestures, and the motion of the text gets jerky.
At some point, we have to draw the text to the screen, which also takes time. One option is to launch a second thread to draw text that has been loaded and decompressed. But since the iPhone has only one processor with one core, this second thread is no more efficient than the method described above (using idle time on the main thread).
Furthermore, there are limits on what kind of drawing you can do in a second thread. Because the iPhone is a relatively new OS and doesn’t have the maturity of, say, Windows Mobile (which, like iPhone OS vs. Mac OS, is also a subset of its desktop counterpart), there are significant missing components for drawing text in anything but the main thread. Apple assumes you’re going to do all your text rendering with its built-in Web view component. But it, too, is an immature component and doesn’t have all the features we need to support everything we need to do with and to the text. So they give us one really nice why to draw text, but limit it to only being used in the main thread of the application. The text functions that can be accessed from other threads are more limited in their scope.
A Little History
Our initial implementation of PocketBible used continuous scrolling. We released an alpha version (a preliminary release that was nowhere near feature-complete) to a small group of testers in January 2009 with the goal of releasing the finished product in March. Because of all the problems described above (and more), the scrolling was a bit clunky. I actually thought it wasn’t horrible once you got used to it, but the alpha testers hated it and sent us back to the drawing board.
For the next six months I tried variations on when to load text, how much text to load, what thread to load text in, when to draw, what thread to draw in, etc., eventually writing at least four complete, from the ground-up, implementations of loading, rendering, and scrolling text. Late in the process I threw it all away and started again and had a relatively good implementation. We released beta 1 and the testers weren’t happy with the scrolling performance.
This was pretty disappointing. We were tempted to just go ahead with this implementation, but when we tested with the newly released OS 3.0 the performance was significantly worse. Something had changed with the new OS and would have required starting over again.
What do the Other Guys Do?
At this point I paused and did a survey of other similar software. I wanted to see what kind of performance they were getting during scrolling, and if there was anything I could divine from applying a programmer’s eye to the use of their software. I opted to look at general ebook software like Kindle, eReader, and Stanza. I chose not to look at other Bible software because the general ebook readers have larger user bases and well-funded, professional development teams.
What I found was a constant use of a “paging” metaphor as opposed to “scrolling”. This was interesting. If they were “getting away with this” with their enormous customer bases then potentially we could do likewise.
User Fatigue and Reading Comprehension
Within a couple days I had a paginated user interface up and running and for the most part, the beta testers liked it. Sure, there were those who really wanted to scroll. But there were others who actually preferred the paginated approach. They found it required a lot less concentration on manipulating the text and allowed them to focus on reading. Their fingers weren’t in the way all the time. And when they tapped the screen they knew it was going to move exactly one page instead of flicking and having to figure out when/if to stop it from scrolling too far, then having to find their place.
This was encouraging because it gave us some very real benefits to the new approach. Paging required less interaction and less concentration on navigating, thus allowing more concentration on reading and comprehension. And the performance was adequate and the implementation simple.
At about the same time my daughter was complaining about a college class that required them to read hundreds of pages of PDF files from the professor’s Web site. The school made the case that this was part of their “green” initiative, but my daughter found that in order to easily read and mark up the text it was necessary to first print it, thus negating the green argument and costing her a fortune in paper and ink. (Ironically, whereas the school could easily have printed this material on a two-sided printer, my daughter could only print on one side, thus costing TWICE as many trees as the “non-green” solution.)
This led me to do some research on online reading vs. reading in print. It seems to be a consistent conclusion that offline reading (from paper) results in better reading comprehension. One of the reasons that was cited was that the eyes can easily go from line to line and from page to page in print, but when reading from the screen the eyes have to constantly adjust for the motion caused by scrolling. The difficulty of moving the screen to the next full screen of text resulted in the eyes and brain having to continuously re-locate their position in the text. The resulting diminished comprehension negatively impacts test scores and was one more point against my daughter’s school’s “green” initiative.
Interestingly, the results of this research could easily be applied to what we were doing on PocketBible. When you flick the text you have to stop and figure out where you’re at. When you turn a page you know right where to continue reading. If you avoid this by slowly scrolling as you read, your eyes can’t move from line to line as easily as they can when those lines aren’t moving. And your fingers get in the way.
So Where do we Stand?
In summary, the reason PocketBible doesn’t have continuous scrolling isn’t because we haven’t thought of it. It’s because we’ve tried several ways of doing it and none has resulted in acceptable performance.
While pagination started as a second-choice user interface, it turns out it’s used by all the large, well-funded, popular ebook reader software for the iPhone. And it turns out it has documented benefits when it comes to user fatigue and reading comprehension.
It cannot be argued that pagination is “not the iPhone way”. The large, continuously scrolling text often cited as examples of “the iPhone way” isn’t actually as large as our text. And there are lots of similar applications that don’t use scrolling as their user interface for books. So while it can be said that continuous scrolling is an iPhone way to interact with books, it cannot be said that it is the iPhone way.
I’m aware of the fact that other Bible software uses scrolling instead of paging. I’ve heard conflicting reports on whether they do this successfully or just “acceptably” in the opinion of their users. I’ve also heard that some do continuous scrolling within a chapter (thus avoiding the problem of having a large amount of text) but then have another gesture that means “next chapter”. This is great for Bibles but doesn’t solve anything for other types of reference books. And it creates a weird concept of “sometimes you flick to scroll and sometimes you have to do something else” to see the next bit of text.
I don’t have any insight into the other guys’ code so I can’t comment on why they may get acceptable scrolling behavior when we don’t. Maybe their standards aren’t as high. Maybe their code isn’t as feature-rich. Maybe they’re better programmers than we are. In the end it’s irrelevant. We are all playing the cards we were dealt. Knowing someone else at another table has a better hand than I do doesn’t mean I can win at my table. To continue but convolute the metaphor, you can either stay in the game with us or you can go play with someone else. We can’t control your behavior.
We have not disclosed our plans for any future features of PocketBible, other than to say we’re continuously working on it, and that the features you see in other versions of PocketBible will find their way into the iPhone version in the future. We have a long list of must-have features in PocketBible and a long-list of suggestions from all of you. We consider the must-have list to be the more important one at this time. We’ve been implementing little things from the suggestion list as we work through big things on the must-have list, but are prioritizing useful new functionality over simply changing the way things work.
Pagination is a feature that is not broken and doesn’t need to be fixed. While we may look at wasting another six months on scrolling in the future, we’ll do that at a time when it won’t cause other very necessary features to be delayed.
Before You Comment…
This article is meant to be informative, not to launch discussion. We already know that some of you would prefer to scroll rather than page through the text. If you’re just writing to tell us that, then you must not have comprehended this article very well. Try paging through it instead of scrolling. 
Furthermore, this article summarizes some complicated programming issues into imprecise layperson’s terminology. Like a paraphrase of the Bible, there is a lot lost in the process. If you are not a programmer and think you have an idea for doing this in a way we haven’t tried, don’t bother to comment. Chances are good you don’t really understand the issues and I won’t be able to tell you that without insulting you. If you’re a programmer and are sure you know how to do this better than we do, I remind you you haven’t seen our code so don’t know what we’re working with, then ask you to send completed, working code to me by email instead of discussing it here where we’ll only confuse the masses.
Comments are moderated. I will remove references to other iPhone programs. I will remove feature requests and off-topic posts. I will remove links to other sites. I may remove other things I haven’t thought of.
Now, other than the above, feel free to comment.
Jack,
Perhaps I wasn’t clear. It’s not the case that we’re refusing to give our customers what they want. It’s that there are two competing points of view here. One side is getting what they want. The other side is being encouraged to reconsider.
While I was spending the first half of this year trying to give you what you wanted, Jeff — my fellow programmer and co-founder of Laridian — kept saying, “Why don’t you just do paging?” I thought scrolling was better and fought to keep it that way. Ultimately I resigned myself to paging, but in the process discovered that a) it’s what the Big Guys do, b) it can be argued that it produces an overall better reading experience, and c) I ended up liking it. So the article isn’t my way of apologizing for not giving you what you want, but rather it’s a note from someone who, like you, thought he preferred scrolling, explaining why you might like paging better, too, if you just give it a chance.
I also want to clarify that no version of PocketBible for Pocket PC has ever implemented “iPhone-like” continuous scrolling of the text. Versions 1 and 2 presented one chapter at a time and allowed you to scroll through those. Starting with version 3 you had the implementation much as it is now, which does a variation on paging (while providing for line-at-a-time scrolling and auto-scrolling).
Glad to hear you’re enjoying the program.
I really don’t want to post with so many comments and so much time in this post that could be used for further development of PB.
I have to though. I feel very strongly. I read Tom’s comments above about how we are getting this for free – well I would guess I’ve spent over $1000 on books from Laridian. I read we who want what is a universal iPhone feature (and as has been mentioned very intuitive) should reconsider.
Initially I didn’t care about pagination. In fact I thought I would like it better. When I first used iPhone and tried a few bible apps I DIDN’T like the scrolling method implemented on the one I chose. I soon grew accustomed to it though.
After owning the iPhone for a few months it is natural, regular and intuitive in every app I own to scroll up from the bottom to read more text. I have continually heard the argument about ereaders – but I don’t use them and neither would I.
What I do use is the iPhone – A LOT. I have over 100 applications. I would guess I use it as much as nearly anyone. PB is the ONLY app I have that CONTINUALLY confuses me and does the opposite of what I want. When I flick to scroll more text it changes books on me.
And here lies the problem. new or ‘light’ iPhone users will like and be used to left to right. It’s no issue. But for people who use the iPhone platform a lot it is logical for the text to go up from the bottom of the screen.
If Laridian can’t do it so be it. But don’t let that be the end of it!
I have continually re-iterated this and will do so again.
WHY NOT CHANGE THE TAP ZONES? If you have to paginate (for whatever reason) then PLEASE let us change the tap zones so that those of us who use the iPhone A LOT will get the next bit of text when we scroll (or tap) up.
Everyone I know with PB on the iPhone has the same gripe. They can’t understand why it doesn’t scroll. Why does the book change when I try to go to the next page?
I have used PB from day one and I can not get used to left to right. Sure in one sitting I am doing it fine. But then I use the iPhone for 50 other tasks in other apps (all of which us up/down) and come back to read the Bible and I am back to square one.
Can I also encourage you to use beta testers who use the iphone for a minimum of 6 hours a day with other apps – not ereaders
Even though I own so many books and think some of the features in PB have potential – I still prefer the other Bible app I have (with hardly any books) because it use scroll (up down).
Thanks for your comments, Adam.
We’ve said before we’re going to give you configurable tap zones.
I disagree with your assertion that scrolling is “a universal iPhone feature”. The difference between your argument and mine on this point is that I’ve backed mine up with examples and you simply assert yours as true when it is not.
I sympathize with the question you and apparently everyone you know asks: “Why doesn’t it scroll?” That’s why I wrote the article. Perhaps you should re-read it for the answer. And perhaps you should introduce yourself to some more PocketBible users. Comments are running about 3-1 in favor of paging here.
Here’s a hint for you: As soon as you start to drag the text and realize it isn’t moving, pause for a second with your finger still on the screen. Use this time to curse if you’d like.
Then lift your finger. You’ll find it doesn’t switch books if you pause for a little bit.
And at your request I’ll now go back to coding the free PocketBible program here on Saturday morning of Thanksgiving weekend while the daughters and grandkids I seldom see are playing out in the living room, just as I did yesterday and all day on Thanksgiving Day before that.
Happy Thanksgiving!
Hi. I’ve always preferred paging. Simpler, crisper, less effort. Thanks
Craig,
I’ve read the article, past blog posts, and multiple other discussions, and I have been using Laridian products for many years. While there are obvious stated technical reasons, isn’t the real reason for paging simply because Laridian wants to differentiate PocketBible from other Bible apps? By providing a “continuous” reading experience, it sets itself apart from the competition.
I have purchased and used MANY other iPhone-based Bible readers, both free and paid. Of note are BibleScope and AcroBible NIV. Each has a rich feature set and simple user interface. Interestingly, they ALL scroll, and they all stop at the end of each chapter or book requiring the reader to swipe or tap to get to the next chapter or book. In this one aspect, PocketBible IS different. PocketBible doesn’t care where you are in a book or chapter, it just keeps you going throughout the document.
While I personally prefer scrolling, PocketBible’s continuous reading does stand out. (I’ve tried to like paging, and though I really don’t like it, I know I will adapt!) But just as important to me, I also like the fact that I can continue to enjoy my investment in the Laridian books that I have purchased over the years.
I am glad to see that Laridian takes very seriously their commitment in providing solid and enjoyable products. Differentiation is obviously a key way to gain customers and stand out in the market, and I hope that this paging vs scrolling issue doesn’t get in the way. Thanks for providing such a great product in PocketBible!
Jim,
No, it’s not the case that we just want to “differentiate PocketBible from other Bible apps”. If you’ve read this article, past blog posts, and other discussions, you have read exactly why we paginate. I won’t repeat those reasons here since they’re clearly enumerated above.
In particular, I’ve never seen BibleScope nor AcroBible. If your description is accurate, though, I would argue that they “page”, not scroll. They page by chapter and scroll within a chapter. Given the choices (continuous scrolling through the Bible, paging like PocketBible, or scrolling within a chapter) I would argue that scrolling within a chapter and paging from chapter to chapter is the worst option and is the one I would never do. (Actually, we have done it in the past; won’t do it again.)
One of the reasons we don’t like it is that it doesn’t translate well to reference books. There are no short “chapter” divisions in commentaries, dictionaries, devotionals, and other reference books.
No, our reasons for paging aren’t motivated by the desire to be different. In fact, there is a certain amount of “desire to be the same” that motivated the decision. But again, we’ve already said that above.
I would like to personally thank you for the explaination you gave on this topic. The PocketBible was the first electronic Bible software package I purchased a decade ago. I have gone through more WM devices than I can shake a stick at, but in the end, yours is the tool I predominately use. Give it an original language OT and NT, and it would be the only. With that being said, I appreciate your taking the time to give the ‘why’ behind the ‘how’. In the end, scrolling or paging is just the ‘how’ we get used to using. Being creatures of habit, we like our old ways and we sometimes miss the fact that it is what we are reading that is important. I have used other Bible software packages and readers and as you have noted, paging seems to be the route being taken. Thanks for your thoughtful design, your patience with those who see things differently, and above all, your work to make the Word of God more accessable for all of us.
A loyal Laridian user,
Michael Krogstad
Craig – thanks for the response (I think!).
I hope you did get to spend some time with the kids…
I am STOKED to hear that the tap zones may soon be configurable
You state I haven’t given examples of scrolling text – do you REALLY want me to start a huge list? Let’s see every app ready installed on a new iPhone, every menu (even in your PB program!) I have ever seen on iPhone apps, Olivetree Bible (and a few other Bible apps but don’t remember the names as haven’t used them for a while) Where should I start with the 100+ apps I have installed, not of which use side to side pages for long text. If you want a list I’ll get one.
You quote 3-1 in favour of pagination. Are these people who have
just bought the iPhone? use it for 1 hour a day? Mainly use it for PB & little else? Just moved from windows mobile?
And even if you can see a HUGE favor of pagination – let’s sort out the direction! up & down or left to right? You have yet again taken ‘pagination’ as meaning left to right.
Adam,
Obviously there are things that scroll on the iPhone. However, if you read the article I wrote what you’ll find is that the vast majority are scrolling through a relatively small amount of material. In every case it’s at least readily measurable. You mentioned our menus as an example. Those are a case in point. The iPhone asks my code “how many items in this list?” and I tell it. Then it says “how tall is each one?” and I tell it. Just like I said in my article.
I’m not going to repeat what I already wrote because you can easily read it. Suffice to say a) there’s a difference between a scrolling menu with a small, finite number of fixed-height items and a 5MB Bible rendered in any font on the device in sizes from 8 to 72 points, and b) we don’t know/care what/how another Bible software company solved the same problem. If you want the details of those arguments, read the article above.
Once we decided pagination was the route we were going, then left-to-right motion for pages was a no-brainer. You see the first page of the Welcome book, learn that you need to tap on the right side, see the new page come from the right, and go, “Oh, it’s like a book.” Within seconds you completely get the metaphor.
If, on the other hand, text moved from bottom to top, you’d go, “Oh, it scrolls a page at a time. I wonder if I can scroll by dragging or flicking. Hmm. No.” You’d wonder if the program was broken or if you just didn’t know how to use it.
I’m sure, as you imply, that you’re the most experience iPhone user posting here on our blog. That’s probably why nobody else sees things the way you do. They just haven’t downloaded as many apps, haven’t spent as much time on the device, and haven’t thought about it as deeply as you have. Maybe when the rest of us catch up to your level of experience with the platform we’ll see things differently. Until then, you’re going to have to flick from right to left to turn pages in PocketBible.
I definitely prefer page-turning over scrolling. That way there’s less focus on page manipulation. I was delighted — though not really surprised — when I first saw that this app would use page-turning. I am surprised that this became such an issue. Best wishes to all!
Glad to have PocketBible on the iPod Touch… been with you guys since my Handspring Visor days. All honesty, didn’t even consider other applications for the iPod Touch for my Bible – weren’t happy with other options on the Palm or Windows Mobile platforms so decided just to wait. I don’t use it as much as Adam — I have other things to do with my day. Just glad to have performance and speed be a priority without sacrificing usability (I can’t be convinced that swiping left/right vs up/down is a sacrifice…). I have my preferences, but they’re irrelevant. I’ve done some coding/programming and at some point you have to move on when you don’t get the solution you as a programmer are happy with. Amazed you spent the time you did, thanks for the dedication. Looking forward to other future updates, books, and apps.
All in all (recognizing that key features are still coming) I find this the most usable version of your software on a handheld platform. Good job.
I’m an iPhone and Java developer (web and mobile) and understand the difficulties involved in this kind of apparently ‘simple’ feature.
Here’s a thought – is it possible to provide scrolling as an option?
Now before you dismiss that out of hand, let me suggest what this option entails.
By default, the program would behave exactly as it is now with all it’s cool features like displaying the blue stars for notes.
By setting it to scrolling mode all those extra features would be turned off. This may help with the length calculations. You can’t go to the next chapter, next book, tap to add notes, it doesn’t display the blue stars, etc. All you can do is use the Go menu button to go to a specific place in the book. It’s purely for reading.
And now here’s what I’d really like – autoscrolling. To see this in action download The Graduate for free which uses the iFlow Reader from here : http://appshopper.com/books/the-graduate-by-charles-webb
You tap the screen and the book starts scrolling up the page. You can tilt the phone to vary the scrolling speed. It resulted in the fastest I think I’ve ever read a book.
I would *love* this. But anyway, thanks for a great product as it is!
Neville,
Scrolling as an option is no easier than scrolling as the only UI. Go back and read the article again.
Autoscrolling is in our Windows Mobile app. If you see a feature in PocketBible for Windows Mobile, it’s on the list for implementation in PocketBible for iPhone.
Ah – cool. I can do without the finger scrolling – it’s really the autoscrolling I want! Nice to hear it’s coming.
There are “introduction and welcome documents”? I think I’ll have to go back and read them.
That being said, thanks for putting out a great product that allows us to carry the Word of God with us and read it, refer to it, meditate on it any time that we want or need (except maybe when driving…)
t
Craig,
I know this comment comes waaaaaaay late into the discussion, but I got my first iPhone not long ago, and was extremely happy to find PB available and all my purchased texts readily downloadable. Wonderful resource.
In a comment above from about Nov 2009, you said that configurable tap/swipe zones would be coming. That alone would fix my problem: I *never* want to swipe to change a book, but I *always* want to swipe top/bottom to change pages. Can I encourage you to get configurable tap/swipe zones back on the to-do list, if it’s not already actively in work?
If true swipe scrolling cannot be done, my personal setup would be that both left/right *and* up/down swipes would change by a page at a time. If you numbered the zones like this:
123
456
789
I would make 1234 go previous page, and 6789 go next page, with 5 still the menu/show-zones button. So if you *do* make the zones configurable, please don’t only allow each command to appear only once.
I migrated from a Palm version of PB, and I liked the extra steps to change Bibles – it never happened accidentally. That’s perhaps my next biggest frustration. I suppose I could close the secondary translations, but I really like having them quickly available – just not THAT quickly.
So having the option to remove that action from the zones would eliminate that frustration too.
Also, as a fellow programmer that also deals with displaying and projecting from Bible texts (projection/song-database software for churches), I fully understand the issues you describe above – a *great* explanation. I offer this additional thought, fully aware that you may well have tried it already: Since I don’t often want to scroll past the end of a chapter, perhaps the swipe option could at least scroll within a chapter. That shouldn’t be too computationally intensive to pre-render (except for maybe Psalms 119!). That would allow the iPhone motif within any one chapter, while still preserving the other benefits of zone-based movement.
Thanks again, and I hope to see a response even though it’s been a while since this thread was pinged.
Brandon,
The interest in changing the way PocketBible scrolls has really dropped off. I think people realize that PocketBible works like all the other ebook readers out there and that its touch-zone interface is actually quite powerful. It’s still on the list to look into, but we haven’t been motivated to make any changes.
Scrolling through chapters is awkward but OK for Bibles. It doesn’t make much sense for other reference books since they aren’t divided into “chapters”. As a result this is a solution we try to avoid (though our Android app currently works that way).
I believe the PocketBible for Android has scrolling of Bible pages. Does this signify a change of stance on this issue for iPad, or is it easier on Android to do this? Personally, I’d like an option to turn on scrolling on the PocketBible for iPad, even if it’s only the appearance of scrolling.
David,
There’s a trade-off. PocketBible for iOS uses our own HTML rendering code to lay out pages. The benefit is that text selection, tap-and-hold, and other gestures and behaviors are easier to implement because it’s all our code. The down-side is that we weren’t able to get continuous scrolling to perform at an acceptable level.
PocketBible for Android uses the built-in HTML viewer for laying out pages. The benefit is that it has some powerful scripting capabilities that make scrolling possible. The down-side is that it’s very difficult to do text selection and gesture recognition. We’re spending a lot of time just figuring out how to let you select verses to bookmark or highlight.
We could retrofit PocketBible for iOS with the Android approach but a) this would involve throwing away a lot of low-level code and having to reimplement many, many features, and b) I’m not convinced there would be sufficient increased sales of books or advanced features to offset the cost. This having been said, that option is not off the table. At the same time, we have our hands full with many other changes right now.