Native Android and iOS migration: implementation and release plan

[dongdongbh]

Status — September 22, 2026: The direction is decided: native Android and iOS clients, retaining the shared TypeScript core. We will build incrementally, test real upgrades through opt-in beta, and release each platform when ready through the existing app listing. The current apps remain production versions. The original exploration below is historical; the implementation plan is in the latest progress update. There is no fixed native release date.

Original exploration (historical)

I am looking into whether native Android and iOS apps would give Mindwtr a better mobile experience in the long run.

The main reason is how the app feels: speed, keyboard and navigation behaviour, accessibility, and each app behaving the way its platform expects. Fewer framework workarounds is a second reason.

This is an exploration, not an announcement. There is no migration date, and the current apps are not being deprecated.

Why look at this now

I reviewed the 204 mobile issues opened between 2 July and 21 September 2026. The numbers are estimates, but they are useful:

• About 12% of the issues (25 of 204) were problems that native screens would most likely not have had. They repeat in the same places: the keyboard covering the field you type in, lists that flicker or jump, navigation and deep links, sheets and pop-ups.
• Five more came from the React Native runtime underneath the screens (networking, storage, timers). New screens alone would not remove those.
• Among bugs only, the share is higher: 29 of 97.
• About half of all issues (101 of 204) were ordinary product work. Any app, native or not, has to build those.
• One fix in five added code that exists only because of the framework.

What this cannot show is how much better a native app would actually feel. People rarely open an issue to say a screen feels slow or slightly off. That has to be built and measured.

Mindwtr already uses Kotlin and Swift for its widgets, the Android capture window, Shortcuts and the Watch app. So the question is not whether React Native allows native features. It does. The question is whether native main screens would be enough of an improvement to be worth two sets of mobile screens.

One shared core stays

I do not want separate Android and iOS versions of task rules, recurrence, quick-add parsing or sync. Those stay in one place.

The first technical test is whether a native app can run the existing TypeScript core inside its own process, without React Native, and use it for queries, changes and change notices. This has not been proven yet. The reasoning is written down in two proposed decision records: ADR 0028 and ADR 0029.

If that works, the next step is a small native Android build of Inbox, the task editor and Focus, measured against the current app on the same phone with the same data. Android comes first because that is what I can test myself.

What this means today

The current apps remain the production apps. Bug fixes, translations, testing and improvements are as welcome as before. If you plan a large change to the mobile screens, please open an issue first so we do not build the same thing twice.

If native apps ever replace the current ones, that would come with compatibility testing against existing installs and other devices, an opt-in beta, and a release plan that covers the stores as well as F-Droid and direct downloads. The data format and sync would not change in the same step.

Feedback that would help

• Which Android or iOS interactions in Mindwtr feel slow, awkward or unreliable today? Device, OS version and accessibility settings help a lot.
• Which workflows or features would a native version have to keep for it to be a real improvement for you?
• If you have experience with Jetpack Compose, SwiftUI, or embedding a JavaScript engine in a native app, I would like to hear what went well and what did not.
• Would you try an early experimental build?

Apple development and testing

Looking for an old iPhone for Mindwtr development and testing

I now have a Mac mini available for iOS development, so I no longer need a Mac. I'm working on improving Mindwtr's native iOS integration and am looking for an unused or second-hand iPhone that someone in the community would be willing to donate for development and testing. An iPhone 13 would be ideal, but an iPhone 11, iPhone SE (2nd generation), or iPhone 12 or newer would also be helpful.

It doesn't need cellular service, and cosmetic damage is fine as long as the device works. It would be used for testing things that aren't well represented by the simulator, such as widgets, notifications, background behavior, audio capture, sharing, iCloud, Siri/App Intents, and Apple Watch integration.

The device would need to be removed from the previous owner's Apple Account and Find My before donation. If you have a device you'd be willing to donate, please contact me privately. Help with iOS testing and development is also welcome.

I will update this thread as the experiments produce results.

[dongdongbh]

Progress update

The first Android experiment showed a way to run Mindwtr's existing TypeScript core inside a native app, without React Native. That gives us a possible path to native screens while keeping one implementation of task behaviour, recurrence and sync.

Comparing the experiment with the current Android app also pointed at two performance problems in the shared code: the Focus calculation is expensive on a large task list, and a sync merge does a long stretch of work without a pause. Replacing the screens alone would not remove either cost.

The first improvement is now merged into main: Focus does less repeated work when it sorts tasks into sections. An independent review and a new parity test found no change in the results. The same tasks appear in the same sections in the same order. This helps the app that exists today and does not depend on any native migration. It will reach you with the next release.

Next is the sync merge: it recomputes content fingerprints that it could safely reuse. Because this is sync code, it is a separate patch with its own tests and review.

The native question itself is still open. We have not shown that native screens give a better overall experience, and there is no replacement release or migration schedule to announce. The current apps remain the production apps, and contributions to them are as welcome as before.

The goal is unchanged: a more responsive and reliable mobile app. Work on the shared core pays off whichever way the screens end up being built. The reasoning and the measurements, with their limits, are written down in ADR 0029.

[dongdongbh]

Update: native mobile development direction

After the Android prototype and its independent review, my plan is to continue developing a native Android client and to begin a native iOS implementation alongside it.

The goal is a better everyday mobile experience: more natural platform interactions, reliable keyboard and navigation behaviour, and better responsiveness. This is a direction for development. It is not a release announcement, and not a promise that every operation becomes faster.

One shared core, native interfaces

The Android pilot showed that a Jetpack Compose app can use Mindwtr's existing TypeScript core without React Native. It has Inbox, task editing and Focus, and every write goes through the existing core commands. The review also named specific corrections and remaining limits, which are recorded in ADR 0029.

The architecture stays one authoritative shared core, not separate Android and iOS versions of task rules, recurrence, parsing and sync. Android uses Kotlin and Compose. The planned Apple client will use Swift and SwiftUI, connected to the same core. Each platform follows its own conventions while keeping Mindwtr's behaviour.

Apple development is now possible locally

I have bought an M4 Mac mini for development. That removes the hardware limit I mentioned above, so the earlier request for a Mac is resolved. I can now build, inspect and debug the Apple apps myself instead of relying only on CI and community testing.

Android is further along. The Apple implementation is the next piece to build and validate; the Android results say nothing about its performance or readiness.

What comes next

The immediate Android work is improving how screens request data from the core, and responsiveness during sync. The pilot showed that a long-running sync merge can delay other core operations. That is an important problem to solve before any production replacement, not a reason to duplicate the core or rush a rewrite.

The Apple work starts with the same shared interface and a small working SwiftUI client, reusing the existing test data and correctness checks.

What this means for users and contributors

The current apps remain the production versions. There is no replacement release date, and you do not need to change anything.

Any eventual replacement must keep your data and workflows, stay compatible with the other Mindwtr clients, and go through opt-in testing before a production rollout. Accessibility, language behaviour, physical-device testing and feature completion are part of that work.

Bug reports, translations, testing and contributions to the current apps remain welcome. For substantial new mobile UI work, please discuss the scope first so we can coordinate it with the native development.

Feedback on the existing mobile experience, and help from developers and testers familiar with Compose, SwiftUI and the Apple ecosystem, would be especially valuable.

[dongdongbh]

Native mobile migration: implementation and release plan

Mindwtr will move to Kotlin/Compose on Android and Swift/SwiftUI on iOS, keeping one shared TypeScript core. The Mac mini is now available for Apple development; physical-iPhone testing is still needed. This is an implementation plan, not a native release announcement.

We will build the clients incrementally while the current apps remain in production. For users, the eventual change is an update to the existing app through the existing store listing. No second store product, new account, or routine manual data transfer is planned. We will test that replacement-install path explicitly.

The order is:

1. Foundation and upgrade safety: one core/host interface, Android pilot cleanup, the Apple host, and preservation of data, settings, credentials, and sync. Address sync-related interaction blocking as a separately reviewed correctness and performance change.
2. Everyday workflows: Inbox/capture, editing, Focus, projects/areas, search, and daily/weekly review. Accessibility, localization, and restoration are part of building these workflows.
3. Complete existing capabilities: supported sync backends, attachments, import/export, reminders/calendar, settings, and optional features. Reuse native widgets, capture integrations, and Watch functionality where practical.
4. Opt-in replacement beta and RC: after maintainer and upgrade-safety checks, use the existing Play app's open-testing track and an external TestFlight public-link group. There is no fixed volunteer quota. Any transition of the existing RN beta audience will be announced first; beta installation replaces the current app, so limitations and backup instructions will be clear.
5. Independent production rollout and stabilization: Android and iOS ship when each is ready, with separate promotion decisions for Play, App Store, F-Droid, and direct APKs, and a tested recovery path.

A native client will not replace production just because the main screens compile. Required workflows, actual upgrades, mixed-client sync, physical-device interaction, accessibility, and language behavior must be verified. No known critical data-safety or core-workflow blocker may remain. Few reports or a quiet beta do not count as a pass.

The migration is complete when both native clients are stable production versions across their supported channels and the obsolete RN mobile stack can be retired safely. Desktop is not being rewritten, and the first native releases will preserve the data/sync contract.

Help with Compose, SwiftUI, accessibility, translations, or testing a particular workflow is welcome. Please coordinate substantial legacy mobile UI changes so work is not duplicated during migration. We will track progress against implementation and release-readiness milestones rather than promise a production date.