The Road Ahead – Q3/Q4 2026

With the Q2 financial report published, it is time for the roadmap update I promised there and in the iOS beta announcement.

A roadmap is a way of looking ahead rather than a fixed plan. The clearest commitments in the Q2/Q3 roadmap were finishing the 5.1 release with its AI features and bringing AndBible to Apple devices, and both of those happened much as intended — in the case of iOS, rather more than I had promised. What has shifted is the part further out. In April I placed a shared Android/iOS codebase somewhere in 2027, with the Bible Knowledge Graph and the Strong’s annotation pipeline ahead of it in the queue. Since then the iOS work has moved considerably faster than I expected, and I have spent a great deal of time on it, learning and thinking along the way. The upshot is that the shared-codebase project has moved to the front, and the next several months will go into it.

Looking back: Q2 in brief

Q2 was about shipping what Q1 had built, and stabilising the app around it.

AndBible 5.1 went to production on 13 June — the largest release in some time, bringing optional AI assistance, the reading and memorisation progress tracker, and editable “My Documents” pages to everyone. The AI toolset in particular has been received far better than I dared hope, with surprisingly little negative feedback. Document Sync arrived on top of that, letting you synchronise a whole document library across devices through your own Google Drive or Nextcloud storage. Alongside these came a stream of smaller improvements: colour e-ink mode, an ePub reading progress indicator, an option to hide the status bar, and page scrolling with the volume keys in list views.

And in mid-July, AndBible for iOS entered public beta on TestFlight — for iPhone, iPad and Apple Silicon Macs. The credit for that release belongs to Jared Murrell (Primetheus).

In total the quarter came to 75.2 hours of work, about 69 of them sponsor-funded.

Why iOS moved to the front

Jared started the native iOS port back in 2021 — years before the AI era. His approach was to take the AndBible Android codebase as the source of truth and build a separate, natively written iOS app from it, and for most of those years that was hand-written work.

He kept the project to himself for a long time: he was not sure it would ever come to anything, and he did not want the pressure that a publicly announced project brings. He only told us about it earlier this year. Over the spring his AI-assisted workflow has grown markedly more effective as the project has advanced, and the progress has been dramatic: the port has now reached very nearly full parity with the Android version — something I could not have dreamed of.

I see God’s leading in this, particularly through the work Jared has done. He gave the iOS effort the push it needed, and I do not want that work to go to waste. That is why I spent the spring accelerating my own readiness for iOS: I bought a MacBook Air M1 specifically for this project and have been working on the iOS release ever since, most recently the public beta.

But the current iOS version carries one catch: it is a separate codebase. Every feature — each new one, and each of the ones still missing on iOS — has to be built twice. Jared and I both see that this is not a sustainable foundation. What we want instead is a single codebase that serves both platforms well, at full feature parity, with a consistent user interface.

An unplanned proof of concept

What settled the technical question for me was not planned at all. MIDI Recorder is a hobby project of my own, written to record my piano improvisations automatically. I published its Android version in the spring, with the UI written in Compose from the start, and over the summer turned it into a single shared codebase serving both Android and iOS with Kotlin Multiplatform and Compose Multiplatform — the iOS app is built from that same code. Looking back, I take that time as God’s leading: without intending it, I had built exactly the proof of concept I needed for the decisions now in front of me in AndBible.

It clarified my thinking about AndBible’s future considerably. I used to believe that supporting iOS would take more work than this project could ever muster, and for a long time that was a fair assessment. AI-assisted development has cut that effort dramatically, and Jared’s port is itself a demonstration of how much ground can now be covered with modest resources. My own experiment convinced me that Kotlin Multiplatform and Compose Multiplatform are the right foundation for AndBible.

The plan: one codebase, and a modern interface

The work breaks down roughly like this.

1. Work from both existing codebases. The Android version is the source of truth for the port, with the iOS version alongside it for comparison — it has already solved a number of hard problems well, and there is no reason to solve them twice. The porting itself is done with AI agents.
2. Rebuild every screen in Compose, one at a time, with the old implementation living side by side with the new one behind a flag. That way nothing is broken while the port is in progress. Most of the architectural change happens here too, screen by screen: a Compose UI is reactive and declarative, so event-driven patterns have to give way as each screen is ported. In places that means changing a fair amount of existing code — sometimes quite a lot of it.
3. Test all of it carefully once the screens are done, and iterate — fixing every problem that surfaces, step by step. This phase also includes genuine UI/UX improvements: the project is a UI/UX modernisation, so it is the natural moment to modernise interface decisions that have aged.
4. Ship it to Android first: a beta, then a production release. This stage adds no new features, though existing features may gain UI/UX improvements. AndBible’s interface will get a significant refresh (Material 3) along the way. A change of this scale deserves a round number, so that release would most likely be AndBible 6.0.
5. Then settle the remaining questions. Nothing is locked down yet, but the likely path is the one the iOS port already took: replacing JSword with libsword. A decision is also needed on the database. I would like to keep Room — Room Multiplatform may be the answer — but there are technical challenges there that I have not thought through to the end.

The project has started well, and it is already at step 3. Every screen has been ported to Compose in a first pass, and the human part of the work is now under way: going through each function in turn, looking closely at how it behaves and how it looks, writing down every shortcoming and defect, and fixing them with AI assistance. This iteration is laborious, and it is the slowest stage of the whole process — but it is also where the fruit is. Usability improves, the interface is modernised and becomes better-looking, and a good many practical improvements arrive along the way.

My target is to have the shared codebase done by the end of 2026. That is a target rather than a commitment — and it assumes I can keep giving AndBible a substantial share of my time, which depends in no small part on the level of sponsorship. My thanks to every sponsor who helps keep that time available.

So the coming months are groundwork more than new invention — and it is good, motivating work to be doing. It will multiply how many people AndBible can reach, and it leaves the app in far better shape for everything that comes after. That does mean the Bible Knowledge Graph and the Strong’s annotation pipeline wait their turn; they remain very much on my list, and building each of their interfaces twice, once per codebase, is precisely the trap the shared codebase exists to escape.

Contributions, and working together

There is a second reason this project matters, beyond maintainability.

I want Jared to have an unobstructed path to contributing to AndBible. He has shown himself to be a first-class developer: highly professional, highly effective with AI tooling, and remarkably committed and hard-working as a volunteer. I do not want to be an obstacle to him. A single codebase, plus a process we build together for making large changes to it safely, is what makes that possible — and we will use AI heavily in that process, naturally.

That brings me to code contributions in general, and I want to be straight about them, because the situation has genuinely changed.

The bottleneck has moved from writing code to making use of what is written. AI can be applied through a great many different processes, and they do not all produce comparable quality — so the demanding part of a contribution is no longer producing it, but establishing that it is sound and that it fits where the project is going. Careful review, not implementation, has become the scarce resource. AI-assisted review helps to a degree, but assessing an unfamiliar change often takes more of my time than building the same thing myself with AI tooling would. That is the honest reason a number of pull requests have gone without the attention their authors deserved, and I am sorry for the silence that has meant in practice.

To be practical about it: until the modernised, shared codebase is in place, larger contributions are not something I can realistically take in. The code is about to move underneath every screen, so a substantial pull request written against today’s implementation would in all likelihood be obsolete before I could merge it. Small, well-scoped fixes remain welcome. If you have something larger in mind, the best route is to open an issue and talk it through with me first, so we can agree on the approach and on the right moment for it — which is exactly what Jared and I are doing at a larger scale.

Ideas themselves are as welcome as they have always been, quite apart from code; a feature request on GitHub is the best way to send one my way.

What’s next

Q3 2026

• Work through the Compose port screen by screen: review each function, fix what is lacking, and improve the UI/UX as I go
• Take the native iOS app from beta to a production release on the App Store — this is the current iOS version, not the multiplatform one
• Catch up on user support and issue triage

Q3–Q4 2026

• Finish that review-and-fix pass across the whole app
• Material 3 interface refresh
• Android beta, then a production release of the modernised UI — most likely as AndBible 6.0
• Decisions on the remaining questions: libsword and Room

After that

• Full feature parity between Android and iOS on one common codebase
• Bible Knowledge Graph and the Strong’s annotation pipeline

Sponsorship and sustainability

My thanks go to the faithful sponsors who make this work possible. Their support is why AndBible is moving at a pace I would have found hard to imagine a couple of years ago.

Part of that pace comes from the way software development itself has changed. AI has reshaped this industry in a remarkably short time, and it now plays a central part in how AndBible is built — which means a sponsored hour buys considerably more than it used to. The work is every bit as demanding: I no longer type most of the code, but I take full responsibility for all of it. What has changed is where the time goes. The hours that once went into typing now go into design, and I can plan larger and more ambitious changes than I would previously have thought possible — this multiplatform project being a case in point.

AndBible development remains a side project alongside near-full-time employment. What I am working towards is one full day per week fully dedicated to AndBible — roughly 90 hours a quarter. Funding at that level, sustained and predictable, is what would let the present momentum continue: regular releases, responsive support, and steady progress on the items above.

If you would like to help make that happen, you can support AndBible through the webshop — either as general development sponsorship or by commissioning a specific feature. Recurring sponsorship by bank transfer is also possible; get in touch for details. There is also a GitHub Sponsors button, added last quarter, for easy recurring monthly support. It differs from the webshop in kind: webshop sponsorship is essentially purchasing development hours from my company, whereas GitHub Sponsors is a plain “thank you” donation.

Thoughts and feedback are genuinely welcome.

God bless,
Tuomas Airaksinen
Lead developer, AndBible Open Source Project