Table of Contents
The App Development Iceberg
Have you ever tried building a mobile app?
Whether you’re using Flutter, React Native, Unity or Unreal Engine for mobile games, Android Studio, Xcode, Cordova, or .NET, it doesn?t matter. They all come with a common set of challenges specific to mobile platforms that you’ve probably already faced.
Developing mobile apps is like an iceberg. The part you see, writing the source code with one of the mentioned technologies, is just the tip.
But what are the hidden difficulties lurking below the surface in mobile development? Why do app launches get delayed even after the code is complete? Are the world’s elites conspiring to stop you from finishing your soundboard app in Android Studio?
I?m Carlos Sala, a software developer, and this is the mobile app development hell.
The Dependencies: the House of Cards
Every day, the tools we use to create mobile apps become more powerful. This means we can build more complex apps with less knowledge and effort.
Teams behind Flutter, React Native, and other frameworks develop APIs with reusable features for people like you and me to use in our apps. But did you know that these frameworks rely on many other libraries written by other developers?
The Fragility of Dependencies
When the dependencies we use in our projects also have their own dependencies, the chances of something going wrong increase exponentially.
We can visually represent the chain of dependencies in our app as a house of cards, where each card is a code library and each level depends on all the ones below it to function correctly.
For example, if we use React Native and Expo to build our app, which is my favorite stack, the levels of the dependency house of cards look like this:
- At the top level of the house is the source code of our project. This includes all the code we write in React Native: components, styles, HTTP requests, state management, and any native modules we’ve created.
- One level down, we find the code for all the dependencies we install in our project, such as React Native, Expo, or libraries from Google like AdMob for ads or Firebase for cloud features without needing to build a backend.
- Finally, the base of the house of cards is made up of the dependencies of the previous level. This includes all the libraries that the dependencies we installed rely on.
If this seems complicated, I?m sorry to tell you that this three-level example is just a simplified version of the actual dependency structure of an app. Because, who said that the dependencies of the dependencies can’t have dependencies?
Native Operating System Dependencies
Everything we’ve said so far is true, but we’ve overlooked that developing a mobile app means building both Android and iOS versions.
Each development kit or SDK for these operating systems is itself a house of cards like the one we’ve described. So, beneath our app, there are not only more levels of dependencies, but actually two different houses of cards: one for Android and one for iOS.
The hierarchy of dependencies at the operating system level would be, broadly speaking:
- At the top level, which serves as the base of our app’s house of cards, is the development framework we’re using.
- Right below that, we have the operating system APIs, the Android and iOS SDKs that handle things like displaying splash screens, sending notifications, opening other apps, etc.
- At the base of this house of cards are the native programming languages and their libraries for each operating system. This means Java for Android and Swift for iOS.
When you put it all together, you can see the monstrous web of dependencies required for our app to work.
If you use another framework, you might have even more levels of dependencies. Or, if you work directly in Java and Swift with the OS SDKs, you can eliminate the first three levels of the house of cards.
In any case, ensuring that the code at every level works correctly and is compatible, knowing that each library was written by a different programmer, is about as close to a miracle as you’ll ever see.
So, don’t be surprised when, after coding your app, you try to compile it and run into one of those infamous Android or iOS compilation errors. And let me tell you, this won’t just happen once.
Testing Mobile Applications
After dozens of attempts, tweaking different library versions, the stadium falls silent and the ball hits the back of the net: the app compiles without errors.
At this point, while we can briefly celebrate having a first version ready, there’s still a long way to go before we can launch our app. The next step is to ensure everything works as we programmed it.
Why Is Testing a Mobile App so Challenging?
In web development, testing the site on just our computer and declaring it functional is a risky move. But when developing for mobile, not testing our compiled app on both Android and iOS, across different OS versions and as many devices as possible, is a guaranteed disaster.
During app development, when you need to test some code, you’ll be tempted to use an emulator on your computer to avoid the hassle of connecting both an Android and an iOS device. You might also want to only test the development version to save time on compilation.
If you take these shortcuts, you should know that some libraries with native mobile APIs have code forks to use mocks when the app isn’t running on a real device or is in development mode.
Therefore, the only way to ensure the code will work correctly in the version we upload to the app stores is to test it on real devices. And logically, on both Android and iOS, because the native code underlying our app differs for each operating system.
How Many Devices Should I Test My App On?
Don’t make the mistake of thinking that just because your app passes tests on your devices, you can guarantee it will be error-free.
Every mobile device runs a specific version of its operating system. This version acts as a dependency for our app, meaning it might work perfectly on iOS 17 but fail on iOS 15. Additionally, depending on the minimum version you’ve set for your app, there might be devices where you can’t even install it.
To add to the complexity, each mobile device or tablet has different screen characteristics, such as aspect ratios or whether they have a notch. Therefore, you need to ensure your interface adapts to various screen sizes and remains user-friendly.
You might be wondering how you can possibly test your app on all existing devices. The answer is, you can’t. But at the very least, aim to install it on the two most recent versions of Android and iOS, and test it on both a phone and a tablet. This will help you catch the most likely errors.
Distribution: Upload the App to the Application Stores
Let’s recap. We’ve developed the app using our favorite framework, compiled a first production version, and tested it on several Android and iOS devices. Are we done yet?
Well, my friend, I’m sorry to tell you that there’s still one more step: uploading it to the app stores. And, unsurprisingly, this is also a nightmare.
The App Listing
Uploading an app to Google Play or the App Store involves more bureaucracy and marketing than programming.
If you don?t already have a developer account on Google Play and the App Store, you?ll need to create one and pay the respective fees: a one-time payment of $25 for Google Play and $100 per year for the App Store.
Once you?ve paid, you can create the listing for your app on each store and start filling in all the mandatory information:
- App Title: Maximum of thirty characters.
- Short Description: Brief but catchy.
- Full Description: Detailed explanation of all the app’s features.
- Icon: An inviting icon that encourages users to download and use your app.
- Screenshots: Screenshots of various app views. This is relatively easy on Android but especially painful on iOS, as you need to upload different screenshots for each aspect ratio of Apple devices. This means opening Xcode, installing emulators for each device size, and taking screenshots.
Additionally, you?ll need to fill in the text fields and upload screenshots for each language you support in your app listing. If you want to set a price for your app, you?ll have to configure the price for each country and complete your business?s tax information.
So, all things considered, and being optimistic, it will take at least two days to set up developer accounts and create app listings that are decent enough to attract downloads.
App Review Process
Of course, the button to submit your app for review will still be disabled.
You still need to fill out questionnaires about the app’s content for classification and request the necessary permissions from users, such as location access or data collection.
Once this is done, you can finally submit the first version of your app for review.
Historically, the App Store review process was known for being more stringent and lengthy, as Apple employees manually reviewed apps, while Google Play’s process was automated. However, nowadays, both processes are manual, and Google Play’s review often takes longer. So, now you have to wait about a week for a response.
After a long week of waiting, you?ll receive a slap in the face heard from miles away: your app has been rejected.
If this is your first time uploading an app to the stores, you?ll be relieved to know that we?ve all been there. The review process is meticulous because thousands of new apps are submitted daily, and they have to filter out as many as they can. You?ll receive a detailed email outlining what needs to be modified or the reason for the rejection, but the most common issue is requesting a permission from the user that you didn’t mark in the app content form.
Once you’ve made the necessary changes, no matter how minor, guess what: you?ll need to compile a new version of your app, upload it to the app stores, resubmit it for review, and wait another week.
You?ll be stuck in this time loop until, after weeks or months, you finally receive the email confirming that your app has been accepted and is now available to the public.
And now, good luck trying to attract users for the app or game you?ve created.
The Competitiveness of the Mobile Application Market
Remember the intensive tests we talked about or the app store listings you need to fill out to upload your app? Obviously, they had a purpose: to develop a product that’s as appealing as possible so people want to use it.
There’s nothing worse for a programmer than putting effort into a project only to have nobody use it. And this is all too common in mobile development.
With so many apps in the stores, most of them remain buried in search results, unnoticed by users. Whether it’s a game or an app, it’s crucial to have a plan to rise above the competition and attract traffic to your application. This could involve ranking in search results for popular keywords, paying for advertising campaigns, or leveraging social media.
One thing is clear: you won’t magically get a million downloads. You’ll have to compete with thousands of developers who may have more experience than you, so I hope you enjoy tough challenges.
Is it Worth Developing Mobile Applications?
If you ask me whether it’s worth developing mobile applications, I’d say yes, absolutely. In fact, it’s my favorite platform for developing games in Unity or utility apps with React Native, because, let’s face it, who doesn’t have their phone glued to their hand all day nowadays?
The journey from starting to program the app to finally getting it published is riddled with challenges and can be quite frustrating. So, when you’re planning the project, keep in mind all the time outside of programming that you’ll need to troubleshoot issues, compile the app, conduct tests, and handle the app’s marketing.
On the other hand, competition is fierce, but honestly, I can’t think of any business area that isn’t saturated these days. If you conduct thorough market research and develop and promote a quality product to the right audience, you can carve out your piece of the pie.
What other pains have you experienced while developing your app? Did I forget any important points?
Once again, I’m Carlos Sala, software developer, and see you soon!
