My Second Mobile App

Traveling to the New Territory

I used to work as a web application developer in my previous life and I started working as a mobile app developer about two years ago.

I learned Swift from an AppCoda book and created my first iOS app in two months. Then I spent four months to build a library of reusable modules — or “framework” in iOS terms — for preparing my second iOS app. 

At this point, you might be asking: Why would I spend four months on just a framework — which is not deliverable by itself —  after I was able to create my first app in two months? 

And some of you might ask: If I could go back in time, would I create the framework before my first app? 

My answer to both questions is: I’ll probably do the same if I can make my choice again.

And I am going to tell you why in this article.

Getting off to Rocky Start

Right from the very beginning, I knew my first app wouldn’t be perfect no matter how much time I spent on it. So I only wanted to create something simple — but good enough — that I can build on top of later on.

I had learned from past experience the difficulties of adding platform support at the end of the software development cycle. Thus, the first requirement I gave myself when designing the app was cross-platform support on iOS and Andriod.

I started my research on what options were available at the time. I came across React Native which seemed to be a good option for providing cross-platform support. But unfortunately, after spending a large amount of time, React Native didn’t work out in my case. 

I was back to square one. 

At that point, I had spent more than a month on just researching, without writing a single line of code for my app. I was frustrated and I asked myself: Should I go back to try another option on cross-platform support? Or should I focus on one platform for my first app?

I struggled with myself for a few hours, then I made an important decision for my first app — it would only support iOS. About an hour later, I was able to build a HelloWorld app with Swift and to run it on my iPhone. 

I was relieved — beyond words —  to finally create a runnable app after all those time spent on researching as well as bootstrapping. 

And I was ready to start coding my first app.

Finding the Shortest Possible Path

Having decided to focus on iOS, my direction became much clearer. What I needed was to create an iOS app and submit it to the Apple App Store, no need to worry about the Google Play Store for Android apps.

After some reading online, I understood the App Store submission might not be always as straightforward as expected. The review process could sometimes take a while.

So I made another important decision for my first app — it would be the simplest app I could create. This app would serve as my “test” app for the App Store before creating my “real” app. 

Because I wanted to go through the whole submission process from end-to-end as soon as possible. The last thing I wanted to end up was, spending a year to create my feature-rich “real” app and then getting rejected from App Store.

Thus I spent about two months building a coffee diary app based on the tutorial app from the AppCoda book. 

Then my first app was done and ready for the App Store.

Stopping Briefly at the Destination

The App Store submission was another time-consuming process for me — or any first-timer. Because it involved a lot of non-development work. 

Not only I had to fill in all the app information required on the website, but also I had to create the app icons and screenshots of different sizes. Figuring out how to fulfill the metadata requirements before my app could be approved also took me some time.

Long story short. It took me almost three weeks to go through the whole submission process. I would expect my second app to take less because now I knew what to expect and what tools I could use in each step of the process.

Anyways, after the first app was launched in the App Store, it was time to start my second app. 

Preparing for the Second Trip

Creating my first app based on the book tutorial one was a good starting point. Because I was able to reuse two essential modules— the UI Layout and the Data Storage. But for obvious reasons, the tutorial app didn’t provide other important modules like logging and testing. 

I was using simple print statements for debugging and doing all the testing manually. It quickly turned all my enjoyable development tasks into tedious QA ones. I told myself I was not going to repeat that in the second app.

So before starting on my second app, I knew I had to build a framework of reusable modules. Going from a long wishlist, I narrowed it down to four basic modules: Automated Testing, Logging, UI Layout, and Data Storage. 

Then I started my quest to build each of these four modules.

Gearing Up to Go Again

I was expecting to spend about two months on building the framework — but it turned out to be four months. 

Still, I didn’t regret any minute of it. It was one thing to directly implement a feature in an app. It was an entirely different learning experience to create a reusable module for the same feature. 

For instance in handling UI Layout, the iOS platform already provided the MVC architecture. There were others — like MVVM or VIPER— some developers were using because of some shortcomings (they believed) in MVC. 

After some lengthy research, I believed MVC was good enough for what I needed in my app. So I just created some MVC helper methods in my UI Layout module.

On the other hand, iOS had built-in classes — XCTest and XCUITest — for Automated Testing. But there were popular frameworks from Google and Facebook that could do even more — like Snapshot Testing. Thus instead of helper methods, I created proxies to wrap around the iOS built-in classes in my testing module. 

So that I can easily switch from the iOS built-in classes to other popular frameworks later on. No need to worry about affecting my app built on top of the testing module.

Nevertheless, with the whole framework completed last month, I can finally work on my second app with minimum distractions.

Looking Back from the Present

In retrospect, I would probably choose to go the same route — building a simple first app, a framework, then a second app — if I could go back to redo everything.

But I am by no means suggesting this is the best route for everyone to develop their mobile apps. People from different backgrounds will take different routes to suit their own circumstances. 

What I would suggest is to start with something — not just simple but also — easy to build. Then launch the app to the public, right after the first release is completed.

Because releasing a mobile app is quite unique, comparing to other types of software. Going through the whole process sooner rather than later will help to fully understand what it takes to create the next app — the “real” app.

And that’s when the journey truly begins.