Sometimes the things we think are obvious to the outside world aren’t.
In our last update, we explained in detail a problem we had encountered in the way that we encode Bibles for use in PocketBible. The TL;DR version is that we found it necessary to update every version of PocketBible, plus update the BookBuilder app, in order to accommodate necessary changes to the way we deliver Bibles.
As you know, PocketBible runs on four platforms: iOS, macOS, Android, and Windows. One of our points of pride is that PocketBible is a native app on each of those platforms. That is, we didn’t use a special tool that might allow us to create one app and run it on all platforms — we created separate apps for each. So when something like this comes up, we have to update PocketBible on all 4 platforms, and in this case, we also had to update our BookBuilder app.
We have a very small team of developers. We don’t have people assigned full time to each platform. So to work on one we pretty much have to stop work on others. That has meant that while we’ve been focusing on Windows, we haven’t been able to do much/anything on other platforms. It also means that if we need to work on iOS, macOS, or Android, we aren’t able to do much on Windows.
We kind of thought you guys all understood that, so we’ve been keeping you updated on our progress on the other platforms with the understanding that we would get back to Windows when these were done. Turns out that wasn’t clear. Hopefully now it is. Here’s where we stand on each of the other platforms with respect to this Bible format update.
BookBuilder and PocketBible for macOS
Because BookBuilder needed to be updated (of course) due to the Bible encoding changes, and because BookBuilder and PocketBible for macOS share so much code, we tackled both of these together. We did all the necessary changes to BookBuilder, then tested the output in PocketBible on the Mac.
While we were in the code, we did some necessary bug fixes and a few enhancements. We released PocketBible 1.4.2 on June 7, 2023 and it’s been pretty stable.
We did not release a new version of BookBuilder to the public because it’s possible we’ll discover problems related to the new format while working on all the PocketBible releases, and we’ll want to go back and make changes.
PocketBible for iOS
Version 4.16.0 went to a small group of beta testers about a month ago. Problems have been minimal and I anticipate we’ll approve it for the App Store soon. It incorporates the new Bible encoding changes and has a small number of improvements and quite a few little bug fixes.
PocketBible for Android
Android has been a challenge for a variety of reasons. Google changed the rules on us and required that we rebuild the app with the latest version of their tools for basically no reason. The app was working fine, but after telling us we had until August to upload a new version to Google Play, they decided to invalidate the app in May. This fell right in the middle of what we were working on for the other platforms. We opted to continue on our original plan of updating the Android app by the end of August. In the meantime, Android users were given instructions to side-load the app from our website and that worked fine.
PocketBible for Android has not been updated since 2018 and the changes required to get it compatible with the latest OS have been challenging. We released a build with minimal new features on August 29th and updates to fix some bugs on September 2 and 7. We anticipate at least one more small release to fix some additional issues; probably two more.
Once we get Android up to speed with Google’s new requirements, we’ll need some time to do the Bible encoding changes. This will involve porting a lot of code from the macOS/iOS apps and making sure it works. The Android app handles Bibles slightly differently from the other apps, so it’s not just a line-for-line translation from one language to the other, but rather it’s a concept-by-concept implementation using methods consistent with the way Android does things.
I’d like to tell you how long I think that’s going to take but I know I’ll just be wrong. Shouldn’t be too long, though.
PocketBible for Windows
Remember PocketBible for Windows? This is an article about PocketBible for Windows.
Once we get back to the Windows app I want to do a couple of things. First, I obviously need to port the Bible encoding changes from macOS/iOS into Windows. The JavaScript code in the Windows version follows the way the C++ code in macOS/iOS works pretty closely, so this should be easier than doing it in Android and Java. Second, while we’ve been working on getting the program finished, new versions of both Electron and VueJS have been released. We should refactor the app to use the new code so we’re not starting out already in need of an update.
We’re actually fairly close to having at least the standard features of the Windows app finished once we’re able to get back to it. There are some Advanced Feature Set features that haven’t been touched yet (Autostudy comes to mind).
Moving Forward with the “Native Apps on All Platforms” Plan in 2024
I want to take advantage of the fact that we’ve had to do recent re-releases of PocketBible on every platform and make it a goal to do some kind of small update to PocketBible on each platform every year. It’s easier to keep up with frequent, small changes than to have to absorb a massive number of changes to how to build and release apps when you do it every 4-5 years.
So that’s the status of PocketBible for Windows, told in terms of everything else that’s going on here. Anytime you see a blog article about any of the other platforms, count it as progress on the Windows app. 🙂
Photo by Arif Riyanto on Unsplash
In my opinion, less is more with software.
A feature that is logical and works well is better than a few features that crash or are unintuitive.
I appreciate the update. I knew about the native code for the other platforms (because I’m one of those few readers here 🙂 ). I know writing something like this from the ground up is much easier said than done and not simply a copy/paste form of development.
I do look forward to the eventual Windows release as that’s my main platform, but I appreciate the updates to the others along the way.
It’s interesting/frustrating for us to know that Laridian is a mobile software company that has desktop apps as a side-hustle, while we have some significant number of users who view us as a traditional Bible software company (i.e. Windows) that also does mobile. We see ourselves as moderately good at what we do, while knowing there is that segment of our users that see us as miserably bad at it. Either of us can be shown to be right, depending on what you think we are. 🙂
“I do look forward to the eventual Windows release as that’s my main platform”
AMEN!
“One of our points of pride is that PocketBible is a native app on each of those platforms” While nice… this is holding everything back. Time to go unified… other Bible platforms are way out ahead. Also, a unified app means CONSISTENCY across all platforms. Not everyone is bought into the Apple ecosystem, not all on Windows not all Android. I use Windows, now MacOS, Android, and iOS. It would be nice to have it all consistent for the user. Perhaps your Electron development in Windows could lead to much easier to maintain MacOS, iOS and Android apps and a unified interface for your users.
I disagree on three counts. First, you have to think of the cross-platform app as a version of PocketBible for yet another platform. Consider that we’ve been working on the Windows app for 3 years now and that will give you an idea of how long it would take to write the cross-platform app itself. Second, there’s not a cross-platform environment that seamlessly targets iOS, Android, macOS, and Windows, especially not one that does so without requiring platform-specific knowledge and time spent tweaking for each platform. So comparing it to developing for a single platform is not really true. It’s more like developing for a single platform plus adding at least 1/4 of that time to add the per-platform tweaks per target platform. Third, there’s not a cross-platform environment that provides fully native experiences on each target.
I don’t believe it’s realistic to think about a unified user interface for mobile vs. desktop. I have so much more screen real estate on the desktop to manage a much larger library, that I would hate to limit my options on the desktop by designing a user interface that also works on the smallest iPhone. I have more choices of user interface elements on the desktop, where I can assume the user has a finer-grained selection instrument, like a mouse, than on a mobile device where I have to think about how fat my user’s pudgy fingers are.
I should also say that there is more shared across platforms than meets the eye. For example, our iOS, macOS, and Windows Desktop apps all share the core C++ code that we’ve developed over a period of 25 years. When moving to a platform that supports C++, it’s relatively trivial to get to where we can open books and read their contents. Most of our time is spent on the user interface, which tends to be platform-specific by its nature. We ported the shared C++ code to Java for Android with the thought that, at the time, Java was a big deal and we were going to see more platforms supporting Java. But then everyone took off in their own direction. Microsoft had C#, Apple developed Swift, and Google moved toward Kotlin. It’s in the best interest of each of the platforms to make it hard to develop cross-platform apps, and they’re doing their best to keep it that way.
Every company that has developed a cross-platform Bible software solution has produced substandard solutions on every platform. We may have platforms on which we have better and worse solutions, but we haven’t made them all universally worse by making them all equally compromised.
Interesting discussion. Not changing our direction at this point, but it’s interesting to talk about.
Fascinating post. I’ve not been following the development process here for a while. Looking forward to trying the new version. I use PocketBible every day (mostly Android, but quite a lot of Windows too.) I’ve been running the old beta version of the UWA PocketBible (3.0.22). I imagine it will stop working or be pulled from the Store sometime. Works really well though!
I’m not sure Electron can be called ‘Native’
Electron-based applications are often categorized as “hybrid” apps. These applications are built using web technologies like HTML, CSS, and JavaScript but are packaged in a way that allows them to run as standalone desktop applications. Electron provides a Chromium-based web browser for the front-end and Node.js for the back-end, all wrapped in a native container.
While Electron apps can’t fully be considered “native” in the traditional sense, they do offer some “native-like” features. For example, they can be distributed through traditional application channels like .exe or .dmg files, they can access the file system, and they can even use some device-specific features. However, they don’t offer the full performance optimization and hardware access that a truly native app would, because of the interpretive layers of node.js and Chromium that lie between our code and the operating system.
So, while an Electron app doesn’t quite fit the mold of a “native” application, it does blur the lines a bit and offers a middle ground between Web and native apps. It could be argued that we’re using it in the way we might use a set of native development tools, since we’re targeting only one platform. But the fact that we’re developing and testing on a different platform belies that argument or at least makes it suspicious. 🙂
Is it time for an update? It’s been a little while. (Like you needed something else to do in December😄)
I’ll post something after the first of the year.
Dear Craig
I started off with PocketBible for Windows Mobile on a HTC phone. Today I use it on Android (S23 Ultra) and Windows (11). The software has been my constant companion for some twenty plus years – and my library, highlights, and notes have followed me throughout. I’ve explored books that I would never have found let alone bought in a bookstore and moved from simply bible reading to life-enhancing bible study.
Your engineering approach means PocketBible has long been a tool ready-to-hand to me. I mean this in the Heideggerian sense – that is, that I use it without theorizing. In this sense PocketBible becomes present-at-hand (just lying there) only if/when it breaks, or something goes wrong. If you’re interested in exploring the distinction take a look at Understanding Computers and Cognition: A New Foundation for Design by Terry Winograd & Fernando Flores, 1987 ISBN 978-0201112979)
Ensuring PocketBible has remained ready-to-hand rather than just present-at-hand has been a significant achievement in engineering terms by you and your team. It has been a true blessing to me, and I am certain to many others.
Shifting operating-system fashions represent stormy waters for cross-platform developers with an installed user-base. In my opinion you’ve been able to walk on water.
With thanks for your constancy over many years, and for your diligence in adapting PocketBible to the future,
Stephen
I have been using VS code editor based on electron, it shows that an app based on it can be visually pleasing, easy of use, and surprisingly fast. So I am looking forward to the possibility of this new app, hopefully in 2024