“This should be easy,” you say, as you embark to take your solutions from web to mobile. The work begins, and you’re proven right! “My team is awesome!” you exclaim, puffing out your chest.
And then the bottom starts to fall out.
That’s because scale in a mobile application comes with nuances that don’t exist on the web. Suddenly, the last 10% of your project leaves your team running a 10K in quicksand.
Instead of falling into the quicksand, you want to avoid it entirely, right? So let’s discuss some of the stickiest pain points and, more importantly, how to avoid them.
1. App distribution
Websites are straightforward — when you publish content, it’s instantly available, and when you take down content, it’s no longer available.
Mobile apps don’t work that way, though because they have a completely different distribution model — one that’s controlled by your distribution channels, Apple and Google. In addition to keeping your code up to date, you must make sure you meet all the requirements from Google/Apple.
While keeping Apple and Google happy is important, it can’t be the end-all-be-all for your distribution strategy.
Automation is a must-have. Manual uploading is outdated and error prone, so use a CICD tool that automates the build and upload processes. Whether you piece together several technologies or use a tool like Bitrise to automate the mobile CICD flow is up to you, but either will lead to a better experience for your team and your customers.
But remember, even with the smoothest automation, the app stores are still the gatekeepers. Think about common bottlenecks in the review process ahead of time — like accidentally having a regulatory issue or a vulnerability — and have a plan in place to deal with any feedback as quickly as possible.
2. Version control
Like we said, websites are straightforward; what you see is what you get. Mobile apps? They’re like onions. They have layers! Version control is a problem because people are installing compiled code onto their devices, so there could be any number of versions in use. Spoiler alert: the app stores have no desire to manage this for you, so you have to manage it yourself!
Here’s an example that illustrates how to do it:
You published version 2.0 of your app in January. In March, you published a new version to meet all the OWASP requirements and find two major vulnerabilities that were present in v2.0 that need to be addressed. So, you published v2.1 with those fixes, but v2.0 is still in the wild because there’s no option in the app stores to not allow specific versions to run on people’s devices.
Want an easy fix? Make your app call a specific API at startup that gives you two values:
- Minimum App Version
- Current App Version
From these two values, you can determine:
<ul>
<li>Is this app lower than the Minimum App Version?
<ul>
<li>If yes, have a dialogue box that only allows the user to go to the app store listing to upgrade but not proceed into the app.</li>
<li>If no, do nothing.</li>
</ul>
</li>
<li>Is this app higher than the Minimum App Version but lower than the Current App Version?
<ul>
<li>If yes, have a dialogue box that allows the user to go to the app store listing to upgrade OR proceed into the app.</li>
<li>If no, do nothing.</li>
</ul>
</li>
</ul>
Just like that, you can control if a user is using an appropriate version of your app and ensure your app and your customer are protected from unsafe or unsupported code.
3. Integrations/SDKs
Using integrations/SDKs affects your scalability. To dive deeper, we’ll break this down into two varieties: third party and internal integrations/SDKs.
When you’re sending code into the wild, you’ve got to be aware of how the version control of your third-party integrations/SDKs will affect the lifecycle of your app and that specific functionality.
For instance, if you’re working with a vendor and they don’t have backwards compatibility in their integrations, or if they publish a new API that replaces an existing API while not making them both available, they could break your app with their own deployment. When you partner with a third party, understand what their version control looks like and make sure you can support it from your end.
This isn’t an issue on web apps because you can time the release of a new API to align with a new front end, but there’s no way to sync those deployments on mobile apps. Why? Because you don’t own your distribution method! (Yes, there are options to work around this, but they’re expensive and they don’t provide any value to your customer. So skip ‘em.)
Another question to ask yourself: How will you consume the latest versions of your third-party integrations/SDKs? Let’s say they’re on a two-week deploy cadence, but you only update your app once a quarter. How do you decide which version to use? Or if you release every two weeks and they only release once a quarter, what happens if you release their new version and there’s an unacceptable bug found in production? These are all questions you need answers to on day one.
Remember, the code quality of third-party integrations/SDKs reflects on your brand. So do solid regression testing once you’ve integrated. Also, account for the long trail of maintenance that comes with them. It may only cost you $X to integrate it, but it’ll continue to cost you $Y every year as you make updates.
Your partner will say it’s really easy and will take you no time to update these integrations/SDK’s so you don’t need to worry. They’re very well-intentioned in saying that, but as you’ve learned, it’s never as easy as it sounds.
What about internal integrations/SDKs? The fun part is that everything above also applies here. But there are additional opportunities as well.
First, because everything is internal, you can use a common platform, which is critical for enterprises that need to leverage work from multiple business units to create a cohesive application. It’s just like building a Lego – everything snaps together perfectly.
Not working off the same base application is like stepping on a Lego – ridiculously painful. You’re creating all the rework that comes from working with a vendor, but without the benefit of having them be responsible for the code.
There you have it. Everything happens in threes, including mobile app scaling advice. Take this trio of insights, bring them back to your team, and running through quicksand will become a distant, squishy memory.
