When the code runs on your servers, you have much more control over the “context” in which it runs. When the code runs on the mobile devices, the context is controlled by the device OS manufacturer as well as the user. This difference leads to some subtle implications.

One major set of differences come from the lack of control of the platform. For server-side code, one can choose from a wide array of languages. For the mobile code, however, the best choice would almost always be the one dictated by the platform – Java/Kotlin on Android and  Objective-C/Swift on iOS. Also, unlike server-side where one can stick to a particular version of the language; in the case of mobile, the language version again is controlled by the platform. Same goes regarding the hardware choices – one can choose to use different types of server machines specialized in handling those jobs, eg. GPUs for math-intensive computes. While for the mobile-code, one had to write a good enough fallback to support a wide-enough set of the devices. Similarly, server-side has to rarely worry about the server killing a running process while it is normal for mobile OSes to kill backgrounded processes eventually.

The other set of differences come from the temporary changes to the platform introduced by the carrier and the user. A network request running on mobile has to be robust enough to deal with intermittent broken connectivity to outright unavailability of a data connection, e.g., due to user switching to the airplane mode. On mobile, network type matters as well. A network request on cellular would usually cost more than a network request on Wi-Fi to the user and a network request on roaming even more. On mobile, the code has to be cognizant of not doing unnecessary work when the user is low on battery. Server-side code is rarely subjected to such constraints.

Lastly, it is possible to parallelize and speed up the server-side code by adding more resources like RAM or better CPUs. If a certain number of servers are not enough, you can add more. There isn’t usually a way to offload compute-intensive or memory-intensive work off of the mobile devices without trading it off for network latency and sometimes, user’s privacy as well. While it might be preferable to go with multi-processing approach in the server code to avoid concurrency issues, on the mobile, however, multi-threading being more straightforward and less resource intensive is almost always the choice.