Creating an iOS version of the app

[vinayneekhra]

Hi,
Habits is a great app.
I was wondering about developing the app for iOS.

Has this been considered in past? If yes, what is the status of the project?
If I want to begin, do you have any suggestions, where should I start?

Cheers,
Vinay

[iSoron]

Hi Vinay, there are no current plans for porting the app to iOS. I would imagine this would take considerable effort, since none of the code base could be reused, and, unfortunately, I don't have any experience with iOS development and I don't own any iPhones or Macs, so I wouldn't be able to help.

Quite a few users have asked me about an iOS version, though, so there is certainly a demand for this. If anyone wants to build a prototype, you are very welcome.

[qcao]

Would be great to have that!

[hyiltiz]

Hey, I have several macs and friends who have iPhone. Considering this is actually the only functional and user friendly GPLed time tracking software for mobile devices, would be really great to port it to iOS. How about we discuss the alternatives? Maybe port it onto some web app framework (Electron comes to mind) so both iOS and desktop can use it, or maybe integrate it on top of some framework that makes it possible to run Java programs on iOS? There should be some frameworks that provide Java APIs for iOS.

[iSoron]

@hyiltiz I am currently separating the code of the app into two modules -- uhabits-android, which contains the current Android UI, and uhabits-core, which is a pure Java module containing everything else. The idea is to make the Android module as thin as possible, so that porting the app to other platforms is easier.

Perhaps we could use some transpiler, such as GWT, JSweet or J2ObjC, to convert the pure-java module into Javascript or Objective-C, but I have no experience doing that. If anyone wants to try, that would be great. I am also open to converting the core module to Kotlin, which can be compiled both to Javascript, as well as native code.

[hyiltiz]

Looking through Kitlin's documentation, and the two links you provided, it seems once the uhabits-core becomes a module/library in Kotlin, then trying to make it run on iOS seems quite feasible with multiple approaches. As you pointed out, one could go via JavaScript or simply native code.

I would guess that, given these many opportunities, it would be important/useful for all developers if you could show us how you plan to separate uhabits-core into modules, and which would be interesting to test out in iOS first. Then maybe we could test out some of the alternatives based on a small module, and decide?

[AuroreM]

Hi !
Have you ever considered using React Native ?
I'm a big fan of your app. I can work on a POC if you like :)

[vinayneekhra]

Since there are many options available, should we decide on the technology to build the iOS version?
Then all of us, who are interested in contributing can collaborate over some repository?

Swift and native tech is something I would prefer.

[luisnabais]

Hello. I would also love this, I used Loop in Android, now I would like to use it in iOS as well.

[hyiltiz]

@AuroreM For maintainability, a JS-based solution seems appealing, compared to a native solution like Swift as @vinayneekhra suggested. It seems @iSoron is more interested in converting the core parts to Kotlin (may have already started doing so by now). If that is the case, maybe we can try converting that to js and test out some minimal functionalities. I assume it converts to vanilla js. Then we can wrap the core functionality with React based UI, so it will be accessible to any devices thru browser wrappers. Any ideas?

Disclaimer: Personally I have using web tech for pure local apps like this, but it that makes development easier and increases maintainability, then it is not a bad thing at the end of the day.

[vinayneekhra]

@hyiltiz This seems a good idea. I am not familiar with using web tech in iOS apps.
I worked on Electron and also a bit familiar with Kotlin.

Regarding the above approach I have little exposure, so once we decide the tech stack, I may be able to contribute.
If possible, could you suggest some resources which you found useful for using web tech for mobile apps?

For maintainability, a JS-based solution seems appealing, compared to a native solution like Swift as @vinayneekhra suggested.

Did you mean that it would be easier to maintain because we would have one base code (in Kotlin), and/or we would have more contributors, or is there something else?

[hyiltiz]

I did a quick but relatively thorough search on cross mobile platform solutions, and it seems React Native is the best one out there to port uHabit. You can read more about those yourself, but here is one of the links that connects to many others [1].

It is easier to maintain a single code base than, say, a Kotlin and a Swift code base for Android and iOS separately. And yes, the JS community is much larger compared to the native app developer communities.

So, React Native does seem a good choice, thanks @AuroreM! A good starting point would be to look for apps that are based on React Native, that has similar UI to uHabit; an options grid/table, then a statistics page. I found an app [2] that has a statistics page, but we can keep looking. That way, we will have an idea what the final product would look like, and then figure out how to get there.

[1] https://www.reddit.com/r/javascript/comments/32iibr/what_js_framework_should_i_use_to_build_a_mobile/
[2] https://github.com/transistorsoft/react-native-background-geolocation

[iSoron]

As far as I know, React Native does not support many platform features, such as Widgets, AlarmManager or custom views. I would also expect its performance to be significantly worse than what we currently have, but please feel free to try to code a prototype.

The idea I had in mind was to create a core module, written in Kotlin, that would contain all the logic that is not specific to Android. This module could be compiled into a JAR file, which could be used by an Android version of the app; into a Node.js module file, which could be used by a desktop (Electron) version of the app; and into a static (native) library that could be linked by an iOS app. We would still need to write some native code for each platform, but it would be significantly easier.

The job of splitting the project into modules is mostly done. The core module already compiles into a JAR, which is used by the Android version of the app. I didn't proceed because Kotlin still doesn't officially support multi-platform projects. While you can write Kotlin/JVM code that compiles to the JVM and Kotlin/JS code that compiles into Javascript, it's really painful to write some Kotlin code that compiles to both. They are currently working on a solution, and when that rolls out, I will have another look.

[luisnabais]

Have you looked at Ionic Framework?

[kevin-zhan]

Hello, I do love the app. Thank you very much for providing such an awesome app.
I have developed iOS app for almost two years. Now my job is as an Android engineer.Thus, I want to do something interesting about iOS at free time.
I wander if I can join you and make a nice iOS app~

[trymeouteh]

Would be great but not the same as Andriod since iOS does not have a file explorer system which means you cannot make backup files unless you backup the backup file to a cloud storage service.

If a iOS version does become a reality I would suggest this app to my iPhone friends.

[hyiltiz]

That is great progress! Excited to see the prototype so close to being ready.

[iSoron]

@javier-artiles That's very good progress. While you were building the frontend, I have spent some time putting together a proof-of-concept version of the core module, and integrating it with React Native. I have also made some refinements to the interface, to make it look more native on both platforms. The result is in the multi-platform branch. You can see it here. I have also included build instructions. Anyone who is interested in helping is very welcome; just let me know if you have any problems building or running the project.

My goal is to have the React Native layer as minimal as possible. Essentially, I would like to use RN to (1) display data to the user; (2) collect input from the user. Everything else, including data persistence, networking, etc can be done from Kotlin/Native.

To go into more technical details, the architecture I have in mind is the following. When the application starts, the React Native layer will request the data to be displayed from the back-end by calling, for example, Backend.requestHabitList(). The object Backend is a Native Module. The back-end will then emit a custom event (onHabitList, in this case), which will be captured by the component that requested the data. See src/components/ListHabits/HabitList.js for a concrete example. The data will come ready-to-be-displayed, already sorted and filtered. When the user wants to create a new habit or toggle a checkmark, the React Native layer will simply collect all the data entered by the user and call the corresponding back-end method (for example, Backend.createHabit("Test")). If this method is successful, an event with the updated state will be broadcasted. There's still some logic in the the React Native layer. For example, as you said, chart manipulation (deciding how many columns to display, scrolling, etc).

[javier-artiles]

Thank you for working on this @iSoron . I will read the branch in more detail this week. My only concern is related to local persistence. I don't see how the core Kotlin/Javascript library would do this task. RN apps either rely on AsyncStorage (probably sufficient for this app) or things like RealmJS. Both require RN bridging between Javascript and native modules.

[luisnabais]

Hello guys! No news on this? :(

[javier-artiles]

Hi @luisnabais , I'm been going though an extended period of crunch time at current job. I should be able to resume work on the React Native repo by mid April.

[luisnabais]

Thanks a lot for not letting this go :) Good luck on your job right now :)

[iSoron]

I am still working on the prototype at the multi-platform branch. After experimenting with React Native for the last two months or so, I have decided to move away from it. The prototype is now developed purely in Kotlin and Swift.

In the next couple of days, I am planning to make that branch the default development branch. At that time, I will create a new issue describing how does the new multi-platform architecture work, how does that impact the current Android version of the app, and how others can help.

[iSoron]

The dev branch now contains the prototype mentioned in my earlier posts. I have also created two issues to track the progress of our efforts to make Loop Habit Tracker multiplatform. Issue #486 describes the overall project, while issue #487 tracks tasks specific to iOS. Since we now have a concrete plan, I am closing this discussion thread. Thank you everyone for your input! You are still very welcome, of course, to make comments and suggestions in the newer issues. Pull requests are also very welcome.

@javier-artiles I would just like to thank you again for the work you done on the React Native port. In the end, I decided to move forward with just Kotlin and Swift, since we are already able to achieve very high code reuse using these two languages alone. Bringing React Native to the mix also increased the complexity of the project significantly, while bringing relatively few benefits. We can still, however, use React for a future web (or perhaps desktop Electron) version of the app.

[TerencedzLi]

Hey @iSoron, could you point me to instructions on how to build the prototype in xcode with the shared kotlin code? I tried to follow this comment but the compiler still ends up not recognizing a lot of classes

[Oge-nna]

Hi, @iSoron, big fan of your app, no news yet on an iOS version? :(

[fokot]

Hello @iSoron I recently switched to iPhone and I love this app. Is it possible to test the iPhone app you have now in progress? Thanks

[hyiltiz]

How can we sign up to test this? Are you in TestFlight yet?

[localpcguy]

I would recommend also looking into Flutter as a cross platform option for mobile devices.

I cannot recommend it for web, but it works great for mobile. I have significant experience with both web SPAs and Flutter and while I do love both, they each have their strong suits.

The downside of Flutter is it probably means a platform rewrite without a lot of code reuse (and while Dart is similar enough you could try to reuse logic, there are preferred coding patterns for Flutter apps that may be worth exploring of moving to Flutter.) That is a one time cost though, and once built, a Flutter app is very simple to keep in sync between iOS and Android going forward.

[shhuayb]

I am switching to iPhone and unfortunately this app is not available on iOS platform. I have data of more than a year on my Android phone. There's still not an iOS version of this app. Can somebody here suggest me some habit tracking apps on iOS that I can integrate later with this Habits app on Android?

[iSoron]

App recommendations are welcome, as long as they are open source. Recommendations to closed source apps will be removed.

[MechtEngineer]

@shhuayb, did you find any iOS apps that were able to import the CSV data exported from Loop Habit Tracker?

[juliusremes]

Hey Folks,
any news regarding the iOS app?

[12people]

Here's a free and open-source (GPLv3) app recommendation: Habo, which is a multiplatform Flutter app.

It's still relatively new, but you can contribute to it via its Github repo.

[byildiz]

I wrote a dead simple converter from Loop to Habo for myself. If someone needs something like that, here is a link to the code: https://gist.github.com/byildiz/376bc419c270a36c0f1119f58c75d61c.

[12people]

Here's another multiplatform FOSS app: Table Habits