Everyone Starts Somewhere

1*y_5fmiIWApEpNgJ67CB5Gw.jpg
I mentioned in my previous post some shortcomings opportunities that my LotR Quiz app presented, and i'll be going into a few of them in this post to explain why it made a great candidate to work on and re-build from the ground up.

In January 2021 I remember miraculously finding myself having a FaceTime conversation with Ben Sullivan and Steven Berard, this was the first time I’d spoken to Steve and only the second or third time I’d spoken with Ben.

We were discussing whether or not Ben and I could pick up some of the hosting duties of the Fireside Swift podcast, one of my favourite Swift podcasts and one that had sadly been off the air since May 2020.

During this conversation we were discussing what direction we could take the podcast in and as part of that I was explaining my “journey” of how I’d progressed from ‘brand new newbie’ iOS Developer back in December 2018 to a slightly more ‘advanced newbie’ here in 2021.

I made a passing comment about my very first App Store project (LotR Quiz) and that I’d recently taken a look at it to make some updates and while doing so, noticed that the code base was understandably… hideous!

image.png

What went wrong?

Understandably we decided to delve a little deeper into some of the choices I’d made, and here are just a few that stand out for me:

Persistence:

At one point Ben asked how I persisted the database of questions, as well as which questions had been answered, or were still left to be answered. I explained that the app wrote a few different JSON files directly to the users ‘Files’ app on the device itself and will read that on each launch to identify progress. Strike One.

Architecture:

To be quite frank there was, and currently still is (yep, even in the version that is on the App Store now!) zero architecture. Looking at my terribly messy Xcode project now I can identify the pitfalls of having no architecture, and the implications of this such as repetition (see below) and just plain difficulty in trying to understand what it is 18 months ago me was even trying to achieve. Strike Two.

Repetition:

One of the main things I’ve learned over the course of the last twelve months of what I’d call more of the theoretical iOS development is the importance of segregating duties and not repeating yourself… too much. This is one thing that the current project does over, and over again with files that are almost identical to one another, which in turn causes other problems similar to poor architecture. Strike Three.

image.jpeg

What next?

After going through the above examples with Ben and Steve as to some of the creative choices I’d made, a suggestion was made that we rejoice in the flaws of the app and use these to show how far I’d come over the course of the last two years by re-building the app from the ground up.

There we have it, that’s how this project was created. I’ve already learned a lot of new things and I’m absolutely certain that before this is done, I will have learned a lot more as well.

There’s a lot more information I could go into about what the new app will aim to improve on the above, but I think that is best left for another post.

I want to stress that at no point were Ben or Steve saying the app was bad or that it was being made fun of (well, perhaps by me a little it was! 😆).

It is very important that I went through the entire process of building that app as if I hadn’t, I most certainly wouldn’t be here today writing a blog and I would encourage anyone learning iOS to tackle all of these problems head on.

Use what all the resources you have available to you, whether that be documentation, books, YouTube videos or what you find on Stack Overflow, but just make sure you take the time to understand what you ultimately end up doing.

That to me, is what iOS development is all about.