What to consider when starting a new app development
Geolocation is not hard to implement on the phone generally. Although what the phone can give us is just the coordinates. When processing this information on the server, keep in mind that some reverse-geocoding might be necessary to implement. It is possible to do this using Google’s Maps API but obviously API requests will be metered and billed.
Something else to consider is whether the app should track a user’s location all the time or just when the app is running. Be aware that to track a user’s location all the time, you need a very good reason, otherwise the app might not be accepted by Apple’s Review.
Push Notifications are one of the main reasons an app gets developed nowadays. To do this for Android and iOS devices the process is not that straight forward neither on the app side nor on the server side.
For the App, in Android it is necessary to integrate Firebase in order to have FCM (Firebase Cloud Messaging) which is responsible for receiving the notifications in Android. That means that there must be the relative project created in the Firebase Console, a google-services.json file downloaded and added to the app and the dependencies added for it to work.
IOS is a bit better, provided that there is a developer account with the required access to Certificates & Profiles. There is no need to register your project into another platform (such as Firebase). Except for this, it is necessary to add the required code in AppDelegate.m or AppDelegate.swift where we listen for new notifications.
Note that notifications for both Android and iOS, don’t always end up to the notification center. They do so only when the app is closed or in background. If the application that received a new notification is in foreground, said notification will not be visible on the notification center. We should do that manually.
Once we set up Firebase for Android and enable the Push Notifications Capability on iOS, we need to ask the operating system for a unique identifier to which we can send the notifications. So there will be a token that somehow the system is going to generate which will identify our app on a certain device. We need to send this token to our server and associate that to the user.
The real fun is on the server-side implementation. We have two third-party integrations, i.e. Firebase and APNS (Apple Push Notification Service) to which we need to send different payloads so that they can forward the notification message to the device.
Instead of implementing these integrations ourselves, there are a few gateway options to consider. One is Firebase Admin SDK for which we need an API Key for our server to be able to call Google’s APIs. We need to get the key from console.cloud.google.com for the GCM API. Yep, it’s not the Firebase Console.
Another one is PubNub, which is not free and at some point, during development, the notifications where having a 3-hour delay to reach the device. Not yet been able to identify the bottleneck on that issue.
The last one worth mentioning is AWS’s SNS. Seems very reliable with the only drawback compared to Firebase that it is not free.
One thing to keep in mind is that every user eventually will send device tokens for push notifications to your server. Probably more than one if it will be reasonable for the user to log in from different devices. It is a good thing to send some time over how to manage deleted, inactive device tokens. Or even let the users delete devices themselves from the system.
Crash reports and User stats
Crash reports and user analytics are very important for maintaining the applications. Most companies will go for Firebase’s services for these two purposes. The reasons are very simple. Most companies are already using Google Analytics for their website, so having the mobile users in a Google Analytics account as well is not a bad idea. One other reason is that, if you have Push Notifications in Android, Firebase is already in your app. Not the case for iOS apps but it’s not that hard to integrate.
I would suggest Firebase Analytics for user statistics and Firebase Crashlytics for crash reports.
Don’t forget to add the dSYMs archive on Firebase for the iOS project. That is needed so that in the event of a crash, Firebase Crashlytics can indicate more or less the exception and the line of code causing it, as well as a little bit of stacktrace of the exception.
dSYMs can be found in iTunes Connect after you upload a build for your app. Be sure to enable the symbols in the build settings in XCode.
Native functionalities (BLE, Airdrop, Touch ID, Face ID, Fingerprint)
These functionalities mentioned in the title and more others available for both Android and iOS add more complexity to the whole development process.
Let’s take the biometric authentication to the app. The normal flow would be that the first time you open an application you are required to either sign up or login if you already have an account. Right after you access the logged-in area of the app, the app should generally ask in some nice fashion whether you want to activate Biometric Authentication or not. After activating it, you’ll also one to be in control of this setting, so on a settings menu you’d like to be able to deactivate it again.
Let’s say you killed the app and after some days you’re getting into the app again. Since Biometric Authentication was enabled, it will immediately ask you to use that method for getting into the app. What must be managed though is the case where Biometric Authentication is not functional in the device anymore, maybe because it was not correct for 10 times in a row.
The last thing to manage is a user logout from the app. Generally, a logout will send the user back to the login screen. And on a normal scenario, when the user gets to the login screen we are automatically prompting the Biometric Authentication process. Though in this case that’s not a good UX to ask the user login immediately after they logged out of the app. We would just want to put a button right below the password field saying: Log in using Touch ID? — which then would activate the Biometric Authentication process.
Authentication depends obviously on the server API implementation. The most common solutions are Cookie-based authentication, oAuth based or some token based.
Some companies might have different forms of authentication such as LDAP or use Amazon Cognito. Others might need the app to be accessible using social authentication methods, be that Google, Facebook, Instagram, LinkedIn or others.
That said, it means that we need to store some information in the app, in most cases, right after login. Those are a refresh token used to refresh the user session in the server and an access token which is the one that generally expires and needs refreshing.
Often this implies that a gobal app state needs to be created and also persisted. So Redux and Redux-Persist need to be integrated into the project. That adds a bit of complexity to the whole projects both in terms of design as well as readability of the source.
If the app uses RNN (react-native-navigation) instead of react-navigation [I suggest that configuration] then adding redux becomes yet a bit more complex.
TouchID, FaceID and Fingerprint authentication are other features that might be required in an app. More so for apps with sensitive information. Bank apps, Insurance and what not.
There are cross platform solutions that handle TouchID, FaceID and same features on Android all together.
Global App Styles
UI and UX is arguably the most important part of an app. Be sure to have the interface designed by a professional if you need the app to make a real impact on your users. UI and UX are too different things. UI is the definition of the look and feel of the application, most of the time it just reflects (maybe in a better way) the corporate identity, colors and styling. While UX covers transitions, navigation between screens, animations, reactions to user actions.
Just like in web development, it’s wise to have the styling uniform and centralized. In cross-platform frameworks it is common to have a css-like configuration file which can be then used for the visual components.
Although it is not always possible to have every style-related property in a global file.
Sometimes background services are needed for an app. Such services are used on different occasions. Perform a background task. Track geolocation in background mode. Listen to and enhance received push notifications, so on so forth.
There are some restrictions for background services. Especially on iOS. It’s not the easiest thing to add new extensions to your iOS app. While on Android the interface becomes normal after a while since it reflects an event-driven architecture. The idea behind it is sending and receiving Intents between the main thread and the background listeners/services. You only need to learn the API.
On iOS, on the other hand, in some cases you can add the background tasks in the app target while, as it is for push notification extensions, you add other targets to your solution. Be aware that when you bump your app’s version and/or your apps build number also the version [and/or build] of all your other targets must match.
On iOS background services have a limited life time on which they can operate. Mostly they are used to finish up tasks that started while the app was running and in foreground. Remember that the app will be terminated by the operating system if it has been for too long in background. Anyhow, either you terminate the app or the system because of inactivity for too long, the operating system will keep the background tasks for some time running until it terminates that as well. The time reserved for the background task will depend on the resources available and version of your system.
Note also that some normal lifecycle methods, such as:
- (void) applicationWillTerminate:(UIApplication *)application
will not be called if background services have been registered in your app.
Don’t forget about internationalization when planning for an app development. It will need its time. Not much for setting it up, because either native or cross-platform framework development offer simple ways to support i18n. However using it and making sure every label is translated will add a bit of effort for every app screen.
There might be unexpected issues with that too. For instance, one issue I had recently was using the phone locale (e.g. “en-GB”) to set it to the momentjs singleton that I was using inside the app. For some unknown reason the app was only crashing in production. But the issue was clear, momentjs locales were all lowercase so it was not able to load it as “en-GB” but wanted “en-gb”.
Every application nowadays needs internet connection to function properly. But what happens when data connection is lost? Since that is a possibility, it should be taken into account. Some time needs to be spent on making the app offline ready. That means the app should cache locally some data, enable navigation to a few offline views. Be able to present whatever was already saved locally and explain with a notice somehow that it is a limited view due to missing data/wifi connection.
Animations are obviously the icing on the cake. One library I suggest which makes everything easier is Lottie from AirBnb. It can be used on Android, iOS, Web, React-Native and whatever you want to use it on. This can be used to show small animated views in the app.
Other animations, integrated throughout the app can be implemented using native animation libraries for iOS and Android. Advanced and very helpful libraries are facebook/pop and Facebook Rebound for iOS and Android respectively.
Having animations in the app, say like SnapChat rather than like Instagram which is more static on that perspective, you need to take into account both a lot of time to be spent for designing the UX and a lot of time for implementation.
When starting with a new app, the mistake most of us make is thinking of it very superficially. A lot of features that we see on every app and consider to be integral part of the application are not weighted accordingly when planning an app development. It is clear that with the exclusion of one or two of the components outlined above, the rest is all mandatory in an app. And obviously the estimation depends on the framework/technology used, whether native or cross-platform, the number of screens and screen complexity.