What are mistakes that native app developers make?

Written by: Reinder de Vries, March 22 2015, in App Development

Mistake: Reinventing the wheel, fueled by the Superhero Syndrome and the Not-Invented-Here Syndrome.

A few years back, when I was very busy with freelance development gigs, I needed a way to account and report my work hours. So, I fired up my code editor and created a nifty little tool that recorded start and stop times for each client.

Then, I found that for a lot of web projects I used the same functions and classes over and over again. I decided to put them in a framework, and put a lot of thought in the structural design of it.

Then, one of my clients needed a HTTP REST API back-end. I had just read up on Object-Relational Mapping and decided I should write a wrapper between MySQL and native PHP objects, to make saving and editing objects easier.

Of course, I learned a lot, but failed to see one personal flaw: I didn’t want to use someone elses open-source work, because I thought I could do it better. Custom always trumped standard work, I thought.

Superhero Syndrome and Not-Invented-Here Syndrome

Both syndromes are alike. Superhero Syndrome means that you fail to delegate work, because you think you can do better than those you’d delegate to. Not-Invented-Here Syndrome means you won’t use something you didn’t make, because you feel you must have made it yourself for it to be good.

How does this apply to app developers?

Well, in order to create an app for iPhone, all you need is Xcode. Technically, you can create an app from scratch without downloading one library.

The same doesn’t always apply for other development environments. To create a Bootstrap web app, or work with AngularJS, React or Node, you’ve already downloaded a dozen libraries and frameworks through the package manager. More often than not, these SDKs already work with their own frameworks and ease/force you into working with their way too.

For app native app development, that’s not always the case — you can get away with your own limited way of thinking and programming.

A downside however, of using too much libraries, is that you lose the intricate meaning and inner workings of the products you use. That makes you lazy as a developer, and more naive. Using higher functions means regression to the mean, and that causes more average programmers.

A Solution

Then, how do you solve this imbalance? The solution hides in the balance: use so much libraries to not invent everything yourself, but still invent enough to understand the inner workings of a library you use.

Consider this an exercise: before solving a structural programming problem (i.e.: how do I parse this JSON?), investigate at least 3 different libraries that can solve your problem. Order them on complexity, customizability and whether they’re part of a bigger framework that you do or don’t need. Pick one or two, work with them, and ultimately solve your problem.

Only then, you’ve used a framework without reinventing it yourself, without not knowing how it works.

Join 11.000+ app developers and marketers
  • Get a weekly curated list of app development tools, articles and resources in your inbox
  • 10x your app installs with relevant App Store Optimization and app marketing strategies
  • BONUS: Grab a free copy of the App Toolbox 2017 to supercharge your next app project
Yes, Sign Me Up!

Most Popular Content

Written By: Reinder de Vries

Reinder de Vries is an indie app developer who teaches aspiring app developers and marketers how to build their own apps at LearnAppMaking.com. Since 2009 he has developed over 50 apps for iOS, Android and the web, and his code is used by millions of users all over the globe. When Reinder isn't building apps, he enjoys strong espresso and traveling.

Got a killer app idea?

Grab the App Toolbox 2017 to learn how to save time building your app,
and how to 10x your app installs in the App Store. With the toolbox, you'll immediately know how to move forward to build better, more profitable apps.

Get The App Toolbox

Comments & Thoughts

Leave a Reply

Markdown is supported. Your email address will not be published. Required fields are marked with *

On The Blog

  • Doodling With Swift 3: The Read-Eval-Print Loop
    Doodling With Swift 3: The Read-Eval-Print Loop

    September 15 2016, in App Development

    Everything apps isn't all Swift, and everything Swift isn't all Xcode. You can code in the Swift programming language without Xcode with a compact tool called the "REPL". Ready to doodle in Swift?
    Learn more...
  • How To Be Productive
    How To Be Productive

    July 27 2016, in Indie App Business

    In our notification-rich world, distraction-free work becomes increasingly more important. It's almost a shared obsession we all have: how can you do more, in less time? In this article, I want to tell you about the various principles, practices and cheats I use to stay productive. It's not your average lifehack though, so get ready!
    Learn more...
  • How To Launch A Subscription-Based App Store Business
    How To Launch A Subscription-Based App Store Business

    June 22 2016, in App Marketing, Indie App Business

    Subscriptions are awesome. Especially because they give your app that sought-after monthly recurring revenue and turn your customers into assets worth looking after. Apple recently introduced a change in the iOS App Store emphasizing the app subscription business. In this article, we're going to look at how to build such a subscription powerhouse.
    Learn more...
  • How to Use Generics in Swift 3
    How to Use Generics in Swift 3

    March 12 2017, in App Development

    Generics can be complicated to grasp, but they're also one of the most powerful features of Swift. In this article you'll look at how they work, and what you can do with them. Enjoy!
    Learn more...