I’ll admit it. I’ve gotten bitten by a dramatically under-estimated mobile app development project. And this was after over 30 years of experience shipping commercial software. You’d think I’d know better by now. The optimistic side of me fought–and won–with the battle-hardened “it’s not going to be as easy as you think” side of me.
It wasn’t that the team and I grossly under-estimated the scope. We included consideration for all kinds of things that might come up. There were simply some things we didn’t anticipate, or under-appreciated.
This article touches on some of the lessons learned, in the hope you’ll have all the bases covered when you estimate your next app development project. Download our Software Development Estimate Template now to see what one looks like and follow along.
1. The days of writing for one platform are over
It used to be easy. “We’ll ship for iOS first, get some traction, then deal with Android.” A friend of mine recently shipped his iOS-only app and was inundated with “I love your app! Where’s the Android version?”
In his world, iPhones dominate. In the real world, they don’t.
US Smartphone Share as of December 2014:
- Android: 53.1%
- iOS: 41.6%
Worldwide it’s not even a contest; Android completely dominates at over 80%, according to International Data Corporation.
Unless you want to alienate half your user base, you need to ship on both platforms on day one.
So what’s the impact? First, you need to select a cross-platform development tool. You don’t want to write two sets of code. That will definitely lead to an over-budget project. Instead select a tool that lets you share code across platforms.
There are several on the market. We’ve selected Xamarin because it lets us write production-quality code and automated unit tests, and it compiles natively on multiple platforms.
The second impact is testing. You’ll immediately double the testing required because you need to test on both platforms. We write unit tests against the shared code base, so we get most coverage that way. However, we still need to run and use the app on each platform because platform-specific visual tweaks are always required, even when sharing most of the code.
2. Offline sync is an expected feature
We’d love to believe that the user will “always have an Internet connection,” but there are many examples where Internet isn’t available.
- Hotel meeting rooms
- Rural areas
- Underground in the subway
- On an airplane, if you decided not to pay for in-flight service or–*gasp*–your particular flight doesn’t have Internet service or it’s not working
Users don’t want to see, “Try again when you have an Internet connection.” They expect to use the app regardless of their connection status.
Offline sync can be tricky, especially if you need to support two-way sync. That is, sending changes from the device to the cloud as well as downloading changes from other users.
3. Screen sizes and densities need to be addressed
Even if mobile devices have the same screen size, your app may look completely different based on the screen density. That is, how many pixels are displayed on the screen. Ever compare a 5 year old laptop screen to a brand-new laptop screen? You’ll probably notice that everything on the new laptop screen is a bit smaller, and therefore more fits on the display. The new laptop has a higher screen density than the old laptop. You face the same challenge with your mobile app.
For some additional details, see Support different pixel densities in the Android Developers Guide.
Luckily, both iOS and Android provide ways to deal with this, helping you ensure the app looks and feels the same way across multiple devices, but you still need to test. Testing takes time, and addressing inevitable minor adjustments takes time as well.
4. Rotating the screen can cause layout challenges
On one project we were 20% of the way through when someone rotated the device from portrait to landscape for the first time.
Oops.
iOS and Android try to help you out, automatically scaling and adjusting widths of various on-screen visual elements, but sometimes “the stuff doesn’t fit when you look at it the other way.”
Users will complain if you lock them down to one orientation unless absolutely necessary. Many games, for example, force you to play in landscape mode. This doesn’t fly for most business apps, however.
Once again, there’s a testing impact and minor adjustments along the way.
5. Push notifications can be a challenge
Push notifications are a fantastic feature, and they seem pretty simple, right? We just show a short message on the screen. Tons of apps have push notifications. How hard can it be?
The first challenge is Apple and Google have two completely separate push notification infrastructures. And guess what happens if you don’t use Apple’s push notification service for your app? Yep, that’s right. It will be rejected.
From the App Store Review Guidelines:
5.1 Apps that provide Push Notifications without using the Apple Push Notification (APN) API will be rejected
You’ll be using APN for your iOS app and the Google service for your Android app. Luckily there are services out there that make it easy for you, permitting you to add one web service call to send notifications via both infrastructures. We use Parse for this, and it’s worked like a champ.
Oh, and don’t forget you’ll need to test!
6. TestFlight only supports iOS 8 and later
TestFlight, Apple’s tool to allow pre-release testing of your app on iOS devices without publishing to the App Store, is fantastic!. It used to be that every test device needed to be registered before you could install a test version, and you were limited to 100 testers. TestFlight now eliminates the registration requirement and allows testing for up to 1,000 users on multiple devices for up to 30 days!
There’s only one catch – it can only be installed on iOS 8 and later, which is only supported on the iPhone 4s and later.
It’s likely that at least some of your testers will not be on iOS 8, so you have a dilemma. You either need to leave out those testers, or you’ll need to also use a tool such as HockeyApp to distribute to the pre-iOS 8 folks.
This introduces more work and more things to manage and, like everything else in this article, will cost you time.
7. Crash reporting is a must
Although we’d like to believe we’re perfect, we occasionally miss a bug that causes the app to crash. Given the transient nature of app usage, it’s seldom the case that users will reach out to you if your app crashes. Likely they’ll just re-launch it and forget all about it. The problem is you can’t fix something you don’t know about.
There are many tools that allow you to add a few lines of code that will allow your app to automatically report a crash via the cloud. You’ll receive a notification and debugging information to track down the issue. We use Raygun as our tool of choice, and love it.
Is this a big impact in terms of time? No, but it’s one more thing to manage and maintain. Don’t forget to include it in your list when estimating.
8. The Apple App Store release process takes time
Many of you have probably heard stories of the dreaded App Store Review. After slaving away on creating your app, you hand it over to the Apple App Review Team and…you wait.
And continue to wait.
You double-check to make sure you did in fact click the Submit for Review button.
You check the Average App Store Review Times daily, sometimes multiple times per day, wondering if you’ll be the lucky one who beats the odds and has a quick turn-around.
And finally it’s been approved (I’m being optimistic here…sometime’s it’s rejected).
Then two days later you find a critical bug you somehow missed through all the pre-release testing.
And you start the cycle again.
The app review process isn’t rocket science, but there are a lot of moving parts. There’s an App ID to create, a Provisioning Profile (including special configuration for Push Notifications if you’re using them!), meta data to complete, screen shots to capture (each in four different sizes just for the iPhone), and pre-release testers to manage.
The biggest challenge is the cycle time. You need to plan ahead for any time-sensitive events, such as a trade show or other sales event, and you can’t quickly release a new version.
Side note — the Android process is a night-and-day difference. You can post an app in about 20 minutes, and update it any time you want. There is a delay for Google’s servers to refresh your app, but that’s measured in hours, not days or weeks.
9. You’ll probably need a cloud infrastructure
Building a mobile app is just about building the app, right? In many cases, it’s not quite that simple. A cloud server is oftentimes required to provide an infrastructure for the app. You’ll need a cloud infrastructure for things such as:
- Sharing data between multiple devices
- Managing user accounts via a web site
- Providing both a web and mobile app interface
- Background tasks such as sending reminders to users
- Facilitating communication between users
There are several mobile back-end as a service (MBaaS) companies that will save you some time, such as Parse, or you can build the back end yourself if you need more power and flexibility.
Regardless of which approach you choose, you certainly don’t want to leave this part out of your estimate.
10. Device inconsistencies need to be dealt with
Apple has the edge here, with only a handful of devices on which your app can be run. Android is a different story, with close to 7,000 devices that might run your app.
Luckily you don’t need to run out and buy hundreds of different Android devices. You can use products such as Xamarin Test Cloud to run your app on 1,000 of the most popular devices.
You won’t find everything, and you’ll get feedback from customers with bugs on certain devices, but you’ll be able to catch a lot of issues before they get into your customers’ hands.
Conclusion
Mobile app projects are a ton of fun and it’s a fantastic feeling when you see your app running on your customers’ phones and tablets, but there are a lot of little things that need to be addressed to create and ship a high-quality app.
Remember to include time for the “gotchas” and you’ll avoid getting caught in the trap of under-estimating the level of effort required to complete your project.
Have you run into other challenges that you didn’t anticipate? Leave a comment and tell me about it!
If you’d like help with a mobile app development project, please feel free to reach out.
