How I Dove Head In To Make A Mobile App With Zero Experience
As a graduate from DigiPen that majored in Computer Science and Game Design, I’ve been predominantly exposed to PC and console game making throughout university. While there are still plenty I haven’t learned in these 2 gigantic platforms, the black box that has always eluded me happens to be the elephant in the room; the huge market of mobile apps, which has long overtaken the PC market.
So, despite knowing nothing about making mobile apps besides coding, I released Quick Guitar Riffs on Android by myself. And by myself, I meant from concept to release to marketing. So, this following post is a post mortem for myself, and a reference for anyone enthusiastic enough to dive into the black hole of mobile apps for the very first time.
Backstory
Building games are great and all, but my interest and curiosity for the mobile (non-games) market have been exponentially increasing each day. I see apps such as “Motivational Quotes” getting 500k downloads, or “To-Do List” apps getting over a million downloads.
To give you a good idea, most tutorials build a to-do list as a get-started demo.
That really piqued my desire (imagine just the ad revenue alone!), so I thought to myself, “let’s build a simple, existing app and put it out, since it’s for my own practice. That’s how we were taught to build our first games as well”. That idea was quickly dumped, because that would just be another blind copy. As if the stores weren’t already flooding with similar apps!
It might work for games, because it’s possible to repackage, rebalance, and modify some features of an existing game to make it refreshing. But since apps are functional-first, replicating for the sake of replicating felt ridiculous to me.
Also, I didn’t want to make simple info apps as well, because I didn’t feel like I could learn much from such a minimal type of app. With all these in mind, the brainstorming begins.
A Change In Perspective
Somewhere in between the brainstorming sessions, I attended a seminar with a friend, on the topic “how to build apps without knowing how to code”. Of course I already knew it was about outsourcing, but at that moment, I thought it would be interesting to see what he has to say.
The talk was mainly directed at an audience that wants to build a side income, and in this day and age, building apps is a viable way to do so. He breaks down the 4 types of apps in the market: the info app, the utility app, social apps, and games, along with the ways anyone can outsource, deploy and market them.
His first idea was a recipe book of a specific diet, with recipes he got from his circle of friends. Give him 1 recipe, and he will give the contributors the book with 77 recipes for free when it is released. He then converted it into an info app.
After a 2 hour session with a lengthy sales talk to join his outsourcing + marketing platform, I retracted the thought of not wanting to make simple info apps. On hindsight, my “programmer’s pride” might have to do with the initial resistance, that philosophical “I want to build something cool, groundbreaking, and world-changing!” train of thought.
So now it’s back to brainstorming, but this time opening up to info apps.
Ideation
About 3 weeks later, an idea suddenly hit me like a train. It was a personal issue at that, so it got me even more enthusiastic.
Problem: There are times I get stuck in a rut with my guitar playing. For me, sometimes it’s not just about learning all the songs I adore. There are songs I might not tap my feet to, but their riffs are fun to play. After learning them, it then starts to grow on me.
But if I don’t know the song names, how do I find them?
So, for years, whenever I arrive at this dilemma, I have been Youtubing for “100 Best Guitar Riffs” or the likes, to see what songs they’ve got. Then, I’ll filter songs that I like, and then for the difficulty level, because I’m no Slash.
Why don’t I automate this then? Build an app library containing all the cool riffs, with a difficulty filter, that allows the user to randomly select a song!
The interesting thing though, was that I only managed to conceptualize this idea because I opened up to the idea of making info apps, but it turned out to be more than that. That’s already one lesson on not restricting myself during ideation!
But that’s just the idea side of things. Other than coding it up myself, I had another goal; to do EVERYTHING by myself.
Now, I am not a lone wolf. I feel that the best way to get quality work is to capitalize on my strengths and outsource the rest. However, I wanted to know exactly what and how much work has to be put in for each aspect, for the benefit of knowing what I’m getting into when I outsource in the future. Since this project is small enough, I thought that is doable, with 2 challenges: artwork/UI, and the marketing side of things, which is a huge monster I have never tackled before.
I then began to prototype the project, transiting into the execution phase. I estimated to be 6 weeks’ of work, but little did i know my estimation was terribly off…
Execution with React Native
Now, I had a small list of features that I have planned to implement, with React Native being my weapon of choice. The next step was of course to draft out an action plan, where the work hours had to be sparse because of my full time job. A list of features and schedule, without knowing anything about the work itself. Hmm.
- Week 1: Setup, basic main menu, screen navigation
- Week 2: Setup all screens, creating the riffs page, data loading,
When I was creating this simple plan, I was already into week 2, and I was having a big problem getting the navigation to work, because well, I haven’t touched React Native before. So I thought, there’s definitely some hurdles, so taking unexpected delays into account, I should be able to finish it in 8 weeks, right?
Wrong.
It took me 12 weeks, and another 2 or 3 for the iOS issues to finish it, which totalled 4 months. You can refer to the summaries below the image as well.
Week 1–3
The first 3 weeks were pretty smooth sailing, after the main issue of navigation was solved. The main bulk of work was familiarising myself with React Native, and to build the skeleton of the app.
Week 4–6
The next 3 weeks were filled with much cursing. Almost every package added gave me that red screen of death, and troubleshooting these errors took up most of the time.
It was the main bulk of frustration throughout the project. Sometimes, it turned out to be an error in the package itself after an update, and the only solution was to wait for another patch. Other times the solution works, but in a contrived manner. But hey, that’s part and parcel of coding, right?
Week 7–9
The following 3 weeks were slightly more peaceful, because it was mostly tightening up and polishing the app, making it look better and more useable. It was also this period that I allowed some feature creep, after showing the app to some friends (yes this is important!).
Some added specs were: push notifications (how could I not have planned this?), song suggestions, and song choosing instead of randoming them. I figured that although randoming songs were the main feature, there are just days where users might just want to pick their guilty pleasure-ish songs. It would also be a clean way to browse through the song catalog.
Adding push notifications were, again, a battle with the red screen of death. I guess that was the only raging part during this 3 week window.
Also, I’ve added a “Full Tab” button at this point. This is because after putting some tabs in, I realised that I might run into legal issues, if anyone decided that this app was successful enough to jab. So that was one simple (but prominent) feature that creeped in as well.
Week 10–12
The last 3 weeks were hell. I had no idea I needed so much time scouring the tabs and song information! If you refer to the original plan, I only gave it 1 week. This was the biggest underestimation on my side, so I had to keep crunching data for 3 weeks to get it done. Being a data monkey was not.fun.at.all.
Other than that, it was a lot of IAP (in app purchase) testing, because it can’t be done on emulators. I had to keep compiling and releasing it on Google Play to test.
Some features are more app-customized, such as the “Wrap text truncation”. For normal text, any truncation can be spilled over to the next line easily, via 1 line of code. However, for tabs, since they are grouped 6 lines a set, they had to be handled differently. The main challenge was to make it look good on different screen sizes, but it wasn’t as frustrating as the red screen of death problems, where I was mostly helpless.
Week 13–16: Apple
But this app is not released on the iOS! What is this iOS version porting you’re talking about?
Well, there was intention for it. Long story short, the app cannot be released on the iOS because, as anyone who has worked on iOS can testify, they have very strict policies for apps. Quick Guitar Riffs was deemed to have copycat issues, because the tabs were lifted from other websites. I presume the only reason they found out is because they clicked on the “Full Tab” button I provided, the feature I added in in hopes of preventing these issues in the first place.
The long story: Since React Native was designed to make life easier for cross-platform porting, it would take an ostrich brain to not take advantage of it. I started looking into it since Week 8, delaying it till then because Apple charges $99/year for the license. I wanted to finish the Android version before porting, so that I maximise the 1 year window of license (read: cheapskate).
So I thought, I should try to create the Apple Developer Program account so that if there is anything weird they require, I can prepare it now before I am ready (and waste precious release time).
Fortunately I did, because apparently I needed this D-U-N-S number that I never knew existed, as I chose to set up my account as an organization instead of a sole proprietorship. That itself took 2 weeks of confirmation upon request. Not a problem, since I still had work to do.
Armed with my very own, exclusively tailor made DUNS number 2 weeks later, I resumed to register the account, but no! Now I need a website and an email. Not just any website and email, it has to be a custom domain. At this point, I was certain that my app would be making at least enough money to cover for these expenses (it had better be), so I proceeded to put those things together. How ironic that I felt relieved upon seeing the payment of $99, because it meant that my application is successful!
The timing was impeccable as well. Apart from some syncing issues with IAP (and data monkeying), the Android version was ready. So the next few weeks was spent battling the iOS version of the red screen of death (which are the same red screens of death), banging out a version 1.0 on the musician-centric platform. I then managed to release a free version of the app without IAP.
And then, I added the IAP entry. This is where things got interesting.
If there are any Apple Developers reading this, I’m probably making a scene to you, but I assume all Apple Devs had gone through this stage one way or another. When money is involved (IAP), the approval process feels nothing like the free version.
I wasn’t so annoyed at the problems itself, but more irritated that they had to tell me the issues one by one, bouncing to and fro for 4 different issues that exist in the first build. I feel like I’m that persistent suitor who just couldn’t get the hint.
So first up was that I needed a way to restore purchases if there is going to be purchase, which was fair enough. And then the weird bouncing of “you need to submit an app update with the new IAP to get it approved for use, but you need the IAP to be working in-app so that the app can be approved” paradox. It resolved automatically in the end, so I’m just gonna assume magic here. The third issue was something performance related.
The last one was the killer. It was a violation of copycat issues, as my app had material that looks similar to the guitar website, as mentioned in the opening paragraph of this section. Now for every issue Apple points out, they have to support it with screenshots. This means that they have taken many screenshots of my app, but only decided to break it to me now. Guess they didn’t have the heart to be direct.
The conclusion was that they couldn’t approve the app, so now I’m stuck with an Apple license, a website domain and an email domain.
With an app release on Android, using React Native, but no iOS version. You know, the ostrich brain.
On the bright side, that’s more motivation to build something to release on Apple now, and um to try and gain more website traction? By the way, this is my website. Yes this. Please click on it.
Advertisements
That wasn’t the only thing I was busying myself with during these weeks though. I had began reading up on advertisement strategies, Facebook advertising and Universal Ad Campaigns (UAC) by Google, in order to prepare to market my app. That, and creating the actual images of the ads. I need a course on “How to market without knowing marketing” more than “How to make an app without knowing coding”.
Also, I started spamming Youtube channels such as Overpass Apps, and App Masters, and reading up a lot on marketing apps. To the experienced gurus, the stuff they shared might be nothing much, but for me, it was one too many “a-ha!” moments jam packed in a session.
So, I started to run the above ad on Facebook, consisting of 3 images, for a few days. Utilizing the basics I have learned, I set a daily budget of $20 as a control, and tweaked some metrics every few days, such as the target audience and age group. After a few days, I talked to some of friends and realised I should make the images into an animation; that’ll garner more interest!
So I went back, combined and published these 3 images into an animation sort of ad, and surprise — They did worse than the images. The CPM (Cost per 1000 impressions) were 60% higher for the animation! By this time I’ve ran out of my budget, so that was my conclusion. But now I understood my target audience a little better.
I still suck at advertisement stuff, but it did open my eyes to a whole new world. I have never been interested on the sales/marketing side of things, so I never bothered with it (because it was always to focus on my strengths and outsource the rest!). But now that I have an actual product I want to push out, I amassed great motivation, soaking up all the information like a sponge. That’s one more bird I killed with a stone!
Art/UI
Ah, finally the visuals! I have always liked flat design, because it is simple/clean, and easy for my limited art skills to replicate it. To fake this art style, I just naively dissected flat design thru these observations:
- Only simple shapes that get straight to the point
- 2 tone hard shading
- The stroke effect to corner/separate elements
- The hard diagonal shadow on the lower left of the frontal images
These pointers formed the basis of building my art assets. Not professional, but not too shabby!
For UI, I had downloaded many info apps before I even started the project proper, and followed the most common and basic patterns during production. It also turned out to be a great exercise for me to be critical of what’s good and what I never want to see in my own app. This is also the only section where my game making experience helped a little.
Post Mortem
It’s been 2 weeks since the app is published at the time of writing, so I’m just observing the numbers before I decide if I want to add more features.
Looking back, I’m still amazed that I managed to squeeze in 3 to 4 weeknights per week to build the app. I had estimated 2 to 3 weeknights, but the burning desire to finish it fed my motivation further.
There were sacrifices of course. I pushed away many after work appointments, and couldn’t commit to the band I was playing with for that duration. Fortunately, I have an understanding girlfriend who supported my passion, so long as I don’t eat into the weekends. Which I still did, a little. Just a little bit.
With regards to the big picture, I’ve achieved my main goals:
- To push a quick and dirty version out for release, adding more features later
- To work on every part of the development process, especially the ones I have never been exposed to before.
The statement “Your cup is only so full, so to fill it with more, you first have to pour some away” holds water as well *ba tum tss*. Looking back, I should have slowed down the pace, instead of working into the midnight (even though that’s when I work best), so that it doesn’t affect my personal/social life. It should’ve been more of a marathon than a sprint, especially when I still have a day job.
Lastly, so long as I believe in the idea, have a schedule to track my progress, and begin with the end in mind (not feature creeping indefinitely), it is easy to build momentum and keep advancing. Also, I am solving a personal problem, so being an end user myself, the hope of releasing this solution for my own consumption is another powerful driving factor.
I’ve conceived a number of app ideas before, but they seemed too colossal of a task to be completed. Now, as I review these ideas again, they actually seem pretty doable (albeit with better scheduling). As they say, the first is always the hardest, so this might be the first of many more to come!
I hope this post-mortem/rant of mine gives you a better idea of the amount of work required to make an app, preempts you for the possible potholes you might encounter, and motivates you to create an amazing app you can be proud of!
