Growing up in the 90's has truly impacted my love for computers. Their development from extremely useful machines to the life-dominating pocket sized devices during my younger years has heavily inspired me. I dedicated most of my earlier days to finding new ways of making my life easier with computers of all kinds. However at some point being a mere consumer of devices, software and services was not enough anymore. For a long time I had pursued a career in business up until getting my masters degree. Eventually I realized though, that my urge to work with technology would only be satisfied if I became a creator myself. And so I finally set out to follow my heart and enroll into computer science studies. Immediately I was consumed by my new world and my hunger for learning. At this point only hard work separated me from achieving my goals. This was one of the most relieving and revealing experiences of my life thus far. From here on out I could proactively shape my world instead of hoping a solution that I required had already been realized by someone else.
But let's take closer look at my later teenage years, to understand what it meant for me to get to this point. When the first iPhone was revealed in January 2007 I was psyched. The combination of advanced mobile software and a straightforward user experience meant for possibilities that were unseen in phones before (except for a few smartphones aimed at the business user niche, but even they did not have rich email and full desktop like webbrowser support). It really felt like a gate to the future had just been opened and Apple allowed all of us to skip 5 years ahead. Upon the initial launch of the iTunes App Store in 2008 I was stoked about the new opportunities of third party software. At this time I already eyed at making mobile apps, but lacked programming knowledge. Ultimately my personal educational path did not allow me to pursue this endeavour. I guess I was somehow funneled towards this road and deep down I knew I wanted something else. At that point I just could not grasp it, even though to an outsider it reader it may seem obvious. But I lacked the right persepctive. Finally after mastering multiple degrees in business administration, a lucky coincidence helped me to find my true calling. It achieved an understanding of my personality, which all of these career days at school nor study consultants could ever accomplish. It finally opened my eyes and relieved me of the bias I had towards potential (safe) career choices for myself. On that special night I was back in the town where I went to university for the first time for my friend's birthday. With an old acquaintance from back in the day I had a talk pertaining computer science studies. Hearing about all the aspects you learn there and about the type of person that is best suited for this course was like having my own profile read back to me. The next day I applied as a student.
Consecutively in October 2015 I wrote my first ever lines of code. Learning my first ever programming language (Java) was a very enjoyable process to me. I had no difficulty completing an incredibly fun semester. Then the winter break hit me and I wanted more. I had just gotten a small taste and I was hungry! Having learned a lot of new skills without much effort, I knew this was not the end of my road. This was just not the time to be lazy. I was ready to learn yet another programming language, to finally bring apps to my personal devices. As a day 1 iOS user Swift was the natural choice. While on the train towards my girlfriend's place, I found myself deep into the according literature. My first Swift coding baby steps can be seen in the following pictures. It was challenging to get over the first hurdles, since during the semester we had only developed simple command line based programs. Especially the interface Builder took a couple of days of getting used to.
Initial trial app, constructed while using Xcode for the first time
The initial idea for the app DayCalc came to me during my university studies in Kaiserslautern in early 2015. This was my first entry into computer science after completing my Masters Degree in Management. Unfortunately I did not learn coding there. Therefore it would take another year from that point onwards, before my idea could be moved into the production stage. As a student a day full of lectures is the standard scenario. Back in Kaiserslautern they would sometimes get cancelled, leaving me with the task to recalculate how much time I had for example in order to grab an unplanned lunch somewhere in town. There had to be a more convenient way than to calculate this from all my calendar events, which I had meticulously entered in the first place. Of course once the lecture was closer at hand this calculation would be performed more frequently to make sure being punctual was still a go. I deemed the solution to this issue to be a fairly simple app to realize, helping me to get into iOS coding. From there my plan was to create more challenging mobile software.
When I eventually began construction during my semester holidays in early 2016, Xcode introduced me to a steep learning curve. Adapting from Java to Swift was easy. Once you know the concepts of one object-oriented programming language, learning a new one is painless. Especially when the two are relatively similar. Building my app however did not require the deep skill set I had acquired for the Java programming language. Rather the spectrum of app design element I never had to deal with before required my full attention. With the help of tutorials (Stack Overflow is an incredible resource) I was able to advance quickly though. Knowing how to program definitely accelerated my understanding process. It did not take long to build some basic features for my app. In hindsight I would conclude that with an affinity for building software and an online class to get into coding, it could be similarly easy for anyone to become an autodidactic app developer.
Although my idea focused on a specific function, I decided to start off with more basic features. On the one hand they were very good additions, bringing more depth to my app, on the other hand they served as a base camp for my code learning journey. Early versions of DayCalc therefore included a day calculator, and later also a way to save dates and see how many days were remaining or had passed since that point in time. Very quickly I mastered Table Views, Tab Views, Navigation View Controllers, Segues and Layout Constraints. My graphic design skills, which I had trained by running a YouTube channel for a couple of years, payed off, as they helped me designing logos and icons with ease. Within only a few days I had produced something respectable.
Early version of the DayCalc app
From the screenshots it is evident, that I was merely scratching the surface of good interface design. I experimented with colours and positioning of my interface elements for quite some time. Apple's Human Interface Guidelines further deepened my understanding of bringing joy to app users. The design process also helped me to better understand the fundamentals of Swift coding, as I was frequently updating many elements of my app (which also required reworking the backend code). The next version of DayCalc improved the visuals and added new features. Though in the end even those UI ideas were discarded.
Interface redesigns during the early development process
While I was reading tutorials my understanding of Swift swiftly expanded, enabling me to include more and more little features into the app. One of them was the ability to hide the date picker until the user tapped on the table row that showed the selected date, just like it would happen in Apple's stock calendar app. Now an easy two minutes of coding, back then it meant hours of work for me. For a long time I had a lot of respect for building these UX improvements for the first time. However knowing that the right tutorial would lead me to success, made me tackle them without being afraid. I progressed continually, checking off one bullet point from my to do list at a time. It was an odd process too, because my understanding of how Apple made the interfaces for their own apps deepened. And that de-mystified them for me (not to say that I no longer have immense respect for their software).
March had come and my next semester was just commencing, which required me to focus less on my app. Eventually I took a break for over a month. Heavy duty assignments shifted my focus towards Java and I did not yet feel comfortable mixing it with Swift.
Expanding the feature set of DayCalc
After some time I got back onto the horse, with more spare time at hand. My goal was to make the app as comfortable as possible for the user. DayCalc should complete all the necessary work and settings proactively in the background, as well as only provide the user with the interface elements and information required right at the current moment. For this reason I began paying closer attention to other applications, mostly the stock iOS software. Studying their UI and UX helped me expanding my list of necessary features. Furthermore it really made me question my current UI design approach. The realisation triggered me to refine all of my interfaces using static table views. They enabled a much more professional look and feel. Furthermore static table views make it very easy to expand the app's functionality and help to incorporate features such as dynamic type.
Redefined UI using static table views
Now it was finally time for building my app's defining feature. Feeling confident with the current design, one last tab in the tab bar was missing before I could move on to building a widget and a watch app. From there only acts of polishing (for example adding multiple language localisations) would be required to finalise version 1.0. Building the calendar countdown was only another day of reading tutorials on how to access the user calendar. Setting up the timer was effortless. Et Voilà DayCal's feature set was complete. Basic versions of all functions were present, granted in a very early form.
First complete version of the DayCalc app
Creating a widget and a watch app was a smooth process. Most of the underlying logic could be reused by taking the code that already existed within the main app. Therefore the widget was completed a day later, the watch app just 24 hours after the widget. The UI design was still at a very early stage and for the most part not delivering on my UX promise. It did burden the user with unnecessary information and confusing elements. Especially regarding watchOS' specific Swift coding and its rather limited UI sandbox made me spend the next few days learning the ways.
The three initial iterations of the watch app's UI design
The next week and a half were exclusively spent on setting up a developer account. Doing things for the first time can seem very difficult, especially when you are required to fill in information hardly anyone can help you with. For the most part I was clueless and unable to find any information on how to fill in the contracts either. Trying many different keyword searches did not yield any success. In my desperation I was close to making only free apps or paying a tax consultant. However I am not a person to give up or make compromises. I had a goal and I wanted it that way. So I doubled my efforts. With the help of some blogs I finally stumbled upon, enlightenment was granted to me. They specified how to fill in the forms. Especially the space for entering an article number from the "CONVENTION BETWEEN THE UNITED STATES OF AMERICA AND THE FEDERAL REPUBLIC OF GERMANY - FOR THE AVOIDANCE OF DOUBLE TAXATION AND THE PREVENTION OF FISCAL EVASION WITH RESPECT TO TAXES ON INCOME AND CAPITAL AND TO CERTAIN OTHER TAXES", in order to claim the relief from double taxation had me confused at first (it is article 23 by the way). Eventually I also figured out that I would need to set up an US tax identification number (TIN), if I wanted to sell any of my apps for more than "free". Getting a TIN may take from a couple of weeks up to a few months. Understandably I was not too stoked about that outcome. Luckily sole proprietors can file for an employer identification number (EIN), which only takes a short phone call to the IRS, not counting the 45 minutes in the caller queue (and then some waiting until your confirmation letter arrives; they say two weeks, but mine took at least five).
I spent most of the following week further refining the interface of the main app, the widget and the watch app. One of the most notable changes was bringing calendar colours to all three variants of the calendar countdown. Additionally I fixed the widget in order for it to no longer show a second (empty) event, in case that there was only one more calendar entry during the next 24 hours (another promise of my UX approach).
Screenshots of a near final build
Hitting this stage made me very proud of how far I had come. My app was already exceeding my personal expectations of what I would be able to achieve. At this point DayCalc was my daily standard way of viewing my calendar. It was a genuine pleasure seeing exactly how much time was left until my lectures (especially when hand-ins were due) and sometimes also knowing when they would end. Yet lectures are only one component of studying and the finals time came forcefully, with an increased workload. By Mid-May I was deep into mock exams and other assignments, which served as entry barriers to the actual assessments. I had to postpone work on DayCalc once more.
At the end of July I was finally free to pick up work for the last time. This last period before releasing the product was mainly dedicated to interface polishing, adding minor elements to the UI, removing some of the bugs and making the logic under the hood run faster. I also redesigned most of the logos and icons one final time. It took about a week and a half to complete the work, factoring in that not every day there was enough time to even launch Xcode. Then on August 4 my app hit gold.
Screenshots from DayCalc's gold master
Ready to upload to the App Store I had to do my final research. Submitting an app to Apple can be quite challenging, when done for the first time. You need to acquire a developer certificate for submitting apps, generate an app identifier, enter it all into Xcode and then upload app archive. But before uploading, it is necessary to create the app entry within iTunes Connect. It serves as a container for the build and also contains all the app descriptions, screenshots and other miscellaneous information that users will see in the App Store.
This sounds fairly easy but coupled with all the trouble you can run into, it may be a pinch more frustrating and could take a little longer than expected. The first hurdle was to enter all the correct bundle identifiers into the app's, the widget's and the watch app's plist files. Build 1 was auto-rejected due to having transparencies in the watch app's icon. I made them rounded, apparently iOS rounds them for you. Now I had to issue Build 2. After a rather long period of not being able to archive the app once more, I realised the issue was not the correct build number missing from the plist files. All the bundle identifiers had been reset. To my demise some other plist entries had also been changed. It took a while to find them all.
Uploading build 2 went slowly. In the meantime I was able to get a head start on filling in the info page for the App Store. The longest single process of the submission procedure was to generate screenshots for every iPhone family. Starting with the 3,5 inch iPhone 4S (the last 3,5 inch iPhone to support iOS 9), and the 4 inch phones, iTunes connect required me to also include screengrabs for the iPhone 6/6S, as well as the iPhone 6/6S Plus models. For every phone I had to set up demo events that would allow to show the calendar countdown in action.
Eventually it all came together. It was a great feeling to finally hit send. I did not care that it was 5am nor that I had just completely blown my regular sleeping rhythm. Less than 48 hours later I woke up in the middle of the night seeing a notification on my lockscreen. It was an email from Apple, telling me that my app had just been approved. I visited the link. DayCalc was live!
About the Author
Erik is a software developer, who specializes in mobile apps for iOS. He is passionate about designing user interfaces, practicing graphic design, as well as hiking, cycling and photography.
He currently works at Stocard GmbH and studies computer science at Mannheim University of Applied Sciences. In his earlier days Erik graduated from Mannheim University and Robert Gordon University with business administration and management degrees.