How To Keep Your Native Mobile Project On The Rails
Native mobile development is costly... so don't make rookie mistakes. This is a non-technical guide to winning.
1) Get the Background: Read These Two Books
Native mobile development is different from what you're used to, so if you want to succeed, you need to walk into this ready for a mental shift. The goal isn't to add software to your client's pocket... it's to take away frustration from your client's life. Golden Krishna's "The Best Interface is No Interface" will help you understand the art of what NOT to do.
If you want your app to actually be used, you need to realize that you are going to need to changing your client's pre-existing behavior. Nir Eyal's "Hooked" will help you understand the underlying behavioral science that you can employ to tear up old habits and insert new ones.
2) Answer This: Do you actually need a native mobile app?
Having read the books above, ask, are you doing this "because mobile" or is there a specific behavior that is done on the move that is enriched by having sensors (like cameras) and data at your fingertips. If the former, just make a web app. If the later, carry on.
3) Be Lean. Use Flinto.
So much of a native app is behavioral black magic, you HAVE TO answer "will the users dig it" before you start coding. If you wait to get this validation until you ship your first build, be assured, you'll be facing some expensive re-work.
Instead, be Lean (read the Lean Startup, if you haven't), break your vision up into the series of hypothesis that must be true in order for your product to succeed. Find ways to test those hypothesis without coding. Flinto will be your best friend here. With Flinto, your designer can mock your app up without expensive coding and answer all kinds of questions by getting a real-feeling app mockup in front of clients.
4) Get Your Backend In Order
Now, common wisdom is that you'll be transferring data back and forth from your app via a RESTful API.
Don't do it. Even if you already have a REST API to build on.
Instead use a Realtime Database. It will save you A TON of dev time on the native end especially if you consider the lifecycle cost of the app with upgrades, data architecture changes, app version management, etc. Some good options are:
- Firebase... if you're starting from scratch
- Realm... if you have legacy SQL data
- Couchbase + SyncGateway ... if you have an enterprise budget
5) Get It Right On One Platform First ... Don't fall for any promises of a shortcut
Congrats you're now in a great place! You know what you're doing. You've tested your hypotheses. Your designs are dialed in. Your backend looks fabulous. It's time to code.
So which platform(s) do we support? iOS? Android? Both? Oooo maybe we can shortcut both with Xamarin/PhoneGap/SellingOurSoulToBeelzebub ...
Well.... my repeated experience is that so called cross-platform "shortcuts" are nothing but a deadly honeytrap. They promise cutting your development in half but in fact, you spend more resources getting things to work that you would if you just made it native to begin with. Remember Java's hilarious maligned "write once, run everywhere" aka "write once, debug everywhere"... that.
So pick iOS (Swift) or Android (Kotlin) to start with. You can do both eventually but let one lead. If at all possible let Android lead. If you do market research that shows you'll not succeed unless you lead with iOS... ok, but Android will let you be more Lean by allowing you to iterate faster and cheaper. Once your released Android version is vetted in real life, in the market, THEN invest in the iOS dev effort (or vice versa)
6) Get A CI Pipeline Rolling
Now that you're rolling out code, your challenge will be getting out good code. A CI pipeline will make your life millions of times easier and let you find errors early by getting your app into the hands of an army of testers before it hits the stores. Here is the tool stack that has served me the best:
- Crashlytics (https://try.crashlytics.com)... for distributing the app to testers and collecting error reports
- Travis (https://travis-ci.org/getting_started)... for continuous integration and testing
- Fastlane (https://fastlane.tools/)... for managing build & release
Conclusion
Native development is it's own animal. Not a bad one. Not actually that expensive if you do it right... but if you do it wrong... ouch.
I hope this helps you nail it. You can do it!