yea, I can see why it can get annoying.
I’ve read that a progressive web app can actually make it to the android store
they requests some things for that, but it is possible
but yea, iOS gives PWA the big NO, so without making it an app, you lose a huge market right there.
I’ve had some problems with Cordova in the past, but when it works, it works like a charm.
Got no problems using PWA so far, so I hope it becomes defacto soon enough.
Single code base for me means missing on a huge opportunity to have them completely separated.
Thank you for all the input so far.
I will look into “progressive web apps” but I think the app store presence is a big point like @wildhart mentioned.
And many thanks to @skirunman who very detailed described their single codebase react stack, I will definitely look into that.
And as @paulishca said: “Single code base for me means missing on a huge opportunity to have them completely separated.” that is true, but after all the goal is a KISS principle for a small app that is easily maintained with as little effort as possible over years. That is why a single codebase is so important for me.
For big apps, I might agree, but for small apps mantained by a small team/single person, having more things to worry about means more man-hours and more headaches, and 2 possible sources of failures, and it makes your product more expensive in the end, a single source reduces costs, resource usages, and man-hours on small apps (and keeping the same look and feel everywhere).
@apalgen good luck!
@felbrasil I (almost) agree. But 2 possible sources of failure is a benefit not only a possible problem because at times you notice a bug in web and … your mobile app is still doing fine because you didn’t push that to mobile. More things to worry about can also mean that you enjoy the leisure of worrying one by one. You are 95% right if the app is small, prototype and it is supposed to stay small for its entire life. I feel that otherwise, separation is an opportunity.
I am trying to achieve the same thing with the following stack:
-
MongoDB
-
Astronomy for class-based schema: https://jagi.github.io/meteor-astronomy/
-
Single file component Vue and Vue Router for the front end architecture using Akryum’s Meteor packages:
https://github.com/meteor-vue/vue-meteor
https://github.com/meteor-vue/vue-meteor/tree/master/packages/vue-component
https://github.com/meteor-vue/vue-meteor-tracker
https://github.com/meteor-vue/vue-meteor/tree/master/packages/vue-router2 -
Quasar for reusable Vue components for both Material and iOS designs:
https://quasar-framework.org/
https://github.com/quasarframework/quasar-template-meteor -
Cordova for mobile deployment
But I have not implemented a real-world app yet nor tried mobile deployment so I cannot yet confirm that it is indeed a good choice in practice.
Good luck and keep us posted on your choice and progress!
Hey there, can you share more resources on vue and meteor? How did you handle accounts? Any templates to learn from?
Single code case even with vue as front end? I thought converting your meteor app to ios or android was only possible if you used blaze as frontend. How did you achieve that with vue as frontend?
Hi @nosizejosh,
For accounts, I just use the standard meteor accounts system with my own Vue templates for creating users, setting/resetting passwords.
I use vuetify for Material Design which scales well from desktop to mobile, and looks fairly close to native android.
Cordova doesn’t care what your front end library is, it just renders your page in an embedded browser. It can use blaze, vue, react, svelte, whatever you want. Once you’ve got the webpage working, add cordova and compile.
There is a new official Vue tutorial for Meteor which includes adding accounts, so give that a go. Once you’ve got it working follow the mobile guide to add Cordova.