Server vs mobile development: Where the code runs matter

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

One significant set of differences comes 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. Further, for the server-side where one can stick to a particular version of the language. In the case of mobile, the platform controls the language version. 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 the devices. Similarly, the 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 comes 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 the 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 aware 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 a 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.

One Reply to “Server vs mobile development: Where the code runs matter”

  1. Good point. With iOS at least it becomes so much easier to push an update to your server than through the app store.

    However, also consider the cost of running a server. I think most programmers are not very good at business-y things. Sometimes (but not always) it is better to do things on the client side depending on the business model.

    What if each user costs you $1 (a little high but lets pretend for a second) per year in electricity? Not a problem really with a hundred users but kind of a big deal if you have a million. Now you have to run ads (yuck!) or find some way to pay for it. How? I am sure there are ways but just something to be aware of…

    Maybe (at least on Android, maybe only for a small white list of high end devices) you can wait until the device is plugged in (charging) and on unmetered Wi-Fi before you do the heavy lifting.

    https://blog.shiftyjelly.com/2011/08/02/amazon-app-store-rotten-to-the-core/

Leave a Reply

Your email address will not be published. Required fields are marked *