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.

Skills Web frontend developer Web backend developer Mobile developer
Slice the PNGs from the PSDs ✔︎ ✔︎
Write HTML / Build UI ✔︎ ✔︎
Write CSS / Style UI ✔︎ ✔︎
Write Javascript code ✔︎ ✔︎
Multiple platforms / Multiple devices, screen sizes ✔︎ ✔︎
Multiple browsers / Multiple iOS versions, resolutions ✔︎ ✔︎
Responsive design / Handle rotations ✔︎ ✔︎
Build custom views ✔︎ ✔︎
Sync strategy ✔︎ ✔︎
Persistence strategy ✔︎ ✔︎
Networking ✔︎ ✔︎
Any other business logic ✔︎ ✔︎

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.

Get the Clean Swift Xcode Templates

Subscribe below to get my Xcode templates and learn how to apply the VIP cycle to your projects, extract business and presentation logic into interactor and presenter, navigate to different scenes using multiple storyboards, and write fast, maintainable tests with confidence to make changes.

I promise I'll never send you spam. You can unsubscribe at any time.

Raymond
I've been developing in iOS since the iPhone debuted, jumped on Swift when it was announced. Writing well-tested apps with a clean architecture has been my goal.

29 Comments

  1. For me an Mobile Developer is exactly the same as a Web Developer. They are just using different languages (Javascript vs. Java/Swift), but are doing the same work and the architecture should reflect that (they build the Frontend/Client).

    And from my point of view there are different types of failures and only one type qualifies to directly blame the developer for and that is a crash. Failures should be monitored and if a pattern arises it is time to find the source and blaming anyone is very unlikely to solve the problem.

  2. Being a Mobile Developer is the same as being an app developer has always been, even before there was a Web, developers wrote the back end and front end of their apps. Most of the time with so much coupling that there was no graphic way to design the UI. Just code.

    The only thing I agree with is that projects fail when the estimates are sloppy. You have to ask questions before giving an estimate, not after. You can’t do estimates without having seen the design first, you have to know if you are using the built in controls or you have to code your own. NEVER ASUME ANYTHING. There will always be surprises, but try to keep them to a minimum.

  3. A valid article and you had me with you until the web/mobile developer table. I’ve always had every one of those check marks next to my name.

    If there is no ability to divide labor in app development like there is at places that have both front- and back-end web developers, then there is a critical issue with the state of app development. My guess is that there are plenty of places that are succeeding at managing responsibilities and the issues you bring up here are more about the size of your shop than the type of development you’re doing.

    1. Hi Robert,

      Good point. There are differences between developing for client projects as a consultant and developing one app for a product/service company. This post describes the former. In the latter, you’ll likely have a large team to divvy up the responsibilities.

  4. “This is why most mobile development projects fail”

    Most software development projects fail. Mobile development projects instance-of software development projects. Therefore, most mobile development projects fail. Is there any evidence that mobile projects fail at a greater rate than any other kind of project?

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

    In what world is this true? I’ve never seen a company so big and structured that these were completely separate.

    1. Hi Poggus,

      However, the designer doesn’t necessarily know which slices and how large they should be in order to work with the UI elements the developer chooses to implement.

  5. That sure is a lot of problems with PSDs and PNGs.

    Ask your designer to provide .svg vector files, and render those natively.

    Problem solved. You’re welcome.

  6. It starts out bad. A project that starts with a lot of art work and words has been chewed on likely by a product marketing team to the point where the actual functional description, the what of what is desired to give the users and the business value, is hidden in realm of how to details all the way down to how each screen and pixel looks. These are the least important things to having a product that pleases the actual users and meets the original functional goals. It is death by a million detail cuts.

  7. I’m sorry but this article is written from a completely biased point of view, their experience in the industry is tainted.

    I disagreed with so much of it.

    First of all, the table of ticks against each person’s role is crazy, in theory yes this looks good on paper, but no organisation of any size actually stick to those responsibilities – they cross over in so many places.

    Secondly, perhaps your projects fail because you’re not sitting down with the team and having multiple huge detailed meetings and discussions that include wireframing and detailed all cases before even starting the project! – how are you expected to code efficiently if you don’t do that?!

    Thirdly, never in my years of development have I known an app developer to slice files – that is ridiculous. No wonder mistakes are happening! This is the designers job.

    Also, when on earth did you do any researching and testing of usability, arguing your case, you just acting as a nodding dog in the article – absolutely every aspect of a project MUST be challenged in order to know its the best solution.

    Also, I’ve known many designers to go into Xcode and start the UI – I admit the may make mistakes or not finish it, but more often than not it turns or superb… You need to let them try it, they’ll pick it up.

    Also, PSD’s?!? Is this a joke, what are we, going back in time? (I know this isn’t your fault though).

    Also, to finish on, I’m not a designer so don’t think I am, but I think you need to give them more credit… They have incredible tools available now specifically for app development which makes the transition SO easy, for example using Sketch and also PaintCode – these use similar constraints that mirror Xcode.

    I’m sorry, I don’t often comment on articles but I felt I had to point out that you’re being biased and you have a tainted view.

  8. I kind of agree with Jonathan, although in reality this shit does happen.

    First it’s a big problem to start the development without going through the mockups and really try to think trough whatever the designer imagined in there. Designers can go crazy sometimes.

    Also, you shouldn’t have to crop the graphics assets yourself, it’s designer’s job. Like you mentioned have him informed what kind of graphics assets are required depending on the resolution

    But again, the article is good and it does reflect the (ugly) reality…

  9. I think the title “Your ideal client and project” should be changed to “Your (apparently) ideal client and project”
    A client which doesn’t think through the designer’s mockups and having to cut your graphics assets by yourself is definitely not an ideal client you’d want to work for.

  10. Hi,
    Just wanted to say that i liked your article and maybe seek to clarify the premise.

    A lot of what you’re saying, and the misinterpretation by some commenters, is because you’re talking about skeleton team app dev rather than well funded tech hub stuff.

    I’ve done a lot of this too and have come to similar conclusions, which basically all fall under the heading, “ways to protect yourself from your and other’s incompetence without it feeling like incompetence”.

    I think it takes a lot of self awareness and is fundamentally a growth perspective.

    Nice one bruv! 🙂

    1. Hi Seth,

      Thank you for your comment.

      Yes, there are differences between working for clients and working for a product/service company. My post primarily describes working for clients. But as a reader, it’s very easy to read something and apply it to one’s own experiences. That’s ok. Any opinion piece will have people who like and dislike it. I knew that before I hit publish. I’m blessed to hear way more positive comments than negative ones.

      The main point I was trying to make is: Mobile development = frontend development + backend development + dev-op. That really strikes accord with people.

      However, the other point I wanted to make was mostly missed. It is the following. As mobile developers, we shouldn’t feel bad about ourselves now that we realize we’re doing the jobs of three people. Instead, we can provide better service to our clients if we focus on improving our communication to our clients and designers AND strive to write better, clean code.

      Nonetheless, it’s very interesting to hear what others have to say.

  11. Hi, Raymond, I am an iOS developer from china. this is really a good article. May I translate it into chinese? I will mark the original sourcc in my translation.

  12. Awesome article that sums up an often seen experience building an app. All those people saying ‘no way!’ and ‘you have to split work’ probably didn’t get the point – the experience described here is for a single person shop.

  13. This model was designed to be as organizational and industry agnostic as possible so that any mobile application development team can use this as a guide for conducting threat modeling for their specific application.

Leave a Comment

Your email address will not be published. Required fields are marked *