This is why most mobile development projects fail

You just signed a new client.

You are excited to work on this new project. It’s technically challenging and financially fulfilling. You’re going to do your absolute best to make this project a success for you and your client.

You’re hoping to build your reputation along the way by featuring this client in your portfolio. And they’re going to mention you in their press release for some word-of-mouth marketing.

Your ideal client and project

You didn’t just take on any client and project. This one feels really good.

• The idea is good. It’s not about building a Facebook clone.
• There is actually a sound and profitable business model. It’s not about getting free users.
• The client has hired a designer to produce a set of beautiful PSDs.
• There’s also a clickable prototype built using InVision.
• They even gave it a lot of thoughts and listed out as many scenarios and edge cases.

The client is responsive and ready to move forward with the project. They signed the contract and prepay you for the first week of development. These are all indications for a great client.

As you start development

After the client sign-off, the designer shares a set of beautifully designed PSDs with you in Dropbox. They look fantastic. You are excited to work with such a great designer.

As you are about to slice the PNGs…

You realize the PSDs aren’t designed for the iPhone 6S Plus at 3x resolution. No problem. Just let the designer know and ask them to make it 3x.

Sure enough. The PSDs are fixed now. Let’s get back to work.

As you are about to slice the PNGs…

You found some images with drop shadows aren’t being done as separate layers. You need the transparent PNSs as the table view scrolls. But you can’t slice them out without the background images. You could try to fix it with your limited skills in Photoshop. But it’s best to ask the designer to fix these up.

Okay. There are proper layers now, and you can slice your transparent PNGs pixel perfect.

As you are about to slice the PNGs…

You realize some of the elements the designer wants to use are very difficult to implement in practice. They require you to read up on the docs and research on Stack Overflow. You don’t know how long it’s going to take. You just know it’ll far exceed your original estimate.

Time to go back to the client and negotiate some of these niceties. Do they really need to be in this MVP or can they wait until a future version? Are they actually useful or just bells and whistles?

The client is reasonable and understand your concerns. So they are flexible. You are given the freedom to be creative and find an easier solution. Or even use a built-in control and just snap a simple background image.

As you are about to slice the PNGs…

You start to realize these PSDs capture only the user interface but not the user’s interaction with the interface. Many of the intentions from the designer are hidden or ambiguous, at best. Based on your experience and some common sense, you can make most reasonable assumptions. This image probably needs to be a button and navigate to a details screen. That probably is intended as a scroll view to scroll through the user photos.

Some assumptions are right and others aren’t. But that’s all right. Let’s have a meeting to flesh these out to get everybody on the same page.

As the meeting goes, more edge cases are discovered and considered.

Showing the user’s friend updates on the dashboard is fine. But do you just leave the section empty when the user hasn’t followed anyone yet? What should the table view display if the app can’t fetch the data because the user is on a train in the tunnel? What should happen when the backend goes down? Should an error message be displayed? Or fail silently? Maybe display a cached version from Core Data? What is the sync strategy?

Some edge cases may not be obvious until you actually try to implement the features. The only sure thing is this. The back and forth will almost certainly allow scope creep. And that’s a real big problem for you, the developer.

When the original design was done, the scope was already sort of fixed between the client and the designer. You weren’t involved to give your technical inputs, nor consulted to give your hour estimates. Heck, you weren’t even hired until after all of these have been done.

After the PSDs are furnished, you are asked to give two numbers – hours and hourly rate. The client shops around and tries to find the developer they are willing to pay and feel comfortable working with together.

Failure is looming ahead

After these issues are fleshed out between you and the client, you can finally continue development.

It’s a new Xcode project, so you don’t have to deal with the leftover cruft by the previous developer. You have all the freedom in the world to design, architect, refactor and unit test.

However, it’s hard as hell to convert the PSDs into actual code that:

• Runs reasonably fast on both iPhone and iPad with different screen sizes and resolutions, varying RAM and storage capacities.
• Does not crash on both the simulator and the physical devices that the app needs to support.
• Works around all the nuances and rough edges of the different iOS SDK versions.
• Is fully covered with a suite of unit tests against all the business rules and edge cases.

If anything happens:

• If the app doesn’t install on the client’s device, it’s your fault.
• If the app fails to match the design pixel perfectly, it’s your fault.
• If the app crashes, it’s your fault.
• If the app is slow, it’s your fault.
• If the app generates unexpected results because of an unforeseen edge case, it’s your fault.

This can get even worse. You may even feel that if the app isn’t successful, it’s because of you. Because you fail to execute on time and budget, the client has to make compromises by cutting features and settling with an inferior design. It can’t be because of the idea or the design. The idea is great. The design looks beautiful. So it must be the developer’s fault.

Oh no, you’re a bad developer.

Is this really all your fault?

There are many things that can potentially go wrong in a project. I’m sure you also have your own unique horror story, or stories. But you’re too busy writing code. There’s no time to take a step back to try to figure out why you’re feeling this way.

Is this the nature of being a developer? Do all developers feel this way? Are you going to be feeling like this forever, as long as you are writing code for a living?

Is this really all your fault? Are you the one to blame?

You can try to deflect the blame. You can say this is not your fault. The idea isn’t as good as you thought it was. The design is too complex. The requirements are too stringent. The edge cases are too encompassing. There’s not enough time and budget planned for this large app. Or this team just doesn’t work well together. Maybe there are communication issues that need to be dealt with first.

You can also choose to take all the blame. Yes. This is your fault. You didn’t architect your app properly. You didn’t design and decouple your classes correctly. You didn’t refactor enough. The unit tests have holes in their coverage.

Or somewhere in between. A popular, feel-good, folk tale version. We work as a team. We fail as a team. We take the fall together as a team. So it’s everybody’s fault. No finger pointing.

Regardless of where you place the blame, you can still feel the negative emotions. They can easily make someone go into deep depression. Some developers even quit their careers and never code again.

Hold your breath. I’ll show you the definitive cause for your failure.

Comparing web and mobile development

In a web app, you’re either the frontend or backend developer.

In a mobile app, you’re the app developer.

In a web app, the frontend developer slices the PNGs from the PSDs. He writes the HTML and CSS. He codes the Javascript. He takes care of multiple platforms and browsers. And he creates a responsive design that works on both desktop and mobile.

In a mobile app, the app developer slices the PNGs from the PSDs. You build and style the user interface. You align things using Auto Layout constraints. You take care of different iOS versions, devices, screen sizes, and resolutions. And you make sure things look good when rotating between portrait and landscape.

Can the designer build the user interface in Xcode?

Auto Layout requires understanding of code and the iOS SDK. It would be very difficult for a non-programmer to build the user interface in a mobile app.

A designer would have to:

• Install Xcode and set up the certificates and provisioning profiles.
• Understand when to use tab bar controller, navigation controller, split view controller, page view controller.
• Know when to use table view vs scroll view.
• Know the difference between static and dynamic prototype table view cells
• Create UITableViewCell subclasses.
• Have a good grasp of all the built-in controls.
• Know how to set up constraints in storyboards and adjust them in code.
• Connect the IBOutlets and IBActions to the view controllers.
• Create the app’s navigation using segues.

As an experienced developer, you also know a bag full of tricks to apply in the storyboard that can make writing code easier. For example, a designer simply cannot be expected to know he should have broken up this complex screen using child view controllers.

If you have to teach a designer on the difference between static and dynamic prototype cells and how to create a UITableViewCell subclass, you may as well just do it yourself.

If you cannot reasonably expect a designer to build the user interface in Xcode, could there be a mobile frontend developer that can do this?

As far as I know, there doesn’t exist such a role. But why not?

In programming terms, there’s simply too much coupling between storyboards and code.

A mobile frontend developer would essentially need to know as much code as an app developer to be an effective mobile frontend developer. If such a person exist, he is essentially an app developer.

But wait, there’s more…

The mobile developer also has to create the certificates, provisioning profiles, and entitlements, add the app in iTunes Connect, generate TestFlight builds, submit the app for review. This sounds more like the job of a dev-op. But as an app developer, you take everything on. But with the same amount of time, estimate, and pay!

Mobile development = frontend development + backend development + dev-op.

You’re doing the job of three while given the resource – time and money – of one. You have to wear many hats to get an app from concepts to the App Store.

When a client wants to build a web app, they understand they need to have a good design, build the pretty HTML and CSS, with a server in the backend, and some dev-op to keep the app running. When a client wants to build a mobile app, they only know to hire a designer and an app developer.

This is why mobile development is so hard. This is why most mobile development projects fail.

And you probably haven’t thought about it this way.

What can you do about it?

You now know the reality. You, the mobile developer, is actually both the frontend and backend developer. And this double responsibilities is the major reason why most mobile development projects fail.

You also saw it wasn’t possible to separate these roles because of the heavy coupling between storyboards and code.

What can you do to fix the situation, to improve the likelihood of a successful project?

There are three areas you can look to set the right expectations and make sure you produce clean, high quality code.

Improve your communication skills

You don’t want to set yourself up for failure. You want to set yourself up for success. To do this, you need to set realistic expectations from the very beginning.

You want to educate your clients about the complexities but not the inner-workings.

Instead of saying:

The coordinate system on the iPhone 6S Plus is 414 x 736 in points. But the physical resolution is only 1080 x 1920. In order to display the 3x assets on the retina screen, it first needs to render the images at 1242 x 2208 in pixels during rasterization, and then downsample the rendered images to 1080 x 1920 to display on the screen.

Your non-technical client will be completely lost and still don’t know which resolution the PSDs need to be.

Say:

Please ask the designer to produce the PSDs with 3x assets in a 1242px x 2208px canvas. If he needs more information, you can send him this link to demystify the iPhone screens.

There is now one, not three, resolution that needs to be passed along. More details is also provided in an external link.

Less is more. A link is worth a thousand words.

Your client will respect your expertise and appreciate your professionalism. With fewer, simpler words, your client can understand the problem while feeling in control.

When your potential client first brought up the project to you, they tell you the idea, the ideal users, features and requirements. They want to know how long it’ll take and how much it’ll cost. It’s easy to tell them it’ll take 6 months and cost $50,000, or you hourly rate.

But you’ll go much further if you break up the numbers for separate frontend and backend development. List the tasks you’re going to perform for each.

Your potential client will realize building a mobile app is not as easy as they thought. They’ll be more open to your estimates. They’ll take you more seriously than your competitors because you clearly identify items they haven’t thought about but now realize as necessary.

Money is often not the problem. Your clients want to have successful projects. They don’t want to pay for something to fail even if it costs less.

Does this mean you may lose the project if your estimate exceeds the client’s budget?

Yes. But.

Losing a bad project is better than winning a bad project. Working in a bad project with unrealistic expectations is doomed to fail. It sucks time and energy out of you. Both you and your client stand to lose. The code quality will suffer. The app will fail. You will earn bad reputation.

Set your design guidelines

You’re an experienced developer. You know what a PSD should look like for you to easily slice the images that can be immediately useful in the asset catalog.

Prepare a document to list your design requirements and best practices. Send it to your client and the designer. This will show your client that you’ve done this many times before. You know your crafts well.

If you’re a consulting agency that provides both design and development services, you can line up your designers with a set of standard design best practices. Similar to a code style guide.

This will save a lot of back and forth between the designers and developers. The resulting PSDs will be immediately useful.

Level up your development skills

With communication and design, you’re still working with other people. But as a developer, you’re in charge of the code you write.

You have complete control of the application architecture. You have the responsibility of making sure your code works correctly. It’ll also be in your best interest to make sure your code is easy to change when the requirements change.

How can you make sure these things happen?

The only way I know is to learn how to architect your app based on decades of experiences and proven techniques by the best software craftsmen before us. Unit testing is beneficial only after the app architecture is in place.

Architecture comes before testing.

I’ve talked about how to apply the Clean Architecture to a Swift project and how to write unit tests with TDD. I encourage you to study it and ask questions. At the same time, don’t be afraid to experiment on your own.

I guarantee you’ll be a much better and happier programmer if you decide to level up. You’ll enjoy writing code instead of cursing and monkey patching.