this post was submitted on 02 Nov 2023
4 points (75.0% liked)

General Programming Discussion

7814 readers
4 users here now

A general programming discussion community.

Rules:

  1. Be civil.
  2. Please start discussions that spark conversation

Other communities

Systems

Functional Programming

Also related

founded 5 years ago
MODERATORS
Cloak@lemmy.ml
Restioson@lemmy.ml
4
Cross-platform mobile in 2023 (lemmy.sdf.org)
submitted 1 year ago by nickwitha_k@lemmy.sdf.org to c/programming@lemmy.ml
2 comments fedilink hide all child comments
 

Hello folks. I'm a backend guy, mostly using Python, Go, and the like. I've learned a bit of Rust and have enjoyed it for embedded.

With that background I'm curious if any mobile devs can give some feedback on the current state of cross-platform (Android, iOS, Web) for simple apps. What I currently have in mind, despite not owning a uterus, is a FOSS menstrual cycle tracker app, using encrypted local storage only (the regularity of this private information being sold by existing apps is very disturbing to me). This means that my reqs boil down to:

  • UI/UX (I suspect this would require platform-specific code)
  • Storage/DB subsystem (probably just use an encrypted sqlite)
  • Optional extras
  • Minimal third-party library usage to potential minimize data leaks as well as limiting possible vectors for ad injection

So, there's really not much to it complexity-wise. Any suggestions on framework or approaches for keeping the codebase DRY as possible (I would want to minimize required effort to update)?

you are viewing a single comment's thread
view the rest of the comments
[โ€“] Yamimakai@hexbear.net 3 points 1 year ago (1 children)

Not a mobile dev, but have utilized Flutter quite a bit at work for web development. You can have a shared codebase between mobile and web, just changing a few options when compiling to create different versions. No need for different UI/UX code if you don't mind having a web version which would really be best suited for a touch based platform.

To keep things simple, I'd suggest using a Provider approach rather than something like BLoC - we used BLoC for a while at the office and it ended up being a headache.

[โ€“] nickwitha_k@lemmy.sdf.org 2 points 1 year ago* (last edited 1 year ago)

Thanks very much. I am leaning that way, from what I've seen.

ETA: Just looked at BLoC vs Provider and...yeah. I think that Provider would be the right choice - scope for what I'm contemplating would be intentionally very limited so, no need to add that further complexity.