> So they hire a developer who was just like you "if it can be a web app then should be a web app"
I can see arguments and I am not like that, you're portraying your predisposed view about me onto me.
This argument you have is not really saying a lot to me actually since you could use Rpis with a web app as well? Tbh I don't think you save that much battery on just making it native. You complain about battery, but fail to mention that Android phones needs to be switched to be able to use the newest api:s in android development. So if you want to use new shit, your client needs to update their phones, something they would not have to do if it were a web app. But in your case, I would probably also have made a native app but that app you built don't really describe how most apps are. You are talking about an exception to the rule IMO.
I can give you a pretty similar counter example:
I worked for a client once that made a newspaper. This client has a list with all shops, kiosks etc that sell their newspaper in a database. To save fuel and to be efficient, they used an old Java Swing application that would every day calculate the most efficient route for each driver. It did a lot of other stuff as well, but that isn't important for the story. The app was fine, it was just a pain to develop and release. Because it was still actively developed. In every release, a jar file had to be distributed to each user of the app since there was no good way of auto updating the app since it was so old. Any way, the users of the java swing application would run the calculation functionality and it would give a result that was printed out and given to the drivers.
What happened later was that the app was remade and presented in a web page. Each driver didn't have to wait for a paper printout of the result of the java swing app, they could simply open their phone, visit a specific url and see their route for that day. There was nothing to install for each driver, since drivers was often changed, no need to wait for some guy that had to print out a paper for them and everything was basically automated.
The benefit here of a web app was great, since as you say truck drivers aren't the most tech literate people in the world, managing a native app here would be a great pain.
So what can we learn from our examples? That the needs are different. I get that. I never said every app should be a web app. But if you can make it a web app, you probably should at least consider it. The benefits usually outweighs any negatives. My entire point was never to not make native apps, it was to avoid them if possible.
Let's agree to disagree. And frankly I love people with love for hypes and technologies that bullshit their clients into adopting that. It means I get to do this type of work, which I call "cleanup jobs" that bring me the big bucks.
Since when is doing stuff for an open standard that will have backwards compability for likely decades following a hype? The hype technologies is imo android and ios apps. They will only work for a few years and soon enough their UI will look so ugly because of the hundred times Google or Apple has revamped their entire UX so they deprecate all apps that don't update SDK version.
Then, the clients have to replace their devices because otherwise they can't run the new app versions. This is literally a hype.
I on the other hand dont use any big frameworks, I just do web apps after the open standard that everyone agreed upon. You're a slave for whatever platform you develop for.
In 10 years when people run iPhone 50 my apps will still work as they do today or probably better due to better hardware. Can you really say the same of yours, given no updates are made?
I can see arguments and I am not like that, you're portraying your predisposed view about me onto me.
This argument you have is not really saying a lot to me actually since you could use Rpis with a web app as well? Tbh I don't think you save that much battery on just making it native. You complain about battery, but fail to mention that Android phones needs to be switched to be able to use the newest api:s in android development. So if you want to use new shit, your client needs to update their phones, something they would not have to do if it were a web app. But in your case, I would probably also have made a native app but that app you built don't really describe how most apps are. You are talking about an exception to the rule IMO.
I can give you a pretty similar counter example:
I worked for a client once that made a newspaper. This client has a list with all shops, kiosks etc that sell their newspaper in a database. To save fuel and to be efficient, they used an old Java Swing application that would every day calculate the most efficient route for each driver. It did a lot of other stuff as well, but that isn't important for the story. The app was fine, it was just a pain to develop and release. Because it was still actively developed. In every release, a jar file had to be distributed to each user of the app since there was no good way of auto updating the app since it was so old. Any way, the users of the java swing application would run the calculation functionality and it would give a result that was printed out and given to the drivers.
What happened later was that the app was remade and presented in a web page. Each driver didn't have to wait for a paper printout of the result of the java swing app, they could simply open their phone, visit a specific url and see their route for that day. There was nothing to install for each driver, since drivers was often changed, no need to wait for some guy that had to print out a paper for them and everything was basically automated.
The benefit here of a web app was great, since as you say truck drivers aren't the most tech literate people in the world, managing a native app here would be a great pain.
So what can we learn from our examples? That the needs are different. I get that. I never said every app should be a web app. But if you can make it a web app, you probably should at least consider it. The benefits usually outweighs any negatives. My entire point was never to not make native apps, it was to avoid them if possible.