As the number of variations to be produced kept growing, we pushed a concept called app templating that lets us release multiple native apps based on a same core codebase in a cost- & time-effective manner, while keeping a good flexibility.
There are many ways to realising app templates and we analysed multiple ones. We opted for a solution based on the tools Apple and Google provide for two reasons:
- Native development lets us achieve high quality apps
- We are more than familiar with these tools
This choice seems thus relevant and natural.
How to design an app template? And take advantage of it? Let us admit you are a customer who wishes to achieve several variations of the same app in the rest of the blog post.
App template concept
App template design and implementation depend on your needs. An app template can be very simple and consist in a single core app embedding different contents and features for each app. It can also be much more sophisticated and flexible.
Let us analyse the main adjustment factors for your project.
If you are thinking of making an app template, you probably have a set of features shared by your various apps, maybe some extras. These extras can guide the design of your app and its architecture.
For CANAL+ group apps, we chose a “hamburger” menu to keep a fair flexibility according to the number of available features for each variation.
Besides, all these features rarely exist separately, but they rather interlace. For example in a public transport app, it is appropriate to go from a timetable to route search or traffic information. Keep in mind also that all the features may not be available in some cities.
This is why an app template has to be thought very modular: customisable parts, best and worse cases should be figured out through the conception phase. Diving into details in the design process ensures the app template will not end up producing clunky apps.
The appearance of your apps plays a big role in the liking of them and your brand identification. Since an app template seeks to mutualise developments, the overall look of your apps will not differ without specific developments, which should be anticipated.
It does not imply that every variation will be graphically identical. Indeed, pictograms and colours are easy to change and bear a significant part of the identity of an app. It is thus possible to get similar apps to create a universe and codes peculiar to a brand while having a unique identity for each of them.
The app format (compiled software installed on devices) introduces inertia and fragmentation, compared to the web. Indeed, the user has to install an update to get the latest version and several versions may coexist. Thus, content (e.g. URLs, images, wording and other data) control requires analysis during the conception phase:
- Hardcoded in the app? It requires no communication with a server but an update is necessary to modify anything and may not be installed by the users, which leads to software fragmentation.
- Fetched on a server? Content will always be up to date, after a loading time. Besides, complex operations are then done server-side instead of being done on the smartphone. However, it implies more work to prevent limited connectivity cases.
Both approaches have their advantages and drawbacks but they are not incompatible.
What comes next?
After conceiving and implementing an app template, you wish now to operate it and prepare the follow-up. Let us analyse ways to make most of this tool.
Once the initialisation phase of the app template is over, comes the time to create apps.
According to the level of customisability proposed, a huge number of parameters may be available thus increasing the risk of handling mistakes. To limit them, one may abstract the technical complexity of apps deployment with an interface which role is to automate as much actions as possible: with a little bit of imagination (and a few scripts) we can implement a form which enables managing an app configuration, its compilation and deployment on a download platform.
This allows splitting the tasks in two parts:
- a technical team in charge of improving the app template and incorporating new features.
- a non-technical team dedicated to the operation part taking care of tests, publication and users feedback.
By splitting the tasks in two, one enables a better focus of the teams. It also lets a team work on the product’s evolutions while the other one prepares the publication or the operation of the apps.
An app template provides a framework that allows the addition of new features, because of its modularity. Bad surprises being generally put aside since the conception, one ensures a good integration of new features in the apps.
It also allows delivering improvements and bug fixes on several apps. Thus, you may test modifications on a single app and then release them all: benefit from the accumulated experience on each app and mitigate the risks.
Since this framework mutualises continuous improvement efforts, the related apps are extremely reliable. This is especially important since users have low tolerance to crashes.
Moreover, this approach significantly minimises time to market for a variation, as one just need to configure the new app and test it to get it ready. Therefore, the initial investment is not only quickly recovered but also improves reactivity for apps replication.
In short, an app template makes several apps profit from evolutions or improvements with a mutualised development and also enables you to release apps in record time and cost.
Conception phase is necessarily longer than a single app project. Indeed, the former requires more time to make the right choices with regard to all the target apps. Another consequence of the app template format is that desired modularity also needs more development efforts. However, this time is then amortised depending on the number of variations.
Furthermore, we identified steps requiring extra care during the conception phase, after designing and implementing several app templates. Here are the lessons we drew from our experiences:
- Functional and graphic specificities should be thoroughly explored well in advance of developments. Afterwards, specific integrations can be sources of complications.
- These specificities should only rely on a configuration which can besides be hard coded or dynamic, just like content.
- APIs should be consistent across all apps. Each particular case can induce complication in the model, more tests and thus more potential bugs.
To sum up, major technical differences bring with them complexity one can do without. For all that, they do not prevent reaching a very satisfying level of customisation.
Part of a long-term Product vision, an app template lets you release many native apps and ensures their scalability. This approach also helps mitigating bugs and crashes which are unavoidable in the life of software, by benefiting from the accumulated experience and by giving excellent publication reactivity for multiple apps.
To finish up, not all projects are very suitable for the app template format. A minimum of similarities between the variations is necessary for the initial investment to be worth it. Here are a few reminders on the main elements you should keep in mind:
- What is the set of shared features? What is the ratio between the necessary and the optional ones?
- Can version specific UIs be close enough to be mutualised?
- Are contents of the same kind?
- May the logic layer be the same?
Mobile apps are the privileged channel in customer relationship and must therefore be on the cutting edge. In this context, it is necessary to consider the mobile apps industrialisation challenges. The app templating meets this need while fostering the establishment of an overall Product approach.
Did you enjoy this blogpost? Do you have any suggestions?Contact us