Alexander Ramadan

Where I Sometimes Write Stuff

Building My First iOS App

What I Learned Building My First iOS App

I recently released my first iOS app, called Write365. It’s an app to help writers get out of a rut or break writers block. It’s based on an ebook my girlfriend wrote and had some success with, so we figured it would be neat to have an app counterpart.

I learned so much while building Write365. Considering I hadn’t ever written a line of objective C , or worked in Xcode, the entire process was an education. I can’t take all the credit though. The courses on iOS development at Treehouse were essential in getting me started. I also learned a lot from the Big Nerd Ranch book on Objective C. I also learned a lot from watching videos on Youtube and Vimeo. I’m extremely grateful that I live in a time where I can learn about things like computer programming even though I was told that “computer programming” is only for people who are “math people” while in school.

Besides all the technical and business insights I learned during this process (submitting an app to the App Store was a whole learning experience on it’s own), I did learn a few general things about building a small product, finish it and get it out the door and in users hands.


I have always found that when I can’t work out a difficult problem, or I need to approach a large project, mapping out my thoughts on paper seems to help to clear my head and give me some direction. When I was first conceptulaizing Write365 it was pretty daunting and at points I was getting discouraged. I eventually took to a small white board to write out how the logic of the app would work.

What is the point of the app? How do I think it’s going to work? What features should be included?

When I’m using a white board or paper I don’t really restrict what I’m writing, I just get it all out and then start to eliminate things. I write everything I think I will need to do, or use, eventually crossing stuff out as I figure out what I really need. This can be exceptionally useful if you’ve got a project with a lot of moving pieces that can be hard to keep track of.


If this the processing of building an iOS app made me realize anything, it’s that I am not good at a lot of stuff and I sometimes need help. Saying my code is duct taped together isn’t too far off base and I wouldn’t wish it upon my worst enemies to have to look at my intial concepts for the app icon. With that said, I am not too proud to ask for help, nor am I above paying for the help I need. Between the super helpful folks in different development communities and the awesome designer I worked with, I was able to fill in the gaps where my own skills lapsed.

Sometimes I wonder how many people could accomplish amazing things if they would just ask for help. I’ve never been above asking for help but I do have a couple of rules when asking for help though.

Try to solve the problem yourself first. When asking for help, come prepared. If you’re asking a question about how to solve a programming question try to come to the table with what you’ve already tried and why you thought it would work and why you think it didn’t.This context could help whoever is helping you figure out a soultion quicker. It also demonstrates you’ve made an effort at fixing your own problems Say thank you. Say thank you to someone even if they couldn’t solve your problem. It’s better to say thank you to too many people rather than leaving one person hanging.


Before I started building Write365 I was concerned that people wouldn’t like it because the code behind it was too simple. Being new to writing code, I am prone to being insecure about my abilities, so that was definitley in the back of my mind. But once I started to actually write the code, see the app in action and show it to a few people, those fears started to melt away.

No one outside of another developer cares how my product was built. No one cares what framework I used, or how I built a custom library to do X and Y. I was excited to talk to people about how I did this or did that but their eyes would just glaze over. All they cared about was the end product. So I learned to focus all that energy I had been dedicating to being concerned about my dev rep to making the product more appealing to actual users.


Feature bloat or feature creep can cause projects to get drawn out, or cancelled all together. Don’t let a feature that isn’t core to the product hold up it’s release. The great thing about software is that you can always add things to it later.

Forcing myself to leave features out of the app wasn’t neccessarily a big problem for me here. My lack of experience and technical skill kind of impeded my ability to build feature after feature, even if I wanted to. Since I would have to basically teach myself how to do everything on the fly, I really had to pick and choose which features to implement. Every feature needed to strike a balance between offering value to the app experience and the time/effort I would have to dedicate to getting the feature working.

I did end up adding one feature that I hadn’t planned on including when I first started building the app. The email feature was tacked on at the end as a comprimise between a desire to include a full blown text editor and some social sharing features. I went with the email feature because it was quicker to deploy and provided a similar feature set as the some of my other potential features.

I obviously learned so much more than I could express here, but those were some of the bigger, more general takeaways. Coming out of this experience I really enjoyed working on the iOS platform and plan to do a lot more of it in the future. I’ve also gained an all new level of respect for great iOS developers. I never really thought about some of the apps I was using before trying to build my own. I just assumed they “worked”, never really considering the immense time, skill, money and creativity that went into creating a great app.