30 Lessons from building my first app ever

Over the past couple of weeks I have been spending my leisure time outside of work on a little side project: building an iOS app. The app is something that appeals to my literary side while also serving as a platform for other interests that lie along the same line. Called Quotepad the iPhone-only app (for now anyway) is like a pocket book of quotes carrying over one-thousand quotes and affirmations along with functionality that lets users add and save their own quotes, collect favourites, discard unfavourites, and keep everything synced with iCloud.

The project is off to a great start and I feel like I have learnt some important lessons that I just might forget as I move forward so I record them here, primarily for my own future reference but also for anyone else who might find themselves in the same boat.

When a friend and I started dabbling with Swift earlier this year, Quotepad was born as an idea for a ‘simple’ app that I wanted to make personally to practise my coding skills while ending up with a nice little product that my wife—who loves quotes and motivational stuff—could find some use for. As I started building it, though, I felt there was enough of a market to it and that it was worth taking Quotepad out of the personal garage and taking it mainstream. While the app initially only carried a few tens of quotes, and its only job was to show one random quote at a time, it was my wife who suggested I should look into adding affirmations because there was a seemingly untapped market for it, and, following conversations with a friend/business partner (I suppose) we decided to develop the app and aim for a worldwide release on the App Store. By launch date the app had almost a couple of thousand quotes and several hundred affirmations.

Get beta testers and consider their feedback earnestly

Maintaining a few thousand lines of code can be manageable in the beginning but keeping track of things over time takes focus away from fixing bugs. Despite everything appearing to work perfectly during initial testing there are inevitably going to be bugs you will catch only weeks down the line, by which time it will probably be too late to do much. Shipping breaking changes during public release is an obvious no-no.

Having a good team of people beta testing your app is essential in more ways than one. We had about 25 testers in all, which is paltry compared to some big-name apps (WhatsApp beta, for example, has long hit TestFlight’s limit of 10,000 beta testers) but for independent developers without huge funding, and for apps on a medium scale like Quotepad, this number is good enough to catch most bugs before release.

We sent out two breaking changes to our beta testers and their feedback helped us catch bugs and make major overhauls. Twenty-two of our testers chose to remain anonymous during testing (Apple keeps testflight user identities anonymous by default for obvious reasons). So thank you Adam Webber, Doug Griffin and of course Vaishnavi Kulkarni. We had a host of big UI changes by launch time that we could not have made ourselves without good feedback.

It is important to be open to feedback while not losing sight of the core principles of your app because beta testers draw ideas from what they see, and their understanding of your app will be derived from yours; their understanding of what drives your app will never be exactly the same as your own. Consequently, their feedback is representative of how users feel while they use your app, rarely of what drives the app—that balance is yours to keep in its entirety.

Sharing analytics—a personal opinion

I have always been one to disallow sending anonymous feedback to developers despite Apple handling the privacy and security end of the deal, and despite no information that can identify you being sent to developers. Perhaps this was because I had never really seen (or understood?) what developers see or do not see, and how; or perhaps it was because I was never in the same boat as them.

However, now that I have had a good look at App Store Connect—the developer dashboard that Apple provides through which we developers can analyse mass user data without ever being able to identify users (essentially, we see trends and nothing else)—I see how helpful it can be to have anonymous user data. Users’ identities are of no consequence in this scenario. But, more important, I see how unreliable this data can be when most users have not allowed their devices to share usage data with developers.

None of this is to make a case for sharing your own data with developers. Indeed I see a lot of sense in my being cautious earlier and I urge you to see things your own way but I for one will no longer be preventing anonymised usage data from being sent to developers.

The risks are real

When people use your app they rely on it to some extent. This might not apply to people who are simply testing your app out, but it does apply to people who jump in and start using your app regularly. It is these people that we developers are answerable to in some ways.

Users’ reliance on your app comes in certain specific ways: first, they assume your app is here to stay; second, they assume the data they put into your app will not go missing or corrupt; third, they assume that their investment, whether in time or money, will not go waste in that the app will prove to outlast its worth.

The luxury of beta testing is breaking changes. Once your app is out there the things you can do to it are greatly diminished at least in that you need to think a lot more about how you will solve problems or add features. The risks then are quite real. The consequences of every update or code change or overhaul will have ripples that can potentially decide whether you gain or lose users. This dawns on you right around the time when you first submit an app to the App Store.

Handling App Store rejections

While Apple’s App Store has exponentially more rejections than Google’s Play Store, reviewers do get back with reasons why they rejected your app. When Quotepad was first submitted we were rejected for a silly reason that we could have avoided: our 5.5-inch and 4.7-inch device screenshots were incorrectly uploaded. Rectifying this was great, but in the one day between rejection and resubmission we managed to catch a couple of last-minute bugs, make quick improvements and make our app better for launch.

Take advantage of the rejection. App Store guidelines may be strict (Apple have over one-hundred rules apps must comply with for approval) but it is this curation that sets the App Store apart from other mobile stores that came after it. Users trust apps from the App Store; except for the occasional one that manages to slip through review apps are expected to be of an incredibly high quality and look, feel and behave premium. And both iOS and macOS users alike have come to expect a certain baseline quality. So look at an App Store review process as just that: a review and correction stage where Apple itself helps you make sure your app is up to the mark.

Design and functionality: Minute things count

There is no doubt in anyone’s mind that App Store apps are some of the best designed mobile apps in existence. While your app may or may not qualify for the same title, try to keep its design top notch. It has to be unique without being difficult. From the themes to the layout to—and perhaps most importantly—the use of negative space, the little things can go a long way in making a difference.

But with a focus on design it is important not to oversee the functionality. Most users interact with many apps a day. Whether you like it or not when you break from some common interactions people tend to resist to the point where they abandon your app because it acts like a recluse. Swiping, pressing buttons, and other gestures must behave like users expect it to. It does not take a genius to map one gesture to an unconventional action just for the sake of it. Unless you have a really good reason, stick to the device convention for your user’s sake. Clever design does not stand out for the sake of it.

That said, some interesting ideas can—and ought to—be implemented to make your app stand out, especially if it helps ease the user experience. Across our app we use taps and press-and-hold gestures to accomplish tasks and views respectively. As we maintain this throughout the app it quickly becomes second nature to users. The same is true of button placement: a button on the left in one screen, if it carries over to another, should remain on the left or—under circumstances that warrant it—move further left. If it switches position to the right-side of the screen consider your user flabbergasted and turned off.

Lastly, think carefully about certain things like how the interface responds to the user’s expectations rather than just their actions. For example, if the only job a user has on a screen is to type something in and this is clear enough, save them the trouble and just show them the keyboard as soon as they enter that screen. Do the tough work in the backend, thinking about as many scenarios as possible (users love to push apps to the limit, especially when they have some free time on their hands) so use your thinking, coding and beta testers’ feedback to make sure the design and functionality of your app is sound enough that it does not break when pushed.

Data management is a headache

Those of you who have ever handled large chunks of data will know precisely how unweildy they can get. In no time you will go from loading some samples to struggling to manage huge swathes of data.

We started out with a text file-based workflow to read and save quotes but that quickly got old and inflexible. For example, storing quotes, authors, dates and owners in csv files can get ugly fast; storing them on separate lines means you have no way of telling one from the other. Consider this: if you only have two repeating fields, you can refer to one as the even field and the other as the odd field and identify pairs. But what if you have three fields A, B and C? You might think of going in threes but you will quickly reach the sixth entry which is really of the type B but because it is divisible by three the computer is tempted to think of it as a type C entry. This will throw your data into a disarray.

iCloud gets a lot of things right in this regard, from querying and sorting to simply storing values and being able to fetch them reliably. Use this. And keep an eye on users’ privacy. With Quotepad we store every user’s data in private databases accessible by the user alone and that too via the app alone. This means nobody, neither us nor Apple, will ever even be capable of accessing this data.

On top of all this I was dead set against user sign-up forms for Quotepad, which meant we had to somehow be able to identify users individually without explicitly asking them for their e-mail or asking them to create a password. We decided to tie things to their iCloud. After all, if you have no iCloud Quotepad works locally and erases itself when you delete the app or reset your phone (this keeping in mind that everyone with an Apple device likely has an Apple ID and therefore an iCloud account too). And if you have in fact signed in to your iCloud, Quotepad cleverly uses that to identify you everywhere without explicitly reading your e-mail address; instead we use a unique, app-specific iCloud ID randomly generated during the app’s first launch. This ID will remain fixed across your devices so long as you use this app and have the same Apple ID (without which you will lose all your apps anyway). This is great for users because they can start using Quotepad with almos no set-up at all if they wish.

Business model

Lastly, we need to address the elephant in the room: what is our business model and why? Users these days find it important to know how app developers plan to support their development. If an app generates no income to at least compensate developers for their time it becomes highly unlikely that an app will last long on the market.

For starters, this rules out anyone getting Quotepad for free. As much as I love free apps myself, I understand that developers put in a lot of thought and work to get things right and create a product to be sold—for money—much like any other product. Would you ask for free furniture?

That said, what price is right for an app like Quotepad? I asked around some and to most people the $2 mark seemed apt. Both of us developers too agreed that asking for about $2 (2€ or ₹150) was fair—at least to begin with. We have huge updates planned and will likely test out a subscription based model where users have to pay just about $1 (1€ or ₹80) per year. If we ever switch to that model older users will be grandfathered in because it is simply the right thing to do, and newer users will be able to get a week’s trial.

We understand, and agree, that to ask for a subscription we need to offer continuous benefits. This will come in the form of monthly additions of quotes and certain other planned features that we would like to keep under wraps for now. Our TestFlight invitation is always open to those who would like to join the beta and test the app out with us, while providing feedback and suggestions we would love to consider and probably even incorporate into our app.

Overall, developing an app has been a fresh and thoroughly enjoyable experience; it has been something new that I have enjoyed immensely after a long time. And if it bears fruit this might just become more than a side project going forwards.

Just minutes before I published this, we received our approval from the App Store and our app is now available worldwide for purchase for just around $2. We hope you take a look, even decide to buy it, and, above all, we hope it adds something worthwhile to your beautiful lives.