Building Consumer Apps Part 2: Going With The Flow
In Part 1 of this series, I introduced a technology stack that could be used to develop a social cooking app called CookMe. In Part 2, I’m going to focus more on workflow, including specific tools and things I keep in mind in order to get the most done in the least amount of time.
I like to think about all app development work as fitting into one of four categories, which are all equally important. I’m constantly trying to get better at all four. Feel free to call them the Steinbaughian Pillars of App Development. They are:
- Project Management
- Technology Decision-Making
I don’t spend too much time worrying about code methodologies. Unfortunately, in all the tech interviews I’ve been in people obsess about it. There are a lot of different ways to organize code, but as long as you stick with the same method and make an effort to keep things clean, it’s all good.
Clean, organized code is great because it might save time for some other programmer, but don’t get bogged down too much in programming theory. For iOS, Model-View-Controller (MVC) works well for me, but I’m told Model-View-View-Model is better. I don’t really care, and to be honest, in the grand scheme of things it doesn’t matter.
In app development, nothing matters except how your users feel when they use the app. Whatever you’re working on, unless it 1) gets more downloads, 2) gets users coming back, or 3) gets users to stay longer, it’s not worth arguing about for too long. You could have the sloppiest code of all time, but if you have a million users who like your app then you’re gonna get funding, at which point you hire some CS guru to come in and optimize your code.
When you tackle a big project, it’s pretty important not to reinvent the wheel. With open source, genius programmers who could probably hack into my brain if they wanted to have developed and shared code for normal people like us to use instead.
Dependency management tools like CocoaPods for iOS and npm for React are pretty life-changing, but can also be tedious. For example, a pod built by an individual developer might break with each new release of iOS, which adds a lot of time getting code to compile. On the other hand, a pod built by a team at Facebook or Slack is probably pretty well-maintained and extensible. So it’s up to you to figure out which sources to include in your project, as well as when to write your own custom code rather than using a third party library.
Similar to dependencies, code snippets are a line that has to be walked. When you run into a problem, looking something up on StackOverflow can save a ton of time, because chances are some other programmer has run into your same problem and come up with a great solution.
Copying and pasting someone else’s code (or even your own for that matter) isn’t a good practice, but when I do, I try and at least understand the code before I use it. It’s sort of like signing a contract: read the fine print before you sign on the dotted line.
I admitted in Part 1 that my only programming gig so far was an early stage startup. As a result, we were making sweeping changes to the app every couple weeks, so we didn’t have time to dedicate to unit testing, and it wouldn’t even have made sense if we were going to throw the code out in a week anyway.
However, I see the value in it. In addition to time savings over doing manual testing, writing proper tests might have avoided several significant bugs and crashes that led to a poor user experience for Wiblits users and the departure of a few key social media influencers, who we had paid marketing dollars to play Wiblits with their followers and hoped would continue to on their own as a fun way to engage with their fans.
I think specialized programmers are going to be a thing of the past pretty soon. More and more companies are looking for full-stack developers who can jump in on anything needed: database, server, web, mobile, etc. Learning these things will not only help you grow your skillset, but you can better understand how all the pieces of a project fit together, as well as understand the challenges faced by other programmers on your team.
There a lot of possible approaches to wire-framing and mockups. One is to mock everything up initially and then build the app to spec. Another is to forget about anything UI-related and make sure the app is working how you want it to, then layer UI. Or some hybrid. Or you can sit in a room with everybody for four hours and go nuts with sticky notes or whatever. It’s kind of up to you and your personal preference.
Personally, I like visualizing how the app might look up front, because it gets me excited to get to that end state, and it’s a way of getting feedback on the design without writing any code. But if a lot of changes are having to be done along the way, then spending too much time on mockups up front isn’t good either.
When it comes to rough sketches, I’m not sure anything can beat old-fashioned pen and paper. But for more advanced, realistic mockups, the Sketch app is a great tool. It includes built-in “symbols” which are OS-specific UI elements so you can better visualize what the app will look like on a specific device.
Adobe Illustrator is the standard for vector graphics across every industry. If you’re planning to do quality vector graphics like creating your own app icon, it’s almost a no-brainer. It’s $19.99 per month or $49.99 per month for all Adobe Creative Cloud apps, some of which can be useful for creating marketing materials if you have the money.
At the same time, there’s no need to reinvent the wheel for graphics that don’t need to be custom. Google’s Material Design icons are a great resource. Google has spent a lot of money hiring the best of the best designers to create the icons, like that perfect little person icon to represent a user. Users will always know what they mean, so why not use them? They’ve open sourced every icon and have it in pretty much any size you could possibly want.
This gets into more creative territory, but it’s important to build a brand image that reflects your app from the start, and to keep that design consistent throughout your app. Spend some time on a cool app logo. Identify a color scheme and font to use throughout.
Is your app going to be fun and quirky, or sleek and modern? Is there a lot of text requiring fonts to be really readable, or is it a game and you can throw in some more exotic fonts to make it fun? Is there some little colored animal (like the red Angry Bird or the green Evernote elephant) that you want to build your brand image around? A yellow crocodile, perhaps? Or a turquoise turkey?
Backlog/Feature Management: Trello
Trello is an incredible piece of software, and I would highly recommend it for any small team, not just teams of developers. The basic idea is you start with a board. Then you divide your board up into lists of cards, which can be individual tasks or checklists, and assign owners to each one. Each card can include comments and comments can mention individuals or everyone on the team. If you have the mobile app, you can customize push notifications.
It’s a great way to organize development work — for example, at Wiblits we always had a “Todo This Release” list which contained all the tasks we needed to complete before our next app update.
Project Communication: Slack
Slack is a good app for keeping track of discussions and is especially great if you’re not working in the same room with team members. There’s also a pretty cool Trello integration that allows you to create cards and assign them to people from within the Slack app using a few keyboard commands.
Doing proper QA testing for new features on multiple devices, screen sizes, and (for web) browsers is hugely valuable, so I would recommend incorporating a testing flow into your release life cycle. I’m sure this is obvious to seasoned developers, I’m just going off my own experience.
I developed a QA checklist that my team would run through before shipping each release, that included things like creating an account, following a user, purchasing an item, and a lot of other common app use cases. A lot of times you can’t anticipate what might be affected when you make a change or add something.
Deciding on which technologies to use is definitely important to the success of the app. There are a lot of options out there, but they can be costly, hard to learn, or not well-maintained. Researching, networking, and general involvement in the programming community are a few ways to put yourself in the best position to decide on a certain tech.
In Part 1, I discussed the stack I’m using, but here are a few more topics of discussion.
Version Control: Git
Git is a great tool for managing changes to a project and makes it easy to share app development across a team. If you’re a developer you’re probably familiar with it and most likely better than me, but it’s worth mentioning. Pull, make changes, commit, push.
Continuous Deployment: Docker
At Wiblits, we used Docker images for our servers on AWS. This allowed us to update servers just by making a change to the git repository instead of having to create a new archive and upload it to AWS each time. It’s a small thing, but a pretty cool time saver over months of working on an app and constantly making changes.
In the beginning, you need to decide what platform is going to work best for your app. Take CookMe for example. Would it work better as a web app, or mobile? Web would be nice because entering a bunch of directions and ingredients is kind of rough on a touch screen. But the goal would be for people to be able to follow along with their recipes in the kitchen, and not everyone has a portable laptop. A tablet app would be good for some extra screen space since you don’t really want to scrunch down and look on a smaller phone at the directions while you’re working in the kitchen. But again, not everyone has a tablet. So best would probably be to develop for all devices, and let the user pick which one works best for them, yeah?
For mobile apps, a decision also has to be made on whether to start with iOS or Android, and down the road, if and when to add the other. I think most startups begin with iOS because it’s easier to develop. However, Android has a bigger user base. Having both can potentially double or triple your downloads (or even grow exponentially if there’s organic growth), but there are downsides. When you’re early stage and still figuring out your product, it often makes more sense to stick with one and iterate on it until you get the product you want, then build for the other, or you risk spreading yourself too thin. It all depends on your specific situation and the resources you have available. React Native or Xamarin can alleviate some of the pain of cross-platform development by allowing you to work with a shared code base.
Keeping up-to-date on tech can help you make better decisions on when to switch or add a new technology to your app. Wired and TechCrunch are a couple good publications that follow tech trends, interview big names in the industry, and attend major tech conferences, so you can keep posted on what the big boys like Apple, Google, and Facebook are doing. Should you scratch your Apple Watch app and start building for augmented reality? Choose your own adventure! (Turn to page 24 to find out.)
Well, that was a lot. And again, this is just my way of doing things. By no means am I saying this is the right way or the only way. There are a lot of great solutions out there for developers, which is awesome because it keeps getting easier and easier to develop great apps!
But, you ask, what happened to CookMe? The app that was going to top the charts on the App Store? We barely mentioned it at all!
Find out in Part 3 of this series!