How to implement Dhis2 sdk's features in ios?

Hello community! This is my first post at DHIS2 community forum!

I’m a flutter developer currently researching system architectures for a Google Summer of Code 2026 proposal with LibreHealth (for the NeoRoo neonatal care app which uses DHIS2 web apis at the moment). This year, the project’s goal is to implement robust, offline-first cross-platform synchronization using Flutter and the native dhis2 sdk integration.(Click here to check out the project’s description)

I have been working on the proposal and mapping out the Android architecture using Platform Channels to bridge Flutter with dhis2-android-core (utilizing D2Manager, TrackedEntityModule, etc. for local SQLite sync).
However, looking at the iOS side, I am having trouble finding an identically featured, officially maintained native DHIS2 Swift / iOS SDK to bridge to. And it is one of main objectives of the project.
So, could anyone please provide guidance on the following:

  1. Is there an officially recommended and actively maintained iOS native SDK for DHIS2 that handles offline-first SQLite storage similarly to the Android Core SDK?

  2. If not, what is the community’s current recommended standard for building offline-first iOS applications for flutter? (e.g., using raw API calls to a custom CoreData layer, or utilizing Dart-level SQLite databases like drift/sqflite?)

  3. Is there any active roadmap for migrating the Android SDK to Kotlin Multiplatform (KMP) to support iOS natively?

Any insights or recommended approaches for cross-platform DHIS2 sync would be highly appreciated to help me formulate an accurate and realistic GSoC proposal. Thanks in advance!!

Hi @debasmita

Thank you for participating in the DHIS2 Community of Practice!

I’m quite sure that the current production ready support is for the Android SDK; however, there is some related work on progress as you can see that the Roadmap idea here is complete: Jira So I’m tagging: @dhis2-android for their comments on this.

You might actually be interested in checking out the recording for this developer meetup: July 2025 Developer Meetup: Build Flutter mobile apps using the DHIS2 Android SDK Tagging: @Yuseif

1 Like

Thank you so much for the help!
While I’m looking for the ios implementation of the sdk in flutter using native modules specifically , I went through the resources provided ,and these were really informative! Specially the youtube video, it was a great tutorial showcasing the implementation of the d2 library!

Hi @debasmita,

As you mentioned, the Android Core SDK does not support iOS at the moment. The Flutter SDK shared by @Gassim (thanks :folded_hands:) is good approach if you need something multiplaform and that works natively with Flutter.

That said, the Android Core SDK is slowly moving towards a Kotlin Multiplatform structure, so the idea of having a multiplaform SDK is in the roadmap. But unfortunately we don’t have a time estimation for that (it won’t happen during this year at least).

2 Likes

Thanks for letting me know! But since my GSoC proposal deadline is coming up on March 31st, I want to make sure I’m proposing the most practical solution for the NeoRoo project to handle the current iOS gap.

The core constraints of my GSoC project explicitly require implementing “platform-specific native modules” and integrating the official “d2 library” for robust offline sync.

I am planning to implement a Split Architecture using a bridge (like Pigeon,as it was mentioned in the youtube video) to route data based on the user’s OS:

Android: The MethodChannels will route strictly to custom Kotlin Native Modules wrapped around the official dhis2-android-core SDK. This fulfills the GSoC requirement to leverage the official native rule engine, internal state machine (TO_POST ), and Android WorkManager for battery optimization.

iOS: Because building a custom Swift CoreData replica of the DHIS2 engine in 350 hours is out of scope, the iOS MethodChannel calls will route to a Dart-level fallback utilizing the d2_touch Flutter SDK (or a pure native Swift custom network queue) to handle the web API and local SQLite syncing.

I’d really appreciate your take on this. In your opinion, is this the most stable compromise for a app waiting for KMP, or would you recommend attempting to build a minimal native Swift network queue instead??