This happens and it happens a lot, that the non-functional requirements are not explicitly stated for an app; BUT assumed implicitly. If we were to ignore these requirements, changing application becomes time consuming in build phase.

Hence the need for planning these upfront becomes imperative. Here are some of the considerations for architecting mobile applications:


  • Native vs Hybrid:If you have decent budget, go for a Native. Period. However, it’s not like Hybrid app frameworks like PhoneGap are not good. But, as name suggests this is a stopgap arrangement. It generally isn’t as fluid as native one. Hence generally lacks on the usability quotient. It works well for simple apps that doesn’t require any device interaction. If it is anything which requires features like push notifications, in-app purchase, fluid interface, etc, things starts getting unmaintainable with hybrid apps.


From data perspective, scalability can be most of the times achieved by just:

  • Having proper indexes in RDBMS.
  • Having read replicas of DB or sharding the DB.
  • Caching at application server end.

This works to a great extent. And would suffice majority of the applications. There could be some scenarios in which we would need to have horizontally scalable DB like mongoDB. This could be required when data can be really huge and social in nature. i.e. it grows exponentially if the app really picks up.

From application server perspective, things are much better. In today’s world, platforms like AWS opsworks allows to automatically spawn more servers based on the load. Only catch here is that user session data has to be serialized in cache (e.g. Memcached, Redis, etc) or in DB. This is because first request from mobile app could go to first application server. And second request can go to second application server. Hence we cannot have user session data stored in application server.

Mobile app coding could also contribute a lot to handle scalability. Mobile app can work towards caching the data and loading it again only when required. I term it as distributed cache. This also helps in making the application responsive, i.e. show data from cache and then check with server if data has changed since the cache was last constructed. If server exposes REST based web services, this can be easily achieved by implementing ‘If-Modified-Since’ HTTP specs.

Geo location is used to deliver content based on user’s location. Or to let other users know about location. It is very important to use Geo Location wisely so that device battery is not drained. Below is excerpt from Apple’s documentation:

  • If your iOS app must keep monitoring location even while it’s in the background, use the standard location service and specify the location value of the UIBackgroundModes key to continue running in the background and receiving location updates. Examples of apps that might need this type of location updating are fitness or turn-by-turn navigation apps.
  • If GPS-level accuracy isn’t critical for your app and you don’t need continuous tracking, use the significant-change location service.


  • Web Services and its documentation:

App would generally interact with server using web services. It is in general REST based web services playing with JSON/XML data.

Documenting these web services is very important for proper implementation and maintenance. We often follow the principle of ‘Document first. Code later’ for the web services. This is very important as mobile application developer is generally different from application server developer. Also web services document acts as input for white box tester to write test cases.
Below is the structure which we generally follow for documenting web services. This structure has weathered at least last twenty mobile applications which SourceFuse has developed.

Purpose: Will add the user
URL : /api/v1/user where v1 is the API version no.
HTTP Content Type : application/json
Authentication Mechanism : None as this service works for un-authenticated user
Sample Input :
“first_name”: “Manpreet”,
“last_name”: “Singh”,
“email*”: “”,
“password*”: “SourceFuse123”
Field with * are mandatory. ‘*’ is not part of field name

Sample Output :
“status”: {
“success”: true,
“message”: “User registered successfully!”
“token” : ”1f3870be274f6c49b3e31a0c6728957f”,
“userid”: “as9da09sda9s8da0d8a0s”

HTTP Codes returned:
200 → Success
400 → Bad Request OR Wrong Data
500 → Error in saving data or server error

Implementation Details:

Give some implementation details of the web services. This would act as guide for the service developer as well as caller.

  • Testing web services:

We generally white box test the application by testing its web services. This can be done by using SoapUI or any other Continuous Integration tool. Benefit of SoapUI is that its free version generally suffices all the test requirements. As the name doesn’t suggest, SoapUI supports testing of REST based web services. SoapUI allows us to make test cases, which internally calls web services with test data. Test data can be such that it is separate for each time the tests are run. End result is maintainability. QA team can run automated SoapUI each time the new server build is rolled out. Hence getting to know quickly if major broke.

  • Multi-version support:

Releasing new version of the app to market is always required. This could be because of bug fixes or enhancements. New version for bug fixes generally don’t break web service interface and hence existing users needn’t upgrade the app. But problem comes when web service interface requires change because of an enhancement. We can still solve this problem by having new version of web service interface. That is, new version of the app can connect to newer version of web service. And old app can still keep connecting to older version of web services. But beyond couple of versions of web service it would become unmanageable. Which means app should have mechanism right from first version to force upgrade the app when server cannot handle particular web service version. Also whenever new version of app is released, app should put informatory message on the home screen suggesting user to upgrade.

  • Terms of Service:

Terms of Service can change as the app evolves. Instead of fixing terms of services in app, it is always good to have terms of services external in a mobile friendly web page. Which means if user accesses terms of service from the app, it opens up web page for terms of service which always contains latest terms of service.


  • Analytics:

As more and more people use the app, it becomes important to capture the features used, demographics and properties associated with the usage. This becomes important for analysing feature usage and hence making decisions on future enhancements. There are many good analytic platforms for mobile, e.g. Google Analytics, MixPanel, etc.

  • Crash Handling

If the app crashes too frequently, people generally stop using the app or uninstall the app. Result is same in both cases. To avoid people leaving the app because of crashes, it is important that we test the app in all possible scenarios and devices. But for all practical purposes, it is still possible that app crashes in complex scenarios or for devices on which flow wasn’t tested. To avoid such scenarios, it is important that we capture crashes and analyze those and eventually fix. We have used crashlytics in most of the apps released in the recent past. It helps us capture crashes and find pattern around it. Which means we can target the most prevalent crashes first.


  • Support:

In case user faces any issue, getting into a dialogue is very important for the success of app. App should provide a support function in the app. Using this function, user can tell the app developer about the issue he/she is facing.

  • Push Notifications:

It has become frequently used mechanism to engage user as well as keep him/her up to date. While implementing push notifications it is important to keep following things in mind:

  • Every mobile platform has limit on the amount of data that can be sent over push notifications. It is important that data sent over push notifications is spec’d out to avoid scenarios when the push notifications don’t reach because of data limit exceeded.
  • Many-a-times push notifications are sent in a batch job. It should be kept in mind to make connection to APNS/GCM only once so that notifications are also sent in batch. This is important for performance reasons.
  • Excess push notifications can irritate users. It should be left to user to decide on the scenarios in which push notification should be sent to him/her.
  • User can anytime switch off the notifications for an app. So it is important that app doesn’t rely on push notifications for functionality.


  • Permissions required by app:

This problem generally happens on Android. I go to play store to install the app and app asks for permissions which it shouldn’t require. E.g. why a social app would require to know my other running apps, why a ticket booking app needs access to my photo gallery, etc. This is very important to only ask for permissions which are required. Otherwise it might act as inertia for users who are conscious about permissions.

  • Web Services security:

Till the time web services are called only by app UI, system is secure. But hackers are motivated enough to go a step ahead and technically extract the list of web services used by any popular app. That’s when they can directly access web services. If web service is not built to work only for authenticated and authorized users, app is lined up for bad publicity. Which means that even if service user has been authenticated, still that user should be allowed to access data he/she is authorized for. This is very important to test it using negative test cases as part of SoapUI test suite. Similarly server framework should be configured to avoid SQL Injection, brute force and DoS attacks.

And needless to mention that web services should be behind SSL.

  • In App Purchase security

In app purchase is pretty much well documented by the mobile platforms. Most of the times purchase is done in mobile app. But fulfilled at server end. Which means that in general flow is that mobile app finishes in-app purchase and makes web service call to fulfill the purchase. And tendency is to just fulfill the purchase at server end. This could lead to you losing revenue. To avoid this, server should first programmatically validate with Google or Apple that purchase really happened and then only fulfill the request.
While we are on this topic, there is another point worth mentioning for In App Purchase. Common mistake which developers do is to not allow restore of in-app purchase. This leads to rejection of the app at least with Apple. It comes handy when user switches phone. And we don’t want them to spend again on the item which they have already purchased.
In a nutshell, mobile app development also requires decent time to be spent upfront i.e. design/architecture phase. Small screen doesn’t mean less effort. 🙂

Manpreet – Leads the Technology Frat Pack at SourceFuse. He eats, breathes and lives tech; technology old or new – they do not rattle him and he likes to keep his ’being Zen’ like by practicing yoga and cycling.