As the CHT community continues to grow in Nepal, our user base is also expanding rapidly. Based on our experience during training sessions, we have observed a significant increase in iPhone users among participants, including health workers, CHWs, and supervisors.
In Nepal alone, there are approximately 800,000 iPhone users [source], and this trend is gaining momentum globally. Notably, the number of CHT users who are also iPhone owners is on the rise.
From a user experience (UX) perspective, users increasingly prefer dedicated applications over browser-based platforms. Browser usage comes with limitations, such as users unintentionally removing the browser and the inconvenience of forgetting web addresses. These factors negatively impact user engagement and overall experience.
To address this, we urgently need to make the CHT application compatible with iPhones. This will not only enhance user satisfaction but also ensure seamless accessibility and improved engagement rates.
Has there been any prior work done to bring CHT to iOS? If so, what is the current status, and are there any existing roadblocks? Are there any plans or timelines in place for iOS development?
We kindly request your support in making the CHT application available for iPhone users as soon as possible.
#1. The first challenge with supporting iOS is that there is no way in iOS to use Chrome (or Firefox) as the webview that renders the app. To the best of my understanding, iOS only allows Webkit (Safari) to be used as the webview in apps. Currently, cht-core only targets Chome/Firefox (historically there has not been much need to support Safari). There does not seem to be any known hard blockers to being able to target Safari, but we would not know for sure until we tried to do more extensive testing.
#2. Then there is the issue of a wrapper app. The current cht-android code is Android-native and it will be non-trivial to port it to something else. Honestly, I would lean towards a complete re-write using something like Capacitor that could (hopefully) let us leverage the needed native apis in both Android and iOS without having to maintain separate code bases for both apps.
#3. Then you still have to publish/distribute that app. I am not at all familiar with iOS development, but I have the sense that side-loading apps is harder (impossible?) and 3rd-party app stores (F-Droid) are not really a thing. So you would need to publish apps to the Apple Store and I think that requires paid license(s).
So, TLDR is that I do not know of any absolute blockers that would prevent us from getting CHT onto iPhones, but it will be a non-trivial process to get there.
@Pawan_KB - welcome to the community! Thanks so much for taking the time to voice your interests in supporting iOS!
Thanks so much Josh for the great technical write up about what would be involved to get a native CHT app on iOS - looks challenging but possibly do-able.
I wanted to touch on some of your other points:
approximately 800,000 iPhone users… Notably, the number of CHT users who are also iPhone owners is on the rise.
By some measurements, this look to be ~2% of mobile users (800k out of 37m), but more importantly you have on the ground data showing viability amount the Nepali the CHW community that uses iOS.
Browser usage comes with limitations, such as users unintentionally removing the browser and the inconvenience of forgetting web addresses
Do you have more specifics around this scenario? While you can uninstall Chrome on select Android phones, most only allow you to disable it, an option buried deep in system settings and not available in the Play Store. As well, all CHT Android APKs have the web address of the CHT deployment hard coded in them. Are there scenarios you’ve encountered where this is not the case? Possibly using the Unbranded CHT Android App?
Understanding the challenges faced in the field can be done through first hand knowledge which it sounds like you might have - please share if you’re able!
Has there been any prior work done to bring CHT to iOS? If so, what is the current status, and are there any existing roadblocks? Are there any plans or timelines in place for iOS development?
I wanted to be sure to touch on this - it’s a very reasonable question! The answer to all of them is that Medic has no current plans to to support iOS. We would look to a partner who has the interest in doing this work themselves or sponsor contractors to do the work. Medic will be available to assist in answering technical questions and possibly form a squad to facilitate ongoing development.
I guess @Pawan_KB was referring to Chrome getting uninstalled on iPhones here. I’ve also noticed an increase in iPhone and iPad users around me. One reason people might uninstall apps like Chrome could be limited storage, especially for photos and videos. Since Apple devices get significantly more expensive with higher storage options, users may try to free up space by removing apps they don’t use frequently.
Dear @mrjones,
Thank you for your valuable insights on the topic. To add further clarity, I would like to share some observations based on recent data and field experiences.
As you mentioned:
This aligns with the data I recently found online. During our field training sessions, we observed that, on average, 3 out of 10 users are iPhone owners, and they frequently inquire about iOS-compatible applications. This highlights the growing need for iOS app development to cater to this user base.
In the past, our SMS-based solutions were universally accessible, as they only required basic phone functionality. However, with the recent deployment and ongoing implementation of the CHT application for health workers, we are encouraging the use of personal devices, including both Android and iPhone. While Android users can easily download the app from the Play Store, iPhone users face challenges due to the unavailability of the app on the App Store. This gap has made the need for an iOS-compatible app increasingly apparent, both for us and our users.
I hope this provides a clearer picture of the current scenario. Please let me know if you need any additional information or further clarification.
Thank you!
Thanks @Pawan_KB ! No further information needed from my perspective.
Per my mention above, Medic still does not have plans to add iOS compatibility and would look toward a partner to pursue this enhancement, or funding development of the enhancement, to the CHT.
How does the CHT/Medic team feel about using Flutter for the wrapper?
Flutter is a free, open-source UI framework that’s relatively easy to learn (a coworker used to joke that it was “dartascript”). It’s pretty powerful, has heaps of documentation, and is cross-platform - including desktop - which could open up some interesting possibilities down the line.
A bunch of libs are maintained by the Flutter team themselves.
And if something’s not available out of the box, Flutter supports custom platform channels to talk directly to native code:
MethodChannel - call native functions and get a response
EventChannel - stream data from native to Dart
BasicMessageChannel - send basic messages both ways
I’m definitely painting a bit of a rosy picture here - there are probably complexities I haven’t considered (especially since I haven’t worked with the current wrapper app). But I’d love to hear what you all think, and whether Flutter could be a good fit moving forward.
Flutter definitly has a lot of momentum in this space and I expect it would support the kind of WebView/cross-platform functionality we need (especially given the resources you have helpfully linked here). I don’t have any experience with Flutter, but one concern I have had from doing some reading is:
Flutter ships applications with its own rendering engine which directly outputs pixel data to the screen
In general this is maybe not a problem (though I do get Electron vibes from this approach… ), but I wonder what affect this has on the size of the app binaries? Increasing our app size from 0.5mb to ~50mb would not be good. My other reservation about Flutter is that it would add the Dart stack to the list of things CHT devs have to work with. (Maybe this is not a huge deal since it would actually be replacing the Java stack and we don’t have a huge depth of experience there anyway…). But, I still feel like I would want to have a clear understanding of the benefits of Flutter over something like Capacitor which seems much more “native” to the NodeJS ecosystem (for better or worse… ). All of this seems like a great topic for further discussion during a CHT Dev Hour!
Valid point, @jkuester! Yeah, since Flutter relies on its own rendering engine (Impeller) - unlike native apps, which use the device’s built-in components - it does come with an upfront cost (from what I can tell, APK around ~15MB). Apparently, if some of the experiences are to be believed, that size doesn’t increase much as the project becomes more complex, if resources like images, imports, and so on are managed properly.
That said, if our app size is currently around ~5MB (based on the budgets listed in the angular.json file in webapp), then a ~10MB increase is still significant - especially considering the internet access challenges faced by some members of our community.
There might be a ray of hope in the form of appbundles, which could make Flutter somewhat more viable. When building an app with flutter build appbundle --obfuscate --split-debug-info=<path>, the size is significantly reduced. Based on this post, the final AAB output may still seem a bit large (17MB), but the actual download size of the appropriate APK (as delivered by the Play Store) can be much smaller - around 6.4MB.
I haven’t played around with Flutter recently, so take this with a grain of salt, but this does match my past experience using Firebase App Distribution when releasing our app to testers.
One can also get a good size estimate around bundle sizes by using the --analyze-size flag when building an app bundle.
All that said, and with my limited understanding, Capacitor still seems like the better fit. As you’ve noted, the team’s experience lies more in web development, so it makes sense to capitalize on that. The learning curve would be easier, the simpler stack would be easier to manage, and the initial setup appears much more straightforward.
), but I wonder what affect this has on the size of the app binaries? Increasing our app size from 
). All of this seems like a great topic for further discussion during a