Working on building mobile apps for the last several years I thought I would publish a list of some of the things I’ve learned here in the mobile trenches. Without further adieu and in no particular order… Btw, welcome your feedback/additions.

1. Take a serious look at React Native. Faster releases, fewer bugs, that can be fixed without AppStore review. Web-style development in the simulator, fast and fluid.
2. Use Crashlytics. It’s free, from Twitter works on iOS and Android and will make your life easier. Just use it. And no, I don’t work for Twitter. (Crashlytics is now part of Google’s mobile platform called Firebase which if you haven’t looked at it’s well worth it)
3. Use Answers. It’s not a full mobile analytics platform but it provides a very useful slice of mobile analytics. Again, from Twitter via fabric.
4. Use fastlane. Also part owned by Twitter, sort of a theme going here.
5. Document your AppStore release process it tends to get long an involved, thanks Apple.
6. On iOS use Cocoapods. Look for Cocoapods versions of packages to include in your apps. Ask venders for them.
7. With Cocoapods use Podfile.lock. Check it in. Don’t unknowingly bump versions of pods (especially third party pods) unless you’re ready, meaning you have ample time to deal with consequences of things breaking. Schedule time to specifically update your pods. Update pods following a release.
8. With npm (see React Native above) use an npm-shrinkwrap.json file. Check it in. Until and unless you’re ready to update lock down your node packages.
9. Use a Gemfile.lock to prevent unknowingly updating any dependent Ruby gems.
10. Use a free analytics package (like Google Analytics) but write the eventing code with the thought that some day you may want to replace it with something like Localytics. If you don’t go with free try to avoid spending too much money on analytics until you really need to.
11. Try to avoid eventing *everything* to your analytics platform, focus on what’s really important and make sure your key flows are evented properly before you ship. (IOW, test that they work)
12. If your app does anything in the background make sure those things don’t trigger analytics events. Get multiple developers to review the related code. Make sure you understand app lifecycle on both iOS and Android with respect to fore/background transitions. Make sure no third party package/pod is doing something unexpected in the background.
13. If you have/support login don’t support anonymous users. Despite your “best intention” thinking that you want to allow people to explore your app it will over complicate your client app, server code, analytics, flows, and everything else for far less benefit than you think.
14. When thinking about retention think in seconds from first launch, not days nor weeks nor months. If a mobile app doesn’t “work” for a user in the first 15 seconds you won’t have days or more to worry about. Time (meaning with a watch) what it takes a user to grok what they’ve just installed. Again get the analytics right in this part.
15. After nailing 15 seconds, think about how you’ll treat users on day two, day three, day five, week one, week two etc. differently as they grow into a returning user. Users have different needs at different points along the way towards learning your app.
16. Know that mobile retention curves are trailing indicators and meaningful curves take weeks/months to fill out. Focus on the above first.
17. Don’t forget the U.S. is BIG and has time zones. Don’t ignore them.
18. Follow Paul Graham and Sam Altman on Twitter. There are many more but start here. Btw, Sam is on a self imposed hiatus so read his prior tweets.
19. On first launch be thinking how to get your users to engage with your company by submitting content to you, or connect them with another user, or enabling a background service like geo-fencing or allowing notifications. Something to give them a reason to re-engage with your company or secondarily a reason for you to initiate a second launch. Users should understand within 15 seconds what this engagement will look like.
20. Don’t use an ampersand (&) in your name. Yeah, there are major companies who use it but getting started it’s not worth the headaches. It’s a terrible idea that will forever bite you for the life of your product. The Internet isn’t friendly to the good old & which I have to type with four characters every time I reference it in this post. It doesn’t work in URL’s and thus wrecks your pretty name getting replaced by “n” or “-n-” or “and” or dropped. Typing an “&” on a mobile device requires users to know where to find that key by switching keyboards and switching back and searching for it on the AppStore is a PITA and pretty much everywhere else you can think of related to search. And, it will constantly be the rookie mistake your team will forever find and have to correct.
21. Use Branch.io. It works. Spend time to get deep linking to content within your app working. Use branch.io to “pass data through the AppStore” for attribution of install source and referrals.
22. Leverage webviews. Hybrid apps using both native and webviews offer lots of benefits. Webviews lend to being cross platform and fixable server-side. Do research on how to interact with web content from native and vice versa.
23. Push to use stock fonts. Seriously. There are more than enough to choose from and ensuring the proper use of your custom font throughout your app may end up feeling like chasing the ampersand problem I mentioned above.
24. Create a RESTful “/versions” API endpoint and call it on every foreground launch. Your clients should pass query params to this API containing details you won’t have to look up server-side such as whether the device has certain capabilities enabled like notifications, location services, bluetooth, its clientid etc.
25. Following a push to the AppStore don’t delete the AppStore release emails from Apple as they’ll help you debug rejections over time and help you recall review durations and rejection details both of which will be helpful with future releases.
26. Keep notes on why your AppStore submission was rejected and what you did to fix it.
27. There will be no shortage of articles trying to explain how and why mobile is difficult. Read them.
28. Don’t let holidays surprise you. Holidays can impact app usage and you should avoid and/or leverage these days depending on what your app does.
29. Take a look at Mobile Action for help with ASO.
30. Find an audible sound that resonates with your app and use it in a context that will delight your users and consider introducing it in the first 15 seconds.
31. If you want to use mobile ad networks don’t expect them to have inventory out-of-the-gate rather expect a trickle of ads (if any) that may not ramp very quickly. Of course, this will be related to the type of app you’re developing but still don’t accept quoted earnings to be even close early on. And be sure to ask for weekly reporting.
32. Don’t expect 3rd party mobile ad SDK’s to be stable as none of the ones we used came without fairly significant problems requiring updated builds (aside from Google). Be sure to test your app with ads and consider having an option to disable loading of the SDK server-side in case something goes wrong (like it’s crashing your app).
33. A surprising percentage (at least to me) of our users have Bluetooth enabled. Significantly higher than the research I found on the web suggested.
34. Frequently check the OS reports for energy usage of your app(s) since being at the top of the list drive uninstalls and/or bad reviews.
35. Be quick to respond to bad reviews on the app stores.

As I think of other items I’ll look to update this post.
Updated: June 28, 2016
Updated: July 13, 2016
Updated: July 15, 2016
Updated: July 19, 2016
Updated: July 21, 2016
Updated: February 26, 2017