We're running a web application and are coming across the same question.
Here are some considerations:
There is a cost to storing larger files (disk space on a cloud
repository or having to move to a larger physical server).
That cost may be outweighed by the time spent addressing complaints
by users (particularly novice or elderly users) who may have trouble
compressing or cropping their images to meet the limit that you set on your
In our case, we decided to implement a 10 MB limit and sometimes even then, use of scanners in high resolution exceeded this limit. While it's true that mobile use was fairly high, it definitely wasn't the only way users were getting images uploaded. Smartphone photos tended to be in the 2-4 MB range.
If you're in an early stage and don't expect many files, you should consider setting a high limit since you'd likely have bigger fish to fry (like focusing on other UX issues). You can always charge a fee after some threshold is met. Another option is to integrate with an API that will compress your files after upload. There are many available or you can write a quick and dirty custom one. We went with a freemium one.
One other consideration is how you store your files - if your developer stores them as blobs rather than just a path to the file in your DB, your DB can grow larger quickly with larger files (and that can have other ramifications like the DB backup strategy).
Regardless of what you choose, one piece of user feedback we received was to include copy recommending use of file uploads behind a reliable WiFi connection. This way, your users can come back to it when it's more convenient for them, rather than get frustrated on slow submissions.