Make Loop Habit Tracker a multiplatform application

iSoron commented 5 years ago

Since the beginning of the project, one of the most requested enhancements to Loop Habit Tracker has been to make the app available on other platforms, such as iOS and the web. With the upcoming release of Google Fuchsia and the constantly changing Android APIs, it's also an overall good choice, for the future of the project itself, to make our app less reliant on platform details.

In the next following ~~months~~ ~~quarters~~ years, I will be working to make Loop Habit Tracker a multi-platform application, based on Kotlin Multiplatform. In the last few weeks, I have already started building a prototype iOS app using this architecture, which is now available in the dev branch. There is still a lot of work to do, and I would greatly appreciate any help. Pull requests are very welcome!

To make coordination easier, I have divided this task into three phases, as follows. Each phase will also have its own issue to track its progress.

[ ] Phase I: Develop iOS version of Loop Habit Tracker: At the end of this phase, we will have a completely functional and fully-featured version of the app running on the iPhone. Shared code will be written in Kotlin, while platform-specific code (to be kept to a minimum) will be written in Swift. The app will be made available for free on the App Store.
[ ] Phase II: Refactor Android app to use multiplatform code: Our current Android app is still working great, and that will not change. At the end of Phase II, the Android app will still look and behave exactly the same as today, but, internally, it will be using the same shared code as the iOS app developed in Phase I. Most of our Android code is already in Kotlin, but during this phase we will finish migrating away from Java completly.
[ ] Phase III: Develop web version of Loop Habit Tracker: Now that the app is already available on two platforms, it should not be that challenging to port it to others. The third major platform I think we should target is the web browser. Thanks to Kotlin's ability to compile to Javascript, it should be possible to have the app running entirely inside the browser, without any server-side code, and with full offline support. The front-end could be built with React and Javascript.

The idea is to execute the three phases above sequentially, but if anyone feels really compelled to start Phases II and III early, you are also welcome. Just let us know in advance, so we can keep coordinated.

I always say that pull requests are welcome, but they are especially important this time, given the amount of work involved. Your contributions could make this move much faster. This is also a great opportunity to learn new technologies and methodologies.

If you have any other questions, suggestions or concerns, please feel free to leave a comment.

hyiltiz commented 5 years ago

Google Fuchsia release is upcoming?

yohannd1 commented 5 years ago

@hyiltiz probably in some years we'll have something funcional. I don't think it will be before 2022, though.

criscola commented 5 years ago

Is there a Trello or something like that with a list of tasks?

iSoron commented 5 years ago

@criscola For the iOS app, there is a list of subtasks at #487. If anyone is working at a particular subtask and would like to start an implementation discussion, feel free to submit a work-in-progress pull request.

criscola commented 5 years ago

Can we create one for the web version?

angelseye commented 4 years ago

@iSoron Hi! I'd be interested in helping to lead/develop the web platform. I have a background in web applications and especially on the web UI side. My background spans over 20 years with my most recent work experience getting me into React. In looking for a habit tracker to facilitate my goals for 2020, I found this one and it would facilitate a habit to produce more development content in 2020. Please let me know how/where to start and maybe get a feel for your vision. Thanks

mahdikhashan commented 3 years ago

I can help with the front and back.

lukaszlew commented 3 years ago

Would it make sense to create common open-source format for the habit data and use cloud storage in the Android app? This would allow other apps (say web app, iOS app) to share it and have multi-platform experience. I understand this might spur competition but perhaps that could be a nice way to offload development to more engineers?

iSoron commented 3 years ago

Would it make sense to create common open-source format for the habit data and use cloud storage in the Android app? This would allow other apps (say web app, iOS app) to share it and have multi-platform experience.

Loop Habit Tracker's backup file is based on SQLite and should be easy to parse. If anyone is interested in writing a habit tracker for other platforms which can read Loop's backup files, you are welcome. If your project is open source, please feel free to share it with us. That being said:

Please do not name your app "Loop Habit Tracker" without our permission.
If your app is not open-source, please do not promote it in our bug tracker/discussion forums.
I make no guarantees that our backup format will remain the same over time.

lukaszlew commented 3 years ago

Thanks and thanks for the guidelines. I became aware of the format after I wrote last comment. Yet, there is no mechanism to export 'on edit' so that other apps can synchronize instantly. But it seems to be covered in #702 and #104, thanks.

sahirmpatel commented 3 years ago

Hi I can help with the frontend too for the web version

12people commented 3 years ago

@iSoron Have you considered moving to Flutter instead? Given that it's native to Google's Fuchsia and builds for all major platforms (including iOS, web, Linux, Windows, and macOS), often with little to no adjustment needed, I imagine using that could decrease maintenance burden quite a bit.

RobertHeim commented 2 years ago

I would love to contribute when the project moves to flutter. 💖

Have been using the app over 4 years now! wow! :D

I have 20+ years exp in all kinds of software development and we use flutter professionally. It has been the most enjoyable coding experience among all frontend technologies I used (classical web, native android, react native, react web, ...). Flutter is awesome and super easy to learn!

localpcguy commented 2 years ago

I also would recommend considering Flutter for the mobile app versions, allowing a single code base for iOS and Android.

However, I would not recommend it for web at all. I say this as someone who is involved with significant web dev and having worked on Flutter apps for a couple years now as well. They are different enough platforms.

Flutter is awesome for mobile though and this app would be a perfect candidate for it. And it is simple enough a web version is doable separately in React, Angular, Vue or really any of the SPA frameworks.

s6thgehr commented 2 years ago

I would love to contribute when the project moves to flutter. 💖

Have been using the app over 4 years now! wow! :D

I have 20+ years exp in all kinds of software development and we use flutter professionally. It has been the most enjoyable coding experience among all frontend technologies I used (classical web, native android, react native, react web, ...). Flutter is awesome and super easy to learn!

I am learning Flutter and would also love to contribute when this project moves to Flutter.

@localpcguy Why would you not recommend Flutter for web? I have no web dev experience, just want to know what the disadvantages are because I have some ideas for web projects and I thought I could use Flutter for it as well.

localpcguy commented 2 years ago

@s6thgehr probably not the proper forum, one of these days I'll actually write it up into a blog post. And I should say "it's not ready for production use now" - it may well be ready in the future if the Flutter folks change a few of their base assumptions around what is acceptable when it comes to building web apps.

The main reason I do not recommend it is because it renders to Canvas. This may seem like using the Skia engine but it is, IMO, fundamentally different as the canvas element is at a completely different layer of the stack compared to Skia. Heck, when I heard they were doing web, I was hopeful the smart folks behind Flutter had figured out a way to do that in the browser (which would be at least interesting).

Anyways, rendering to canvas leads to a number of issues IMO - large bundle sizes (meaning slow loads/loading screens/etc.) and inaccessibility being the major two I focus on. It's also had it's share of performance issues, although I'm sure those are or can be ironed out. I've been through a number of cycles of "this tech will replace the web app as we know it" cycles, and I feel as long as Flutter continues to push forward with the same tech they currently use, it will (and should) be relegated to the same trash heap of history in a few years. I have some hope, as they are apparently working on an HTML renderer. I haven't looked into the details yet though, so can't offer an opinion yet. I am a bit proponent of accessibility, and I do not see it being done well in Flutter web (as compared to native web, at least).

Bit more philosophical (I understand some folks won't agree with this) - There is also a long tradition on the web of being able to "peek behind the curtain" and that has enabled a ton of people to see something cool and learn how it was implemented, and then go on to build something better based on that learning. Truly standing on the shoulders of giants, as it were. The web is an open platform (for the most part) and that has enabled it to grow by leaps and bounds become as popular as it is. And it levels the playing field for folks who want to enter the dev field, adding to the diversity of voices that tends to make the web technology better over time.

I think it's fine for experiments, playing around, etc. But I would not currently plan out a production app I was building as a business or even a well supported hobby and have Flutter web be the web portion. I'm open to new information or to find out I'm wrong or my information is out of date, but this opinion is based on my current knowledge of what they are doing and 15+ years of significant web dev experience.

cocoonkid commented 2 years ago

Can't wait for the web version! Keep up the great job!

Shahin-rmz commented 2 years ago

Hi,does anyone need Python FastAPI dev? At your service. P.S I love the app, and now should give something back.

Dieterbe commented 2 years ago

I'm curious how Kotlin multiplatform compares to React Native. Seems that React Native is very compelling as it targets web dev + native (!) ios and android, and has been used by many app developers (see https://reactnative.dev/showcase)

whereas according to https://kotlinlang.org/docs/multiplatform.html:

Multiplatform projects are in Alpha.

Seems Kotlin Multiplatform requires that you write a separate UI for ios and a separate one for android, only reusing business logic, whereas with react, most or possible all frontend code can be shared. I realize porting the app to react is probably an excessively large undertaking. I just wanted to bring it up to see if anyone has thoughts. (I am interested in learning web dev and android (e.g. kotlin) and am learning React Native right now as it seems it lets me do both)

UPDATE: i found some stuff regarding react native in a prior thread https://github.com/iSoron/uhabits/discussions/277, seems it boils down to "too much work". that said, if kotlin can be compiled to javascript, then it seems the uhabits core could be converted to javascript and a react frontend developed (which may work for android + ios + web), which would possibly not be much more work than the kotlin multiplatform path which also requires building a new UI in a new technology (and may or may not cover a web app). of course in practice there's more nuance like quality of the transpiled js code, etc.

12people commented 1 year ago

There's a relatively new framework called Jetpack Multiplatform, which brings Android's Jetpack Compose to iOS, Linux, macOS, Windows, and the web. (Though iOS and web support is not stable yet.)

This would probably be the easiest and most straight-forward way to port the app to other platforms, as it:

doesn't require the app to be rewritten in a different programming language
doesn't require writing a separate UI for each platform

matbgn commented 1 year ago

You could also use Tauri (https://github.com/tauri-apps/tauri) which is now supporting the mobile part https://tauri.app/blog/2023/03/20/tauri-2-0-0-alpha-4

Unlike Jetpack Compose, the supported development ecosystems are web oriented (Angular, Svelt, React, etc.), so depending on your skills it could be much easier to reboot it with your beloved frontend framework and then just build it to all the targets you wanted to be cross-platform.

Here a bunch of useful links and documentation:

https://github.com/tauri-apps/awesome-tauri

Shahin-rmz commented 11 months ago

Hello, any progress on this issue?

Dricc123 commented 10 months ago

@angelseye no update on a future web platform?

nikhilweee commented 9 months ago

I would love to help with the web backed in whatever capacity I can.

Not sure what's the current plan to sync data between multiple platforms, but one approach that comes to mind is to have the app store the database periodically on a cloud provider (Google Drive) and have the web version use the same file. This saves the overhead of maintaining a database, and the web app can essentially be a standalone frontend to the sql database, thereby reducing hosting costs. This way one can essentially "Sign in with Google" in their browser and continue using the app on the web. The hiccup right now is for the mobile app to constantly push and pull from the cloud provider. Not sure how much of a bummer that would be.

inson1 commented 9 months ago

What about desktop or at least pwa?

astingengo commented 1 week ago

Any updates for web support?

iSoron / uhabits

Make Loop Habit Tracker a multiplatform application #486