Traveling to the New Territory I used to work as a web application developer in and I started working as a mobile app developer about two years ago. my previous life I learned Swift from an 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. AppCoda book At this point, you might be asking: Why would I spend months on just a framework — — after I was able to create my first app in months? four which is not deliverable by itself two And some of you might ask: If I could go back in time, would I create the framework my first app? before My answer to both questions is: I’ll probably if I can make my choice again. do the same And I am going to tell you in this article. why 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 which seemed to be a good option for providing cross-platform support. But unfortunately, after spending a large amount of time, React Native . 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 support iOS. About an hour later, I was able to build a HelloWorld app with and to run it on my iPhone. only Swift I was relieved — — to finally create a runnable app after all those time spent on researching as well as bootstrapping. beyond words 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 and of different sizes. Figuring out how to fulfill the before my app could be approved also took me some time. app icons screenshots metadata requirements 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 development tasks into QA ones. I told myself I was going to repeat that in the second app. enjoyable tedious not So before starting on my second app, I knew I had to build a framework of reusable modules. Going from a wishlist, I narrowed it down to four basic modules: Automated Testing, Logging, UI Layout, and Data Storage. long Then I started my quest to build each of these four modules. Gearing Up to Go Again I was expecting to spend about months on building the framework — but it turned out to be months. two four Still, I didn’t regret any minute of it. It was to directly implement a feature in an app. It was learning experience to create a reusable module for the same feature. one thing an entirely different For instance in handling UI Layout, the iOS platform already provided the architecture. There were others — like — some developers were using because of some shortcomings (they believed) in MVC. MVC MVVM or VIPER After some lengthy research, I believed for what I needed in my app. So I just created some MVC helper methods in my UI Layout module. MVC was good enough On the other hand, iOS had built-in classes — — for Automated Testing. But there were popular frameworks from and that could do even more — like . Thus instead of helper methods, I created proxies to wrap around the iOS built-in classes in my testing module. XCTest and XCUITest Google Facebook Snapshot Testing 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 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. by no means What I 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. would 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 ’s when the journey truly begins. that
