PocketBible for Windows Progress Update #16

I told myself I’d write a progress update after the first of the year. Suddenly that’s where we’re at.

As you recall from updates 14 and 15, we had a bit of a crisis of our own creation happen toward the end of 2022 which required us to update both BookBuilder and PocketBible on every platform. We had to modify our Bible format and make sure all versions of PocketBible (with the exception of the old/current Windows versions) could read the new format.

We started with our BookBuilder and PocketBible apps for macOS, since these two share a lot of code and doing them at the same time gave us a platform on which to test our new Bible format. We held off on releasing BookBuilder in case we discovered anything we needed to fix as we rolled out the changes. We released the macOS version of PocketBible in May with updates following into June.

This allowed us to turn our attention to the Android version, which was problematic because of Google shenanigans. An initial version was released in September to address new Play Store requirements. We spent the next 6-8 weeks implementing the Bible changes and doing updates to fix various problems discovered after the release of the new version. This was our first update in 5 years for the Android app, so there were some issues.

That brought us to the Thanksgiving/Christmas season, which is our busiest time of year. There are two large tasks that I’m personally involved in because they impact code on the website — creating the 2024 editions of the Bronze, Silver, Gold, Platinum, and Emerald PocketBible Library collections, and implementing the end-of-year “name your price” sale. Because these tasks have to be done every year, some of the process is automated. But it still requires a bunch of my time.

Despite the distractions, progress was made on the Windows app during this time.

The app is very close to being feature-complete, at least for the standard (non-AFS) feature set. One of the next big tasks that, oddly enough, consists of a lot of unknowns is being able to build a Windows EXE suitable for distribution.

As I’ve explained before, we do all of our development and testing on macOS. We’ve done occasional debug builds for Windows, but we’ve never been able to generate a stand-alone EXE like we’ll have to do when we release the product. So even though we’re not quite there yet, I have someone looking into those issues.

This has taken us down two dark alleys. One was compatibility problems with the versions of the Electron and Vue frameworks we’re using in the app. In order to build an executable that works, I think we’re going to need to be running newer versions of those foundational tools. Electron isn’t much of an issue, but Vue has undergone breaking changes in its most recent major update. This requires that we make significant changes just to get our code to build with that version.

The second issue is code signing. Code signing is a process that is supposed to do a couple of things. First, it assures you that the software you download from our website really is from us and not some other company pretending to be us. Second, it assures you that the code hasn’t changed between the time we signed it and the time you downloaded it. This is meant to make you safer (or at least make you feel safer). But if you think about it, code signing is arguably pointless. No malware you’ve ever been a victim of is stopped by a code signing requirement. If this requirement were lifted, all the same malware would continue to work just fine.

Anyway, signing our executable and getting it to work after it is signed has been a challenge. But we’re working on it.

Meanwhile, I’ve been able to get back in my coding chair and have been porting the new Bible format to the Windows code. One unexpected benefit is that I’ve gotten to re-think the way we had ported this code from C++ to JavaScript in the first place and make some changes that will make it easier to maintain. I’ve borrowed some from the C++ (macOS and Windows) implementation and some from the Java (Android) implementation. This gives us good consistency between all platforms and will make maintenance easier in the future.

To sum up, after a detour to do a lot of work on other platforms, we’re back to work; we’re close to feature-complete (at least for the standard feature set); and we’re focusing on tasks that are necessary to move from development to beta to release.