Building for Mobile — Issue #1
Tags: mobile
Published: 2024-02-17 17:02:59

---
title: Building for Mobile — Issue #1
published: true
description: Crafting native apps for mobile devices comes with distinct advantages and a plethora of challenges. Throughout this series, drawing from my experience in mobile app development, I aim to shed light on effective strategies for overcoming these challenges and taking advantage of said benefits.

tags: mobile
# cover_image: https://direct_url_to_image.jpg
# Use a ratio of 100:42 for best results.
# published_at: 2024-02-17 02:15 +0000
---

Crafting native apps for mobile devices comes with distinct advantages and a myriad of challenges. Throughout this series, drawing from my extensive experience in mobile app development, I aim to shed light on effective strategies for overcoming these challenges and unlocking the full spectrum of benefits.


### (En)force mobile app updates

In contrast to web applications, which rely on cache policies or seamless deployment for updates, mobile apps require manual updates (with the exception of certain frameworks like React Native that support over-the-air updates). This means that when an update becomes available, users must initiate the update process themselves. Unfortunately, this approach places the responsibility on users, leading to challenges in promptly addressing bugs and deploying new features for the majority of users.

Implementing a policy of enforcing app updates involves coding or utilizing existing libraries to verify whether the user’s current app version falls within the supported or non-deprecated threshold. If the version is outdated, users are restricted from accessing the app until they have completed the necessary update. This strategy ensures a more uniform and timely distribution of bug fixes and feature enhancements across the user base.
![Google Stadia Update notice](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/45ipuacai4yrradkng10.jpg)


### Extend timeouts and add retrials
Networks can be unpredictable, unreliable or non-compliant with API response SLAs. To mitigate these issues, extending the connect, read, and write timeouts is a crucial step. By allowing more time for these operations, the system gains flexibility in dealing with variations in network behavior.

In addition to adjusting timeouts, incorporating retries after failed requests is an essential tool in the strategy to tackle network-related challenges. Retrying failed requests provides an opportunity for the system to recover from temporary disruptions and improves the overall robustness of the application in the face of network uncertainties.



### Always Verify internet access
To perform an HTTP request, we need internet or intranet access. Depending on your current setup, verifying if the user has internet access and informing them accordingly can help debug the issues or inform the user as to why the operation was not performed, and not having internet does not always mean not having access to a functioning network;, sometimes it might mean that the DNS server is not working. So when testing for internet access, do not only use the API, since this will only inform you if the user is connected to a network, but does not guarantee internet access. To do this verification, you can attempt to make an HTTP request or a DNS check; these should guarantee whether the user has internet access or not.



### Use serif fonts for password fields
This is where we replay the capital I and lowecase l, which depending on the font are barely distinguishable, along with other characters and variations, in my experience serif fonts create a noticable visual diference aiding in improved legibility.


![Font types](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y6d8hco3qe6x56dfq8vw.png)