One thing I really wanted to do was get my hands on some iOS project so I could learn the other half of mobile development. It surprised me that Epicodus, with all those Macs in the classroom, decided to teach Android instead of iOS (or instead of both…). I was jealous of the classmate(s) that got to use a little iOS during their internships, but I finally got a chance to to get my hands dirty too.
I was working for a local agency, Media Mechanic, that started out as a mobile app development firm before branching out into developing websites too. My first project was to update an app they made several years ago called the Neurosurgeon’s Survival Guide. I was working on the Android app, and just about finished when their iOS developer disappeared.
Do you think you can do the iOS version too?
Sure. How much time do we have? 2 weeks!?! Well, I can give it a try.
There were two versions of the old app. One in Objective-C (the older version) and one in Swift (at this point, the broken version).
Now, this was old code. And I don’t even own an iPhone, so I’m not all that familiar with the versions and when certain features became available. I try to keep these things in mind as I look over the old code and not blame the previous programmer for doing things the way he did – because for all I know the way he did them WAS the way it was done when the code was written.
The first challenge was the Swift version. We loaded it up (on the latest version of Xcode) and it was just a mess of red squiggly lines. I tell you, (like I told my boss), I don’t even know where to begin with that. Are you sure this thing worked at one point? Because I don’t think I can fix it now.
The older version, in Objective-C, however does appear to be working. And what did you say the Swift version was supposed to have fixed?
Swift code looks pretty familiar, and given a choice, I thought I’d rather work with it. So I began the project by trying to duplicate the working version in Swift. This turned out to be a dead end when we got to the SQLite database though. The only information I could find on using SQLite was with Objective-C.
Not to mention, that part of the program was working fine in the original app.
And 2 weeks…
By the second week I had watched all the training on LinkedIn Learning for Swift and Objective-C and had a much better idea what I was working with. The original app did not have storyboards. All the views and controls were hand-coded. (Like I said previously, it was old, maybe that’s how they had to do it back then?)
The UI had changed significantly though from the older version so “swapping out the graphics” (the original requirement) was not possible. Instead, I had to rebuild the thing from scratch.
I wrote code and slept and wrote code, and had at least a working version up by the end of the second week. After that, it was all about “pixel perfect” which seemed to take hours as one small change would move all the other controls around in unpredictable ways.
Meanwhile, while I was obsessing with the user interface, someone was playing with our database. We got a bunch of corrupted data in there somehow and it broke the Android app (bad reviews are suddenly showing up on the store).
What did you do?
Yes, of course it’s my fault…I did after all just try to resize your drop-shadow.
In the end, it turned out to be caused by copy and pasting text from Word. So now we can blame Microsoft and get back to fixing our app.
I enjoyed making the iOS app and would like to do another at some point. Will, almost certainly, build iOS versions of my own Android apps.
I found once I started to understand the storyboards and relative layouts that they were fun to work with (but very frustrating before that…)
I even came to appreciate Objective-C and would not necessarily jump straight into Swift for my next project.