Creating a Mobile SDK can be challenging for Web developers
Here at Helppier, we had the challenge to develop Helppier Mobile and we are excited to share our development process and some challenging points that we found during this process.
The whole mobile development process is also distinct from web development. For example, deployment is not made in the same way (in mobile development deployment is made in the app stores and goes through a very specific process). Moreover, many concepts are also different, for instance, a screen or page in Android is called an Activity (and this has a different lifecycle) and in iOS it is called a ViewController. Also, the lifecycle of an Activity or a ViewController are very different.
So switching from a web development perspective to a mobile development one has a steep learning curve. Considering also that we are not developing a traditional application or even a conventional SDK makes it a harder task to tackle.
Our SDK has three target user profiles:
- Admin: User that creates the content (usually someone in the marketing, product management, or customer support areas), maintains it, and checks its impact (the analytics side).
- Developer: User that installs our SDK in their application.
- End-user: User that will see the content created by the admin user.
For each one of these profiles, we must investigate different journeys, for instance:
- Admin users: would it be better for he/she to create everything on the device itself (like what we do currently with our web version), do it on a backofffice with a web builder and then sync the content with the mobile app or something in between by plugging the device with the computer?
- Developer: At which stage will the developer need to install the SDK? What configurations are required? The main goal is to allow them to just add the SDK and forgot about it in a way that if new content created by the admin user or do they need to target a specify set of end users, a particular screen or app version? Ideally the developer doesn’t need to do anything more than install the SDK and set it up (no need to make any changes to the code and deploy a new version).
- End-user: No need to install any extra software to see the content.
Furthermore, one user journey will affect the others, for instance, the way the developer install the SDK is impacted by the way we will allow the admin to create the content.
All the options presented above bring challenges that need solutions, but even though they all might have a technical feasible solution, it can be one that can make the user journey too hard to achieve or that simply doing it has no or low commercial value.
First, we identified the main technical challenges for the use cases that we have:
- What is the best user journey for our users (admin, developer, end-user)?
- What are the main types of content that we need to add?
- How to inject our code into mobile applications?
- How to ensure we have the best performance?
- How to detect/target pages & elements?
- How to ensure that our content works well on all devices and operating systems?
- How to target users?
- How to position our content?
- What are the events that we need to collect and how to do it?
- Do to we ensure a smooth experience with our tool?
After listing them, we chose a couple of these challenges at each time and started to investigate on how to deal with them, exploring different solutions. An ongoing process to deliver the best experience to our users.
We are happy to keep sharing our development process with our blog readers. Stay tuned to our next articles where we will share some of the solutions to the challenges mentioned in this article and will explore and explain them in more detail.