What I learned From Releasing My First App

I just recently released my first iOS app to the App Store (yay!) and in the process, I’ve learned some things, a lot of things, which maybe someone reading might find helpful.

Wait, what app?

Let me quickly plug my completely free app, called GradePoint which is what this article will be discussing.

GradePoint is a simple and easy to use iOS app for students who could use some help keeping tracking of their grades in school.

Being a student, I always found it frustrating that some professors would update grades using an online service while others would wait until the end of the semester, and you’re left in the dark the whole time. Sure you could keep track of all your papers, but no one has time for that. There should be a decent app for that, and that’s what I, as a decent computer science student, decided to do.

Okay, let’s talk about what I learned and hopefully other newbies, like me, can learn a thing or two.

Developing a decent app takes time

This may sound obvious, of course developing an app takes time everyone knows that. But it takes even longer when you’re the only one developing for it and you’re a full-time student/intern. When I first had the idea to make this app I figured this would take no longer than a month or two, and sure something like this could easily be done in that time frame. However, I wanted to write everything myself (no 3rd party libraries, besides Realm). After all, this was a learning experience, I wanted to learn as much about iOS, Cocoa Touch, and Swift as possible.

So the fact it’s taken over 7 months, way longer than I first thought, has taught me not to underestimate how long it takes to make something which I would be proud to release.

When I started
When I “finished”

Not only is making sure to not underestimate the length of the initial development time something that I learned but also once it’s in the App Store this is now an application that I must be responsible for maintaining. This is something, I think, many newcomers like me don’t completely grasp. Once a project or some piece of code has been made available for others, you’re now somewhat responsible for making sure this project stays maintained and working, and this can definitely become a hassle. So next time you have a super cool idea make sure you’re willing to commit the next year or two to working/maintaining this idea.

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. 

 — Tom Cargill, Bell Labs

Building your own views is fun

Before I started working on this app I didn’t have much experience creating any custom views for iOS. I used to use all the built-in views that Apple graciously provided us with UIKit. However, these built-in views can’t do everything. For this app, I needed some sort of circular progress ring which would display the grade percentage for a class. There are a couple of these view libraries on GitHub, but remember, I wanted to build all of these things myself so I set out to do that.

A view created for this app

I looked at some online posts and StackOverflow questions on creating custom views, and how the drawing works. From there I quickly prototyped what I wanted to build and then spent the next month or so, making this view as good and as nice to use as I could. I spent so much time on it I decided to put it on GitHub and CocoaPods, and now it’s become quite popular (which goes back to the issue, of maintaining and being responsible for updating). But all in all, I learned an immense amount of interesting things that can be done using custom UIView’s and it has helped me think about how to create my apps differently. If you have never built a custom view, give it a shot.

I suck at designing

I’ll keep this section short, while I definitely don’t think the application looks ugly by any means. It’s for sure not the most eye catching or interesting app out there, and I’ve absolutely learned how important and game changing good design can be.

Hey Siri, remind me to take some courses on design.

Plan, plan, plan

This is probably the #1 thing I learned while working on this project. I’m still new and learning so I didn’t quite plan everything out, I mean sure, I had an idea of what I wanted to build but not really a _how_ I was going to build it. I also didn’t have a project manager working with me either. So this is the biggest mistake I made while working on this app, and it happened before any work even began. Planning is crucial because it helps keep you focused and also stops feature creep from consuming your life. Obviously, things change and plans must be updated but try to start off with a solid plan of what you want. Not just an idea, actually plan things out. You can use an online program planner, like Trello or even GitHub issues and close them off whenever you finish.

Push yourself to finish

This is something I struggled with constantly while working on this project. It’s easy for me to want to drop something I’ve been working on for a while and move onto something more interesting or fun. There were weeks where I didn’t get any work done and decided to do something else. It’s healthy to have a balance but always try to stop yourself from dropping something entirely.

While pushing yourself to finish also try to make meaningful progress, by this I mean don’t spend a day refactoring your entire code base just because you’re really annoyed with the way you named certain things (I did this). Meaningful change would be implementing that feature you posted on your Trello board or fixing that bug you found a few days ago. It’s easy for us developers to look at the code and want to make it better, but really I don’t think I’ll ever be 100% satisfied with the code I write, there will always be a better/cleaner way of doing something. The end user won’t know the difference if it’s something minor. I am not at all trying to advocate for bad code or design but maybe save the refactoring and cleanup for after the release.

No one is better at breaking your app than other people

Seriously, if you can get your app in the hands of others before you decide it’s “bug-free” then do it! As developers, we sometimes focus on smaller aspects of developing and design. I can’t tell you the countless times, at work and while working on this app, that I thought a feature worked just fine before I gave it to my brother or a friend to try it out and they immediately broke something. Which is good, I don’t want a feature to break while it’s out in the public. I want to know about it and fix it as soon as possible. Hmm, maybe I should write more tests…

If you don’t have any close friends who can test your application, then try publishing it to Xcode Flight Test and post a link on some social media platforms asking people to help you test. For GradePoint I had 20 people just trying out the application, and while not everyone gave me feedback a few did and I listened, I feel like this definitely helped make the app better.

Don’t be afraid of criticism.

Final thoughts

It was definitely fun working on GradePoint, even though it was also very difficult and frustrating at times, overall it was a good experience. I learned a ton of things and hopefully others can now enjoy using something I created. If you’re new to software development then just sit down for a few days and try to build something. Don’t just go to class and expect to come out an amazing developer. Try your best to do things outside of school/work and keep improving your skills. It doesn’t have to be anything amazing or great, but learning is never a bad thing. If you need more advice or want someone to help you test an application, don’t be afraid to contact me!