The Journey of Creating My First Real App: SleepyPug
Awesome, you’ve committed yourself to learn iOS Development and have stumbled upon the cold truth that in order to call yourself an iOS Developer, you must build an iOS project and deal with the problems that are bound to happen as if you were building the project for a client. Well, that’s what I thought at least, and fortunately I was right: in order to be a confident iOS Developer, building a personal project is a great way to propel yourself into the iOS Dev world and learn new skills. You can watch as many online courses, go to as many classes, or read as many books as you want, but nothing will improve your skills more than building your own project.
What I wrote below should be viewed and considered as a “journal”. I give advice, and explain the processes that I went though and why they were important (also what I could’ve done better). Hopefully, by reading this you will feel more comfortable tackling a project of your own. Enjoy.
The most important thing to determine before beginning any project is to decide on a clear purpose for said project. For me, that purpose was to become a more confident iOS Developer. The purpose is general and simple in my case, but crucial for the project. It acts as the roots for the entire project. Once I was set with my purpose I could decide what was important for this project to be successful and what was not. For instance, it was not important for my project to hit the App Store, or be useful in any way. However, it was important that I was building something fun, so that I wouldn’t be too quick to give up on the project in challenging areas, difficult so that I could learn new techniques, and more that a simple app so that I could learn the structure and workflow of building a full project. Based on this self-defined criteria, I brainstormed potential app ideas to build and came up with SleepyPug: an instant bedtime-story messaging app. Why did I choose this project? Because I knew that I’d have to implement an audio library which I’ve been told isn’t too simple, and social networking features. Both of these would be something that I could imagine myself having to implement in the future. Most of all, the concept interested me, and I knew I’d put in enough effort to make it happen.
Advice summary: Find your purpose first with any project, and ask yourself what you want to get into. Search for a concept that you’ll be somewhat passionate about. It’s VERY easy to give up while learning iOS Development, so make sure it’s something you could see yourself finishing.
This phase is the only phase that overlaps with my design process, and with that being said, challenge yourself *graphically and try to stay away from easy to implement interfaces. For me, I was very anxious to start coding and in my opinion didn’t dig deep down enough if I was in my designer boots. Fortunately, it was fine because this wasn’t intended to be a design *project.
Enough chitter-chatter: Start by sketching everything, and get all your ideas out. Check out some similar apps, and figure out what features a potential user would want. Most importantly, experiment. Try different things, go in different directions, and compare, that’s the easiest way to discover and create cool stuff. Here’s what some of my sketches looked like:
Flow is also extremely important, so map out your flow (you can see what I did) and revise your sketches until your flow makes the most sense for the user. Once again, experiment with this, as your app should be navigable, and simple to understand. ALWAYS ask yourself where potential user’s frustrations may be and revise them. The most important skill a designer can have is user obsession, so make sure to always be considering the user. The beauty with sketches is that the revision processes is easy, that’s why you should always push for another revision even if you think that you *can’t. Seek other’s opinions if possible.
Like I said, if this was a meant to be a design project (it would be if you were building a real app), I’d go into much more depth about this process. If you’re interested in knowing more about this phase, read this or this. If you’re purpose is to learn iOS Development, do this step, but I’d suggest to not over obsess with it — focus on your goal.
Advice Summary: Don’t skip this step, even though you’re learning iOS Development, knowing how to brainstorm is an important skill to have. Consider designs that can’t be easily implemented using Xcode’s built in GUI elements. Sketch everything down, and maintain a heavy revision process. Always consider flow, and user frustrations.
*graphically: So many iOS Devs don’t know how to implement GUIs too well, and it drives designers crazy. Make sure that you learn skills that will make you a well rounded developer.
*project: You defined your purpose, so make sure to stick to it.
*can’t: Let your entrepreneurial instincts kick in and start to think of marketing tactics that can be incorporated into design. In my sketches I created a full invite process with marketing tactics in mind.
By now, your creativity is hopefully flowing, and you’ve settled on a concept and design. Now, face reality. Draw the line between features that are challenging, and features that are over the top difficult and unnecessary. You can do that by researching what it takes to create certain pieces of functionality in your app. The reason why I did this was so that I could make sure I would finish the project. Keep a list of all of the functionality that you’re stripping off of your project to potentially include after you’ve finished your app.
Next, I decided to hop into Sketch to start creating the UI and simple branding for the app. I tweaked something here and there, but the majority of my app stayed coherent to my sketches. Hopefully, you know how to jump into Photoshop or Sketch to convert paper to pixels. If not, don’t stress about this; you can hire someone on Fiverr, or just do it all in Xcode based off your sketches (just try to make a more detailed revision of your sketches).
Advice Summary: Make sure you’re creating a trail that you can reach the end of, and research what you’re getting into. Dim down challenging functionality that isn’t essential to the concept of your app, and write them down for later. Start to convert your sketches to pixels, and finalize the look of your app.
Finally, start to code. Make sure that you feel confident with the last two phases before proceeding. From this point on, you don’t want to have to think about UI or UX as it’ll distract you from your coding process. This is where your previous iOS knowledge and research comes into play; most of the time the hardest part about starting to code is figuring out where to start to code. Because I was creating a *social network, I couldn’t create much without a specific user to experiment with. In order to have a user (surprise), I had to start with the Signup and Login process.
For me, I found a few techniques helpful to start your project and new functionality:
- Break down your functionality. Similarly to our Brainstorming process (Phase 2), start with the functionality’s purpose, and them come up with solutions for an executable plan. For me, I found that I could analyze and revise plans better once I got them out of my mind and in front of me in paper.
- When building ViewControllers, start with UI whenever you can. Build out the UI the way it should look, and then plug in the functionality. This will create a natural roadmap, and a template for your functionality. If you do things the other way around, I find that developers have to go back and change their functionality (sometimes completely revise it).
- Create a todo list to keep track of functionality that has yet to be implemented.
- Research what you’re doing (I know I say this a lot) because someone’s done it before you.
Feel confident, it is possible to do what you’re doing. However, whenever I became overly frustrated with a bug, error, or I couldn’t’ figure out how to build something, I hopped on CodeMentor, and called one of the mentors to help me out. Don’t resort to this, but it’s better to spend $15 on code help, than $1000 on a new computer because you smashed your old one; CodeMentor is a good backup plan.
You have to learn to expect bugs. Sometimes the simplest things will create the errors that take hours to figure *out. If you research your error, and you keep trying to solve it, you’ll figure out your bug. What’s important to remember is that this is where it’s easiest to give up on your project and it’s also where you learn the most. You’ll quickly realize that you learn the most during the periods of frustration.
Advice Summary: Consider using a notepad to break down plans, and start with implementing GUI in Xcode. Always remember that nothing is quick in the coding world. Expect delays, and expect bugs. Once you get one, keep pounding away at it until it works. Never give up, and Google and read documentation to research your errors. If necessary seek help on Code Mentor, or from iOS Dev friend.
*social network: For simple backend implementation, I’d recommend using Parse. It’s very simple, and for the most part free if you’re planning on not releasing your app, or if it doesn’t have a lot of users.
*out: If you’re like me, when you started developing your app, you didn’t know how to properly debug with breakpoints (until someone on CodeMentor looked at my strangely and explained it to me), so learn how to do that because it’s the simplest way to squash a bug (you can do that here).
Before you tell yourself that your project is done, consider accommodating for these things:
This is obvious, but often missed. Organization is all about the simple things, like naming. If you didn’t decide your naming conventions before beginning, create one, and go back to change your names. Naming is important, if you have a system for naming things, while coding up complicated functionality you’ll have one less thing to think about (not to mention it can cause tons of bugs). Also often missed is commenting. You’d ask yourself if it’s really necessary and the short answer is yes. Commenting can help you think through problems, and in a scenario in which you’re required to update a certain piece of software, commenting can be a great way to catch yourself up and act as a huge time saver.
Go back and optimize your software. Especially with new functionalities and as a beginning developer, you’re likely to code up things until they work. Once they work, you move on and that’s that. Now that you’re done with your project, you might have a few tricks up your sleeve and a new view on how that piece of functionality should work. So, make sure to go back and re-code anything that may not be fully optimized.
Not a lot of people think about this, but it makes a lot of sense. You spent hours getting something to work, why not make sure that you don’t have to do that for the same thing in the future? Functionality that could be used in the future should be built for reusability. This means that it should be optimized, and versatile.
Don’t underestimate this step. You can learn a lot of things, and you’ll be able to save yourself (or maybe someone else) a lot of time in the future.
Advice Summary: Organize the shit out of things, become obsessive over organization. Optimize as much as you can; by doing this, you’ll be able to optimize your code as you initially write it. Revise for reusability, and create of references to projects where you have reusable functionality.
Hopefully, this article has hit it’s goal and has made you more willing or more comfortable to attempt a similar project of your own. If it hasn’t, or if you disagree with anything that I said, I’d love to chat: you can email me here. Also, if the project did help you in any way, I’d love to know! (Please reach out to me with the email above).
Lastly, follow me on Medium, and follow me on my social networks and lets make sure to keep in touch.