iOS app development best practices

oren Blog

Here’s a fairly detailed set of best mobile development practices from Aditya Narayan, TurnToTech’s co-founder and CEO.
—–

h

Over the past 15 years, I’ve actively been involved in Information Technology –  building software, building data centers, designing large scale systems, heading technology departments at large companies and running my own tech companies. These lessons are based on those experiences and the iOS specific ones are based on our experience with mobile development in the last 7 years. Each of these is based on direct experience on more than one occasion over several projects.
image
In many ways, I use the ‘good enough’ approach but in most cases, I have absolute standards and I don’t cut corners unless absolutely necessary. My approach to everything, including software development is entrepreneurial. I minimize risk, maximize resources and try to produce a very high quality product. The following lessons are mainly centered around minimizing risk.

WHAT SHOULD I DO ABOUT DESIGN and ARCHITECTURE of an iOS APP?

  1. Writing code for the app is important but architectural decisions are more important unless your team is really small and has extraordinarily talented people who can improvise on the fly – in which case you don’t need to read this. But otherwise – do spend time designing, prototyping and defining the architecture before formal coding and iterating the cycle over and over.
  2. As a process: design the user process/workflow first, next design the data/information model i.e. how information is viewed/created/retrieved/stored – both in app and in the backend, and then choose your backend technologies, design classes etc. Definitely do not let visual designs, pixel perfection and animations distract any of the developers at this stage.
  3. Use wire framing tools – or paper. Or use crude Flinto type models. Don’t go for colors and visual effects – they will distract your team unnecessarily i.e. take the big picture approach at this point
  4. Remember that an app is a fat client – which is very different from a thin web app. If you’re not clear why – look up the architecture of fat client applications. It’s been extensively documented.
  5. If cached data is relevant to your app  – design, prototype and debate your caching model – before implementing or you’ll be in deep trouble. Caching helps in many ways – better responsiveness, usability when network is not available, reducing load on server.
  6. Spend some time drawing the state diagram for your app. You’ll find it useful for many things but especially for push notifications.
  7. Which software development patterns are most useful in iOS?

    All patterns are relevant but obviously, MVC stands out – and it doesn’t stand for Massive View Controller – I wish I’d coined that term  🙂

    HOW SHOULD I APPROACH SECURITY FOR AN iOS APP?

  8. Do not ignore security – make sure your developers understand password hashing, salt, privilege escalation, ssl and server side authorization. Make sure every request is authenticated and authorized unless it’s to a part of the app where the user is not supposed to be logged in. Bottom-line: centralize your security, don’t apply it piecemeal
  9. Understand that storing keys/passwords is tricky business. Storing those in code and thinking that the compiler will somehow obscures it is a very common misunderstanding.

    WHAT ARE TROUBLESHOOTING AND DEBUGGING BEST PRACTICES FOR iOS APPS?

  10. Logging – split every discrete process such as user sign up or tagging a photo into 4-5  stages. Log success/failure of each step. This way even when app crashes unexpectedly – you’ll know the last successful step.
  11. Make it easy to access the logs from the device. During debugging – you may want to log all this to a file. You can get the users to send over files or build a little features to email that log directly from the app.
  12. Use crash analytics. Understand something called ‘symbolication’

     WHAT IS THE BEST WAY TO PERSIST DATA FOR iOS APPS?

  13. Avoid core data and use sqllite if you can – your app will be easier to port to Android and everything will be less magical. But if you’re not concerned about Android and want to launch quickly and don’t have an overly complex data model and someone on your team knows Core-data well – go for it. That’s  a lot of if’s by the way…
  14.  It may be useful in some cases to have two layers of  your model classes – one for displaying information and one for physically storing data eg locally to SQLite or the backend.  And then you need to transform between the two layers. Test yourself on this question: How disruptive will it be to switch from core-data to SQLite?  The answer should be – “ Our model is clearly abstracted out. It’ll just take some coding but we can easily switch’. But if your answer is – “we’ll need to almost rewrite the app” – you’re dealing with a deeply flawed architecture.
  15. If you are using a nosql database in the backend – don’t use performance as generic rationale to justify it if you don’t already have a massive performance issue. Find another reason. There are plenty. A good reason is flexibility.

    WHAT ARE SOME NETWORKING RELATED BEST PRACTICES FOR iOS APPS?

  16. JSON is good for exchanging data over the wire but remember that you get nothing more than strings and numbers. Be prepared to deal with unexpected types. Try to get your feet wet by formatting dates and normalizing across timezones.
  17. Don’t ignore push notifications until the very end of the app –  they are super easy to get started with but super tricky to get right. The number of cases you need to test for is huge if different push notifications need to open different parts of your app.
  18. Spend plenty of time understanding “network reachability” – it’s powerful and deceptively hard to get right. Take an unreliable network as the norm. And leverage caching to provide a good user experience.
  19. The app should recover gracefully – after a sudden reboot or lost network. Harder than it sounds.
  20. Constantly read about specifics from the developers of major apps like What’s App, instagram, Facebook etc.
  21. Use the NetworkLinkConditioner – it will save you months of debugging time.

    PROGRAMMING

  22. Should I use code from GitHub in my iOS projects?

    Don’t use frameworks with a bunch of dependencies from github for doing simple things. If you do –  be prepared to fix at least one serious bug in each which means you’ll be understanding/changing/testing that code. If you do decide to use such a no-name framework – do the following

    • Check how many commits they’ve had in the last year
    • How many active developers
    • How much stack overflow activity for that project
    • Is one of their lead guys answering questions on stack overflow
    • Is there a company with some longevity behind the project
    • Many times, a more generic but no-name framework will use 1000’s of lines of code along with dependencies and potential inconsistencies with your code –  for a feature that you may be able to write in under 100 lines. We’ve seen several such cases.
  23. How does one prioritize the work for an iOS App?

    Don’t go after visuals and pixel perfection until your app is robust enough that it doesn’t crash under various situations like airplane mode, low network bandwidth, big DNS delays etc.
  24. Which frameworks should I use?

    Don’t use frameworks whose use cannot be conclusively justified e.g. don’t use core-data or GCD just because everybody likes to talk about them.
  25. What’s the best way to build navigation in an iOS App? Should I build my own?
    Don’t create your own navigation unless you’re an expert problem solver – because it will be problematic. Use built in classes and customize.
  26. Shoud I use Objective-C language features such as categories and understand the Objective-C runtime?

    Don’t go overboard with categories and swizzling and other exotic things. Use  features when they make sense. Readability of code important at the end of the day. And developers from other backgrounds may be joining your project. And soon you may be developing for another platform. So it’s best to not get too deep into the intricacies of a specific language or technology and instead focus on breadth of your understanding.
  27. Should I use NSNotification for integrating different parts of my iOS app?

    Don’t use NSNotifications for passing data between different parts of your app. Use them for notifications only. You’re asking for serious problems down the line. This is worse than goto’s.

  28. How often should I refactor?

    Refactor constantly. Copy pasted blocks of code mean bad code. But everyone knows that 🙂

  29. How much commenting is required for code?

    Comment your code like you’re writing a book. Especially, document your own algorithms with examples. This is way more important than proper naming of classes and variables which one should do in any case.

  30. We have ARC. Do we still need to understand memory management?
    Memory management – understand how it works in iOS. ARC isn’t as magical you’d like it to be. If it means anything – I wouldn’t hire anyone as an iOS developer unless they understood how memory management works.

    WHAT ARE SOME OPTIMIZATION BEST PRACTICES?

  31. Do not optimize your code until the very end. Focus on robustness over performance. You may have heard: premature optimization is the root of all evil

  32. Optimization is hard. That task should be given only to the best in your team.
  33. Understand the difference between network latency and bandwidth and how they affect perceptible performance. In order of difficulty, if writing the first 70% of the functionality takes effort X, optimization should be treated at near 6-10X or so. Compiler flags and server settings for optimization are not what we’re talking about. We’re taking about improving algorithms in your code.
  34. Be systematic and focused. Identify the slowest steps in a process and optimize those instead of optimizing random parts of the code.

    How does one plan an iOS project?

  35. Make sure at least one person in your team is a master in memory management and instruments and knows both ARC and manual memory management
  36. Make sure at least one person in your team is a master in performance testing
  37. Make sure at least one person in your team is big on automated testing
  38. Make sure at least one person in your team is a master in source control management, especially merging. And this can’t be a semi-technical manager – it has to be a senior developer
  39. Make sure every developer understands async programming
  40. Make sure every developer understands how to debug http using command line tools like curl
  41. Make sure every developer understands how to cancel a pending operation such as a network request — and why they should know about it
  42. Make sure every developer understands how network timeouts work
  43. Make sure you entire team understands MVC. Don’t have any logic in your controllers.
  44. It is relatively hard to split an iOS app into different parts for different developers to work on. So pay special attention to this aspect. Frequently, developers will be working on the same files.
  45. Carefully guide your developers who want to constantly use the latest and greatest and use technology for the sake of technology. While that’s great for creativity, it doesn’t work well when launching products. Try a balance between creativity and discipline.

    USER FOCUS

  46. If your app is super unique in its concept – make sure you have nice visual tutorials. Otherwise skip those
  47. Test your app with someone from outside of engineering for every little feature that gets added – even when it’s super crude. Not doing that is asking for several months in lost time.