December 9, 2024 — We were informed this morning by Google that they’ve removed PocketBible from the Play store, claiming we haven’t verified our identity. Never mind that we’ve had products in the Play Store for over a decade.
They’ve been asking us to jump through some verification hoops every couple of weeks for the last three or four months. Every time they ask, we jump through their hoop. Now they claim that there was no hoop and even if there were, we didn’t jump. So they’ve removed the app from the Play Store.
November 9 Update: PocketBible 4.18.2 was approved on November 9. Additional bug fixes noted below. PocketBible 4.18.1 was approved on October 31. Fixes a couple bugs in the earlier 4.18.0 release.
Version 4.18.0 was approved for distribution on the App Store on October 28.
The main motivation for this update was to fix several little problems that had shown up in PocketBible as the result of recent iOS updates.
While we were in the code, we took a look at the bug list and squashed a few of the bigger ones. And while we were doing that, we moved some code back into the iOS/macOS codebase from the new Windows app in order to gain functionality. This turned out to mostly affect the Advanced Feature Set features — Autostudy in particular.
Here’s an annotated list of fixes in version 4.18.0-4.18.02
Autostudy
Most of the work in this version turned out to be related to the Autostudy feature.
Letters with accent marks could break word and verse Autostudies. This was a fascinating bug to fix, only because it turned out to be a minor problem with code that has been in our apps for Pocket PC, Palm OS, Windows, macOS, and iOS since 2004. It had just never been invoked in exactly the right way to expose this bug. The fix was simple once we found it.
Changes to the verse, word, or date being studied weren’t always recognized. If you changed the verse without closing the Autostudy window and starting again, PocketBIble might not recognize the change. Another easy fix.
While the link on the word “Note” at the beginning of verses with notes was not there, the word “Note” was there. One of the advantages of being me (Craig) is that when you’re doing your own Bible reading and spot something annoying, you can fix it. So I did.
Word Autostudies now support phrases, not just words. This was added in the Windows code then ported back to the macOS/iOS codebase where it came from.
Better algorithm for discovering sources of cross-references. We took some time during the Windows project to come up with a better algorithm for this. We look for commentaries that cover a high percentage of the verses in the Bible, that have a large number of links per entry, and in which links are a high percentage of the total text in the book.
Bible verses in date Autostudies can now appear in devotional order instead of date order. As you know, I’m a fan of doing my daily reading in chronological order. I tend to use resources like the One Year Chronological Bible or my own 7-Minute Bible for Bible reading. When using the OYCB, Autostudy would put the verses in biblical order instead of leaving them in chronological order. This defeats the purpose. This feature fixes that.
Navigation buttons at the top of Autostudy reports. This feature was borrowed from the work we did on Autostudies for the new Windows app. It puts a row of navigation buttons at the top of your Autostudy reports to make it easier to navigate those long files.
AI Insights in Autostudy
This one deserves its own section. We’ve integrated ChatGPT into PocketBible to generate custom commentary, original language insights, devotional thoughts, and other useful information. This feature requires an active Advanced Feature Set subscription. It is not available to users still relying on the old “permanent subscription to the legacy AFS features” from version 3 of PocketBible.
Before you dismiss this innovative and useful feature, you need to give it a try.
As you may know, ChatGPT is a large language model that is able to give in-depth, human-sounding answers to natural-language questions. The key to using ChatGPT effectively is to craft the appropriate query (or “prompt”). We’ve spent a lot of time over the last year and a half designing prompts and instructions that cause it to give responses that are Bible-based and Bible-first. It avoids dogma and denominational bias and favors what it clearly reads in the Bible. It uses biblical terminology where political correctness would prefer non-biblical alternative language.
ChatGPT is trained on virtually everything that has ever been written about everything. As a result, it brings to your study deep knowledge of biblical languages, of biblical and secular history, and of the geography, politics, and culture of the lands and peoples of the Bible. We call the articles it writes for PocketBible, “AI Insights”.
AI Insights in Verse Autostudies
Bible Commentary — Scholarly, accurate Bible commentary that is written at the level of an average Bible reader. Includes historical/cultural context, information about the author and original audience of the passage, the role of the verse in the surrounding passage, and practical application. The article will cite its sources if it refers to other Bible passages.
Cross-References — A list of cross-references for the topics in the verse or passage, organized alphabetically by topic.
Theological and Doctrinal History — Discusses varying interpretations of the passage or concepts covered by the passage and how they have been debated throughout church history.
Hebrew and Greek Insights — Lists key Greek or Hebrew words used in the passage, along with their meanings, usage in other contexts, and nuances that might affect the meaning of the passage. To make these articles more accessible, words are transliterated rather than spelled out in the original languages.
Sermon or Lesson Title with Outline — Produces an alliterated outline (or a close approximation thereof) and a suggested sermon title for the passage.
AI Insights in Word Autostudies
Bible Dictionary — An article about the word or phrase being studied, including a definition of the word(s), key Bible verses that use the word(s), and insights from the Greek and Hebrew words that are often translated using this word.
AI Insights in Autostudy Today
Inspriational Thoughts — An inspirational reflection on today’s Bible passage(s). The attributes, promises, and commands of God are emphasized. The goal is enriched worship and prayer, and a deeper personal connection with God.
Commentary — Basic Bible commentary on the passage(s), including background information, historical context, and explanations of key themes. Important Hebrew or Greek words are defined and their implications discussed.
Applying Today’s Verses — The focus is on the practical application of today’s passage(s). How do the teachings and principles in the passage(s) guide the reader’s behavior, decisions, and relationships as they live out the commands and promises of God in practical ways?
Today in Christian History — This article is different in that it is not about the Bible passage you’re reading but is about what happened on this date throughout Christian history. The emphasis is on known dates, not dates when events are traditionally celebrated, and on people and events, rather than on holidays and commemorations.
Other Features and Fixes
Some apps had trouble pasting text from PocketBible. PocketBible has been putting formatted text on the clipboard (actually called the “pasteboard” in macOS and iOS) since the first day it was supported. (You probably have forgotten that the first two major releases of iOS did not even have a clipboard. The clipboard wasn’t introduced until iOS 3.)
When apps put text on the clipboard, they have to identify the format of the text so that the receiving app knows what it’s looking at. Somewhere around iOS 17 or 18, certain apps stopped recognizing the original identifiers for some of the rich-text clipboard formats, and as a result would misinterpret text placed there by PocketBible. We’ve resolved this in a way that maintains compatibility with the past while adopting the newer identifiers.
Punctuation in selected or entered text could confuse search, look-up, and Autostudy features. We do a better job of filtering punctuation than we used to. Note that 4.18.0 was too aggressive about removing punctuation and introduced a problem that has been fixed in 4.18.2.
AFS subscription management on the menu was linking to the wrong URL. Apple changed the URL for subscription management and we didn’t notice it until recently.
The space after a trailing apostrophe was missing in certain Bibles. Instead of “Jesus’ disciples”, you’d see “Jesus’disciples”. The fix for this in 4.18.0 and 4.18.1 introduced other problems. 4.18.2 fixes it.
Searching for non-existent words at the beginning of phrases could fool PocketBible. Searching for “grafted in” in a Bible that does not contain the word “grafted” would give the results for “in” instead of saying that the phrase doesn’t occur.
Wildcard searches were broken by changes in 4.18.0. Fixed in 4.18.2.
Wildcard searches were inadvertently omitted from the User’s Guide. The User’s Guide was severely lacking in detail when it came to the search features. We updated the User’s Guide for 4.18.2, adding information about certain types of search patterns that have been in our apps for 10 years but have just never been documented.
The “toggle play/pause” button on certain headphones didn’t work with the synthesized speech feature. This turned out to be a complete oversight on our part. Sorry about that.
Text would scroll some random number of pages up or down when the height of the window changed. This was usually the result of showing or hiding the toolbox on the iPad version of PocketBible. Apple changed the order in which certain things were done when resizing the window, which caused our attempt to keep the text at the same location to be defeated.
Link previews in notes might not be able to be dismissed, or, when dismissed, would close the note viewer. Fixed in 4.18.2.
There is a small number of other fixes that aren’t worth mentioning.
Once again, we’re overdue for an update. I know it seems like this is taking a long time, but we really are getting closer to at least a beta release. You can watch the video if you want to see the program in action. It’s a long one this time.
Almost everything in this update is an Advanced Feature Set feature. As a reminder, if you have an AFS subscription (or if you own the “legacy AFS” before it became a subscription) for the Windows Store version of PocketBible, it will gain you access to the equivalent features in this new version. Since the features we’re going to talk about today are not present in the current Windows Store version, your AFS subscription for that version will not get you access to these features. You’ll need a new subscription to the new version for these features.
User Note Indicators
One thing that is not an AFS feature is the new indicator for user-created notes in the text. You’re used to seeing the word “Note” linked to your notes at the beginning of a verse. PocketBible 3 for Windows will let you select either a duotone solid or outline note icon to use in place of the word “Note”.
Position of Layout Tabs
In previous screenshots and progress report videos, you’ve seen that the row of layout tabs extended all the way across the screen, including the area above the study panel. We’ve modified the layout so that the tabs appear over the text panes only.
Navigator
The Navigator is a featured ported from the macOS version of PocketBible. It allows you to see a list of all the places in your entire library (or a subset of your library that you define) where the current verse is mentioned. The Navigator can be set up to display its results based on which of your books contain the most references to the current verse, or it can be configured to always show your books in an order you choose.
When you select a link from the Navigator pane, you’re taken to the section of the book where the active verse is mentioned. You can configure the Navigator to always be active or you can disable the continuous updates and manually refresh its content when you need it.
Library Search
As you may have guessed, the Library Search study panel is where you perform searches across your entire library — or the portions of your library that you select. Library Search does not perform the full range of searches (such as “sounds like” and “root word”) that the single-book search does. Instead it looks only for exact matches, so that it can search your entire library quickly. To perform a deeper search of any single book, you can select the magnifying glass icon next to that book.
Searching your entire library can take time, so we provide a way for you to select only those books that you are most interested in searching. You can also control the order in which results are displayed — either by putting the books with the most search hits on top, or by following the order that you choose.
Verse Autostudy
If you’ve used PocketBible for Android, iOS, or macOS, you’re familiar with PocketBible’s Autostudy feature. It lets you easily collect material from your library that is related to a given verse (or passage), word (or phrase), or date. Autostudy will be implemented in PocketBible 3 for the first time on the Windows platform.
Verse Autostudy works on a single verse (“John 3:16”) or on a contiguous range of verses (“John 3:16-18”). You select the books that you want included in your results, and the order in which the books should appear.
For the Windows version we’ve improved the method PocketBible uses to determine if a given commentary is a “book of cross-references”. Previously, only the Treasury of Scripture Knowledge qualified. PocketBible 3 for Windows can look at a book at runtime and decide if its cross-reference density is high enough to make it useful for this function.
We’re introducing AI Insights as an experimental feature in this version of PocketBible. PocketBible can perform custom queries of ChatGPT to create Bible commentary for the passage, generate a list of topical cross-references related to the passage, provide theological and doctrinal history as it relates to the passage, give you insight into key Greek or Hebrew words used, and even generate a sermon title and alliterated outline. (We’ve found the alliteration to be hit-and-miss, but it does reasonably well on creating an organized outline.)
Any time that a Bible reference appears in your Autostudy reports, it is “hot” — click on it and PocketBible will go to the selected verse. This applies to your AI Insights as well — that is, the links to Bible verses are added to ChatGPT output so that references in its output can link to PocketBible. In addition to Bible verses, any links in the books that are in your Autostudy output are active as well.
This linking feature is also present in Word and Today Autostudy results.
Similar to Verse Autostudy, you can ask PocketBible to collect information from your library on a given word or (new in the Windows version) phrase. For the Windows version, we’re adding the AI Insights feature. PocketBible will use ChatGPT to generate a Bible dictionary entry for the word or phrase you give it.
The purpose of Autostudy Today is to collect all the Bible verses you need to read on a given day. Assuming you’re doing one of our read-through-the-Bible plans, this can be very convenient.
AI Insights is also coming to Autostudy Today. You’ll be able to generate three types of devotional readings: An inspirational reading that focuses on the praise, prayer, and the attributes of God as revealed in the passage you’re reading; a commentary on the passage, providing background and interpretive information on the passage; or an applicational article, encouraging you to apply and practice what you’ve learned. You can also get an article entitled “Today in Christian History” that gives you information about key events that took place on today’s date in the past.
A couple of interesting synergies happened as a result of implementing Autostudy. First, the dialog that lets you choose the books you want included in the Autostudy came in very handy for choosing the books you want to include in the Navigator and Library Search features.
Second, we needed a way to display Autostudy output. After some experimentation, we came up with the idea of using an external window with its own controls to allow you to save, copy, and print your Autostudy reports. It wasn’t much of an extension to this feature to make it so that you can re-open a saved report. And if you can re-open a saved report, you can open any HTML document in one of these windows. And if you can open any HTML document, you can open HTML documents that you create yourself, and any links you put in those documents can link to PocketBible.
Once we had this capability, it solved another problem. Many of you have asked for a way to copy search results to the clipboard. We used external windows to not only give you the ability to copy search results to the clipboard, but to allow you to print or save them. And since links in external windows are active, when you output your search results to an external window, it behaves a lot like the Search pane in the Study Panel — select a search result to cause PocketBible to show you the verse in context.
And then, once we had the ability to output search results, it wasn’t much of an extension to also output lists of bookmarks, highlights, and notes, and also to output your Library Search and Navigator results.
Any external windows you have open when you exit PocketBible will be re-opened when you launch it later.
What’s Next
We believe the app is “feature complete”. There’s nothing major that needs to be added before it will be ready to ship. There are a couple small features that are “on the bubble” and either could or couldn’t be added before we release at least a beta version. But for the most part, it’s safe to say that there are no major features left to be added.
There are a number of bugs on our list that need to be found and squashed. None of these are large, but sometimes you can’t tell how hard it’s going to be until you get into the code and figure out what’s going on.
We are very sensitive to maintaining the integrity of your user-created notes, highlights, bookmarks, and devotional reading progress. We’ve been testing this code as we’ve implemented it, but I want to take a step back and re-run the full test suite on this code before we trust it with your data.
We’re not announcing any ship date at this point, of course, but we anticipate that our next update (whenever that might be) will be to announce a beta version. No promises. Just letting you know what we’re thinking at this point.
If you want to think of this as a PocketBible 3 for Windows progress update, you wouldn’t be entirely wrong. You will surely be disappointed, but you won’t technically be wrong.
The Dingus
We’re experimenting with giving you access to AI-generated commentary and other tools in the Autostudy feature in PocketBible 3 using the ChatGPT API. You won’t have to have a ChatGPT account to use it; we’ll create the prompts and automatically submit them and get responses for you to include (if you’d like) in your Autostudy output.
ChatGPT uses Markdown in its responses. Markdown is an easy way to create formatted text with a plain text editor. PocketBible use HTML for this purpose, which is a very different and more difficult way to create formatted text. So we have to convert from Markdown to HTML to display ChatGPT results in PocketBible. This is not straightforward, as Markdown wasn’t “designed” so much as it was pieced together as needed.
When the nerds who power our tech economy were asked to come up with a “standard” for Markdown, they discovered that even its most formal definition was ambiguous. If someone asked, “What happens if you overlap bold and italic markers in the text?” the only way to find out was to try it and see what happened. In order to make it easy for users to experiment and deduce the rules, they produced what is known simply as “the CommonMark Dingus” — as in “that whatchamacallit on their website”. The Dingus lets you enter text using CommonMark syntax and it shows you how it will render and what HTML tags are required to get the same result.
The Laridian Dingus
After laughing about the CommonMark Dingus every time I used it, I realized the only way I was going to be able to interactively test my server-based Markdown to HTML converter was to write my own “dingus”. Turns out it’s actually not a bad idea. I see now why they created it.
The Gooberizer
While writing this, I (Craig) was reminded of some PocketBible code. Back around 2002, my programming partner, Jeff Wheeler, was working on the DailyReader app. At the time, daily devotional books and Bible reading plans were not a part of PocketBible, but rather, you needed a separate app called DailyReader.
Since DailyReader didn’t know how to read PocketBible books, and since Palm OS, the hot mobile operating system at the time, didn’t have a file system (!!!), we had to come up with a way to store the text of reading plans and devotionals in a way that would be compatible with a Palm OS database, would be quick and easy to decode, and wouldn’t be readable by humans.
Of the two of us, I was the guy who had experience with encryption. I had implemented a simple encryption algorithm that we were able to use on our website and in our apps when we needed something “secure enough” — not something you’d trust your credit card number to, but good enough to obscure other sensitive information that we don’t want you messing with. So Jeff came to me to figure out how to obfuscate his DailyReader data.
“I don’t need some kind of unbreakable encryption. I just want to goober up the text enough that it can’t be read by the average user,” he said. I picked up on Jeff’s goofy terminology and created the skeleton of code called “The Gooberizer“. I created a simple encryption algorithm with a symmetric key — as long as the producer of the encrypted file (his little program that created DailyReader books) and the consumer of it (the DailyReader app itself) use the same key, one can encrypt and the other can decrypt the data. In order to make it slightly more secure, the secret key is not something stored in the program, but rather is computed based on the data in the book. This made it harder for a nefarious (or curious) user to break the code and ungooberize the text for himself.
Jeff fleshed out the code from my design and DailyReader soon had fully gooberized text.
PocketBible and the Gooberizer
Three years later I was adding some code to PocketBible and needed a way to authenticate an LBK (Laridian Book) file. We had decided to release our BookBuilder app as a commercial product but didn’t want a rogue competitor to use it to reproduce our entire library and put us out of business. So we put information into the LBK file that tells us that the file was built by the consumer version of BookBuilder. We needed a way to verify that these imaginary rogue competitors (who were growing more vile and contemptible the more we thought about them) weren’t tampering with the info to convince PocketBible that their books came from Laridian.
Then I remembered the Gooberizer. I rejiggered the Gooberizer code so it could produce a one-way hash of any string you gave it. The idea is that BookBuilder would build a string based on critical values in the LBK file, then store the gooberized string in the LBK itself. When PocketBible opens the file, it builds its own copy of the critical-values string and produces its own gooberized representation of it. If the stored goober and the runtime goober match, you get to read the book.
But seriously…
It can be embarrassing when the terminology you use around the office to describe something makes its way into public. You casually refer to your experimental test page on the website as “that dingus” and the next thing you know it becomes the most important part of your project.
Fortunately, we don’t foresee any need to give the public access to the Gooberizer. So for now it’s our little inside joke. Until somebody decides to write a blog article about it.
I was happy to have the opportunity to talk about 35+ years of developing Bible software, starting at home, then at Parsons Technology, then at Laridian. Check out biblebuyingguide.com for reviews of Bibles and other materials related to reading and studying the Bible.
This isn’t so much a progress update as it is a quick demo of some of the user interface features of the upcoming PocketBible 3 for Windows.
Recently I got an email from a PocketBible user who didn’t like something about how the current Windows version of PocketBible worked. He was hoping it was not to late to ask for it to be fixed in the new version that we’re working on. I was able to reassure him that the new version won’t work anything like the version he was using. I wanted to send him a link to a video to demonstrate the feature, but while searching past updates it surprised me to find I hadn’t done one of these for a while.
So here’s a very fast tour through the app that touches a lot of different features and is meant mainly to reassure you that you’ll be able to resize the text (a flaw in both the current Windows Desktop and Windows Store versions of PocketBible) and that the toolbar will stay visible all the time (you PocketBible for Windows Store users will know what I’m talking about).
When traveling near the speed of light, one experiences both the dilation of time and the contraction of distance. An astronaut traveling to a distant star at near light speed experiences less time than his friends back on Earth. He arrives at his destination sooner than expected because he also experiences less distance to that destination — as he accelerates toward light speed, his destination appears to be disproportionately closer to him than it would appear if he were at rest.
Then an interesting thing happens as he gets closer and begins to slow down — his destination gets farther away. This is due to the reduction in the effect of length contraction as he slows towards being stationary with respect to the destination.
We see the same thing happen in the software world. As we approach the end of a software project and find ourselves implementing fewer new features and solving fewer bugs, the release date appears to move farther away. The effect of taking 4 weeks at the beginning of a project to solve a major problem is relatively minor in the grand scheme of things. But taking 4 weeks on a single task at the end of a project makes it feel like it is never going to be completed.
Reactivity
One of the major challenges we’ve faced in the last couple of months is related to Vue — the user interface framework we use. Vue is a “reactive” system. That is, if you want to display some text on the screen, you don’t write code that moves to a particular (x,y) location and outputs the text in a particular font, but rather you define an area of the screen that will display text in a certain font, then attach a particular variable in your code to that area of the screen. Now when you change that variable, the screen is updated with its new value. In other words, the user interface reacts directly to changes in your data.
In order to know when it needs to update the screen, Vue wraps its own code around these reactive variables. It is very good at doing its wrapping. If you’re not careful, it can “infect” certain pieces of data with its reactive wrapper. The result is not only inefficiency (since a bunch of unnecessary code is executed when you change the value of a variable) but potential confusion as Vue believes you’re changing data at a time when you shouldn’t be changing it. In reality, Vue shouldn’t be paying attention to it at all, and everything it reports is nonsense.
One common problem is changing the value of a reactive object or variable while Vue is getting its value in order to render the screen layout. This seems easy to avoid (why would you change something while getting its value?) but in reality, it happens often. For example, the table of contents of a book is a static piece of data. But we don’t keep it all in memory at the same time. So when you want to display the table of contents on the screen, we have to read it from the book. Doing so changes the value of the file pointer that tells us where we are while reading the file. In other words, reading static data (the table of contents) changes a value (file position) in the object in our code that represents the book. If Vue has wrapped this object with its reactivity code, it believes you are changing the data while it’s trying to read it.
The other way this can happen is when accessing some piece of data from a book that needs to be constructed the first time it is accessed but is static after that. Consider the field where you type the name of a book of the Bible that you want to go to. That field needs access to a list of all the book names and the abbreviations of those names that are in this Bible. That information isn’t stored directly in the book file — we have to iterate over the list of all the books of the Bible that are in this particular Bible and generate a supplemental list of all possible names and abbreviations. Consider, for example, 2 John. You might enter “2 John”, “2 Jn”, “2John”, “2J”, “2Jn”, “II John”, “Second John”, etc. We keep a list of all possibilities so we can auto-fill the field. So the act of getting the list of book names for the first time will cause the list of names to be stored in the book object for use if you need it later. Storing the list in the book object that has been infected with reactivity code makes Vue believe you’re changing data while it’s trying to read it.
There are certain significant data structures in PocketBible that are susceptible to this unnecessary infection by Vue’s reactivity code. For example, we keep a list of books that you own. Some are open, some are installed but not open, and some are back on the server. We know a little about the ones on the server; more about the ones that are installed; and a lot about the ones that are open. What we know about each book is stored in an “object” that is the representation of that book in the list.
For the most part, this large list of book objects is not directly displayed anywhere on the screen and Vue doesn’t need to know about it. Our code will reference it when getting Bible text or when showing you the table of contents of a reference book. But you’re rarely looking directly at data directly stored in this list. As a result, this list is immune to being infected by reactivity code, and we’re free to change the data it contains whenever we want.
But because this list is so central to almost everything PocketBible does, it isn’t difficult to accidentally expose it to Vue, then have the result of the reactivity infection show up in a completely different part of the app.
We’ve spent a lot of time in the last 3 months chasing down a major bug related to this reactivity infection phenomena. We’ve been seeing the symptoms for quite a while but hadn’t taken the time to look into it until recently. We think we have it solved but it’s the kind of thing that can pop back up at any time.
New Bible Format Implementation
We continued and perhaps finished work on integrating the new Bible format that we’ve been talking about for the last year or so. In addition to the basic functionality we added some enhancements that allow us to see the version numbers of this Bible data and identify where it came from so that future troubleshooting should be easier.
Link Preview
We began work on the link preview function, where hovering over a link causes the target of that link to be displayed in a pop-up window. For example, hovering over a Bible reference will cause that verse to be shown as long as your mouse is hovering over it. The user interface portion of this task (tracking your mouse and popping up a window) is basically complete; now we need to implement code to get the text that populates the window.
We’ll also be adding code to activate the link preview pop-up on long press for touch-screen devices.
Delete Books
We implemented the ability to delete books installed on your machine. This is trickier than you might think, since you have to make sure the book is not left open in one or more panes after it has been deleted.
Miscellaneous
We fixed a problem with devotional start dates and at the same time, found a problem that might be related to 2024 being a leap year. Should be easy to fix once we take the time to look for it.
We fixed a problem when trying to find an installed book when you only know its publisher ID and book ID. This is rarely used but could have caused a hard-to-find bug had we not caught it when we did.
When looking for a Bible to handle a link (or, in general, any book to handle any link) errors were always being reported to the user even though there are some cases where we want to know there was an error but don’t necessarily want to show it to the user.
On Friday, April 5, my wife and I took off from our home in Iowa and headed toward New England — the only area along the path of the April 8 total solar eclipse forecast to have clear skies. By Saturday, the weather was improving in central Indiana, so we turned back a bit and spent Saturday night in Indianapolis. Sunday morning’s forecast suggested Cape Girardeau, MO might be the place to be. I saw the 2017 eclipse from Makanda, IL, which is about 2 hours from Cape Girardeau, so we headed to that area to spend Sunday night — with the idea we might move quickly on Monday morning, in time to set up for the 12:40 PM “first contact” (C1) between the sun and the moon.
Monday morning things looked no better in southern Missouri than they were in southern Illinois, so we headed to Makanda to reprise my 2017 experience at the place where the two paths of totality (2017 and 2024) met.
With me was a new Seestar S50 Smart Telescope. The Seestar is just a sophisticated digital camera. You set it on its tripod, calibrate its internal compass, level it up, then tap “sun” in its app. It just rotates and looks up and finds the sun, then follows it across the sky until you tell it to stop.
We got some great footage with the telescope. I combined it with my iPhone footage to document our experience.
Meanwhile, At Laridian
If you’ve been paying attention, you’ve figured out over the last 5-6 years that we’ve settled in on a marketing schedule where we announce a new product or sale every Monday morning. The email goes out around 9:30 AM Central Time. This tends to make Mondays our best revenue day. On Thursday, the email goes out to anyone who hasn’t opened it yet, as a reminder that they’re not keeping up. 🙂
After getting back in the office, I looked at Monday’s orders and found an interesting pattern. We had an initial bump around 9:30 AM as expected, but then starting in the hour that the partial eclipse started in southwest Texas, sales fell to all but nothing. They didn’t come up until the hour after the total eclipse ended in northeastern Maine. For the rest of the day they were higher than usual as everyone recovered from staring at the sun.
In this graph I’ve normalized the sales numbers so that “peak sales” is at the same level for both a typical Monday and eclipse Monday. The point is not to reveal exact numbers but to show the dramatic effect of the eclipse. Sales are reported hourly, so the slant in the line that starts at 14:00 (2PM) doesn’t mean that we started to see sales as soon as totality started in the midwest, but rather that there were a lot more sales in the 3:00 hour than the 2:00 hour.
I suspect there might be more to see here, but I haven’t taken time to dig into it. For example, I wouldn’t expect to see as much of a difference in sales from western states as from eastern states, since the former were so far away from the path of totality.
I wouldn’t normally share information like this but it was so dramatic that it seemed like it might be interesting. And I don’t blame you for not buying anything during the eclipse — even those of us at Laridian were doing nothing but watching the eclipse along with you.
Thinking about PocketBible users’ group meetings in Iceland in 2026 and Sydney in 2028.
We just completed our annual survey of our PocketBible users and I thought I’d share a few results with you. This isn’t everything and it’s not even every important thing. But some of this is interesting and might help you understand who your fellow PocketBible users are, and in some cases, why we might make the choices we do when it comes to the products we create for PocketBible.
Demographics
The majority of you are male, and are 55 or older. To some peoples’ surprise, most of you are not preachers — though about half of you have some kind of teaching ministry.
This is consistent with what we’ve come to know about our PocketBible users. I believe that our age (yes, I’m in that “over 55” group, too) puts us in a generation that trusts the authority of the Bible and therefore wants to know more about it. We also believe there are people smarter than us who have things to say about the Bible from whom we can learn. Younger people tend to value the experience of God. They learn about God through their community experiences with their fellow believers. As a result they have less dependence on the kind of commentary and research tools at which PocketBible excels. Not all of them, of course; we continue to add new users of all ages to the PocketBible family.
Beliefs
Half of you chose the label “Bible-believing” to describe your Christian beliefs. One-third use the term “evangelical” and one-third “nondenominational”. About two thirds selected “Catholic”, “Orthodox”, or a specific Protestant denomination. These terms aren’t mutually exclusive so the totals add up to more than 100% with a lot of overlap.
It’s interesting to note how our ranking of denominations is different than the ranking of these denominations in the general population. Note that these are cherry-picked to match what we asked on our survey; there could be a number of smaller denominations missing.
Church/Denomination
Rank (In the US)
Rank (Among PocketBible users)
Catholic
1
8
Baptist
2
1
Methodist
3
4
Lutheran
4
6
Pentecostal
5
2
Presbyterian
6
3
Episcopal/Anglican
7
5
Seventh Day Adventist
8
7
Orthodox
9
9
Only denominations that got at least 10 responses on our survey are listed. 80% of you are in the US, so only members of these churches in the US were considered.
This is consistent with what we know from being in the Christian publishing business for over 30 years. People who purchase Bibles and Bible study materials tend to be on the more theologically “conservative” end of the spectrum and they tend to describe themselves as neither Catholic nor Protestant. That “Bible-believing” term sums up who they are. This has been true the entire time I’ve been in this business.
And it makes sense. These are the kind of people who are encouraged by the churches they attend to study the Bible for themselves and not to depend on a formal member of the clergy to answer their questions. Even the least leadership-oriented person in this group has a small but useful Bible library, which may or may not be entirely digital.
Bible Reading
90% of you spend time reading the Bible every day (or nearly every day). The majority of those are either using PocketBible’s devotional features or following an external plan but using PocketBible to read the Bible. Those who do read every day spend 17 minutes each day reading the Bible. This is consistent with the 16.5 minutes we got last year.
I find that encouraging. I believe it’s important for Christians to read and understand the Bible. It’s our most direct way of getting instruction from God.
Online Habits
Most of you are still using Google for searches even though it puts your privacy at risk. The next most popular choice is arguably the right one: Duck Duck Go.
A few of you, when asked what search engine you use, told us you use Edge, Firefox, or Safari. Please — these are browsers. A browser is how you access the Web. A search engine is a website you use to perform searches. Most browsers allow you to choose a default search engine. This allows you to type some search words into the address line in your browser and it will automatically invoke your chosen search engine to perform the search.
Use of PocketBible
Most of you use PocketBible every day and almost 90% use it more than just in church on Sunday.
Over 80% of you use PocketBible most of the time on either a phone or tablet. This is consistent with how we target our marketing of what we do — we are a mobile app developer and always have been. That less-than-20% who use it primarily on a desktop or laptop will argue with us about that and point out that Windows is the most popular operating system. Until we point out that Windows is the most popular desktop operating system. If you expand your scope to all computing devices, then Android OS is actually installed on more devices than Windows.
Satisfaction
94% of you are somewhat or very satisfied with PocketBible. You are most interested in the same kinds of resources that we are already producing — commentaries, dictionaries, Bibles, and atlases. You have some very specific recommendations in some cases, and we’ve made a note of those.
2% of you are dissatisfied with PocketBible, so we’re pouring over your criticisms and suggestions. We don’t respond to these of course, but we do read them. We don’t enjoy it, but we do it anyway.
This is just a quick overview of the portions of the survey that I thought might be of general interest. The complete report is 49 pages long, including your comments, suggestions, and complaints in 10-point font.
Thanks to those of you who participated! This is an important part of what we do to make PocketBible into a useful tool.
I recently purchased an Apple Vision Pro. I’ll eventually have some thoughts about this platform and its potential for Bible software, but right now I want to talk about that boring little brick you plug your iOS device into when you charge it.
I’ve owned an iPhone since the day it was introduced, an iPad since its launch date, too, and now a Vision Pro 1.0. Just like many of you, I have drawers and computer bags full of those little USB power supply bricks and a variety of the bigger ones that come with MacBooks. I figured out a long time ago that I can plug any device with a USB charger into any USB power supply even if it’s intended for a different device. So I charge my iPhone and Watch with my MacBook charger and have been known to plug my MacBook into an iPad charger just for grins.
When I got the Vision Pro, I saw someone on YouTube put a meter inline with the charging cable and note that it would draw up to 60 watts when connected to his MacBook power supply, even though it ships with a 30 W power supply.
I have just a little bit of experience with electronics, having learned Ohm’s Law for my ham radio license 50 years ago (!) and having built a number of transceivers and other electronic gizmos. I’ve been assuming that all these devices needed 5V at some number of amps — 1.5 A for iPhones and 2.1 A for iPads and many more amps for my MacBook. They are all interchangeable, so they must all use the same voltage, right? Maybe just limit the current?
Wrong.
Turns out these little power supply bricks are smart. They talk to your device and negotiate a voltage the device can use and the current limit the supply might have at that voltage. Between your device and the power supply, they work out the optimum arrangement for operating your device and charging the battery. Voltage ranges from about 5V to about 20V and current is adjusted so as not to exceed the limits of either the power supply or the device.
I guess they’ve been doing this since about 2012. Who knew? Not me.