Shipping Travelog

(and why it was so hard)

In June, 2011, I started learning iOS development — I read an Objective-C book to nail the basics, and started developing practice apps that utilized different APIs and SDKs, to get familiar with CocoaTouch.

Around 8 months in, I still didn’t have a product. Sure, I had developed an app that helped attendees of the IB AP 2012 navigate the conference, but that became redundant after the 3-day convention was over.

My dad is a frequent traveller and is on a business trip every other week. He suggested I make an app that allows you to record flights, track your miles, and stay up-to-date with the latest travel information.

I wasn’t overly passionate about the idea, I didn’t respond to it as my father did, but I wanted to build a product for the App Store. Something I could add to my Twitter bio. So I took up the idea, and called it “MileIndex”. The design was crap and the code worse. I didn’t plan the app, I was navigating through misty waters, using my recently acquired knowledge to keep me on track along the way.

I released the app, but was dissatisfied. A month later, in mid-2012, I rebranded it to “Trvlogue”. I restarted development without any prior planning, again, and still somewhat lackluster iOS skills. I released the app in November of 2012, however was still displeased with it, and the name’s ambiguous pronouncation. So in late 2012, I set it out to create “Travelog”. A professional design, a professional user experience, written with professional code. Not an app that sells just because it’s developed by a 12 year old. A real app.

At this point, my iOS skills had vastly improved, I can credit this to Lenny Khazan, when we partnered to develop the now defunct augmented reality graffiti app (Apple engineers @ WWDC said it was not possible with the iPhone’s, inaccurate, available sensors), he really led me to understand what real code was. I wasn't even familiar with OOP well back then, I was creating my models with dictionaries! My code was unstructured, hacky, and pathetic. I stuffed everything in one view controller. Lenny really saved me, I sent myself back to the books for a month, and got a better jist of Objective-C and the entire notion of OOP.

After that, I was writing better code than ever. And work on Travelog (AKA update 2.0) started, I was very passionate about the idea and app. I set out to create a social system that tells you when your connections will be in the same city as you — a feature my dad wanted at the beginning, but I had no idea how to create. However, at that point, web, servers, creating anything that beyond local data storage — was confusing and scary as hell to me.

I was alienated at first, but after hours of Googling, I came upon Amazon S3 and CloudFront, alongside SimpleDB / DynamoDB. I decided to make my system on AWS, and proceeded with the iOS app. After a month, I found my legacy code to be a burden, so I started from scratch. For the second time. At this point I made one huge mistake — not planning my app, not learning from my mistakes!

So there, I started with (what at the time) I felt was great code. It was good code, I just didn’t have practice, so it had problems. AWS was frustrating-it was slow, and difficult to implement (at the time). It wasn’t serving me how I wanted. And soon, as I learnt more and my programming skills evolved, I found my code terrible again, a burden. So I refactored completely. And I hadn’t planned out anything, I was figuring out stuff on the go, which created a mess.

During this process, I switched to Parse, which, by the way, I discovered is a slow, unreliable service. In-between, I learnt how to setup servers, and write NodeJS, so for my newer apps I’m developing my own backend.

Creating the entire system as-you-go is not a good idea. It leads you to develop bad, unstructured and hacky code. This was a problem among majority of the app, with the travel info data downloader as an exception (that naturally needed a lot of planning to create a cohesive system).

Soon, most of the code was becoming a burden again. But I didn’t have the time to rewrite or refactor-that code still exists. Lazy code still exists. Bad code still exists. The Travelog Xcode project is huge, I’ve written around 10,000 lines worth of code, no joke. With another 20,000 of open source code. With such a big project it gets hard to keep track of bugs.

Travelog’s design kept evolving, as iOS 6 went to iOS 7, as my tastes randomly changed, as I got feedback from others. New features were just stuffed in, every time I thought of something cool, I tried to add it. Huge mistake. Wasted months of my time, and even more as it created huge bugs. After that, I had a change of heart. I started stripping down features to let the user focus on what really matters.

I took huge breaks in-between development, I got bored and frustrated of developing Travelog. I had a burn out. Started watching a lot of TV, doing more Contra development. And when I did try and sit down to work on Travelog, I didn’t get much done. In fact took a break from iOS development as a whole. But I’m still very passionate about the idea.

I would consider myself a good iOS developer now. It’s all about prior planning, including the app layout, features and how your code will be structured. I’m currently working on a social debating app, called Contra, and have developed a plan almost 3000 words long, highlighting every feature, the layout, the backend models, the iOS structure, etc. Right now, I’m working on the Contra backend Node.js code, and when I start the iOS app, I anticipate everything to go smoothly.

I can justify this, I’ve also developed a few client apps in-between, and they came out pretty well! I know how to develop iOS apps, it’s just that I couldn’t give up on my first project.

Travelog represents me and my journey as an iOS developer. I‘m always learning, but at this point, I know I’m at a certain threshold to develop decent quality iOS apps in a fair amount of time. Who knows, maybe in a few months I’ll have squashed all the bugs out, maybe I’ll rewrite the app and the backend, maybe I’ll stop development on it completely.

At one point I decided to release it. It would create a clean slate. I could look at bugs in new ways. I could collect bugs easier.

TL;DR: No prior planning (hacky code), constant change of taste, constant adding of features creating bugs, programmer burn-out, learning along the way

I’m sorry it took so long, but hey. Download the app. Tell me ‘de bugs!

Update: It’s only been a day, but I’m already feeling a lot better about the app. I sat down, and could productively solve problems and fix bugs in the app. I’m probably never going to move off Parse (unless it goes big), or rewrite/refactor the entire iOS app, but I have some super-duper cool stuff coming down the road.