Making my first
Decisions and lessons learned
As part of learning how to code, I wanted to release my first iPhone app.
I’m a designer and front-end developer, and have on occasion hacked something together in PHP. I’ve worked with various languages like ruby and php, and on a higher level understand what’s going on. But by no means can write any functional production-ready code.
The goal was simple: release an iPhone app and get at least one person to buy it who I didn’t know.
I enjoy to ride my mountain bike throughout the year. During winter, wind chill is a big factor in the temperature you experience. Where during the summer, high humidity and the lack of wind makes it feel a lot warmer. Making the feels like temperature the most relevant when outside for an extended period of time.
This is very much a product I wanted to exist. Many weather apps have the option to show the feels like temperature, but I wanted something dedicated. Therefor I didn’t do any extensive market research, but I’m aware there are a lot of weather apps out there.
Whenever possible I like to minimise the options available to the user. As the maker of a product it’s your duty to design it well. Not taking the easy route by dumping a bunch of unneeded options all over the settings screen.
I actually avoided the settings screen all together for this one.
Based on your location the app sets the corresponding units. For example, the weather in New York is displayed in Fahrenheit, 12-hour time clock and US customary units. Whereas the weather in Amsterdam is displayed in celsius, 24-hour time clock and metric units. This might not cover all use cases, but for the vast majority it’s exactly right.
Throughout the design process I made sure to leave out any unnecessary elements. I find leaving stuff out to be immensely rewarding.
The temperature is the most important element. By researching different weather maps and temperature colors, I created a series of gradients to reflect the current feels like temperature.
Because the temperature unit is based on your location, displaying the temperature unit seemed unnecessary. The difference between fahrenheit and celsius is big enough to avoid any confusion. Instead, I used a circle around the temperature as a universal degrees symbol.
Where are the weather icons?
It’s all about the feels like temperature. Icons would distract from this experience. I opted for a text-based version to display the current conditions.
It’s hard to predict the weather over a longer period of time. Three days out might have been ideal, but I couldn’t find the needed space in the design.
I wanted to design a forecast view that had contrast while still being connected by using the same gradients.
The forecast view shows at which times the low and high temperates are reached. While testing various locations all around the world I noticed these times vary a lot per climate.
Now that most design is flat and minimal, animations are a great way to enhance and diversify your design. It can be tempting to go overboard. Creating a series of animations that wear off soon and an app that is perceived as slow. I believe Microsoft sped up the animations in Windows 7 to make the OS feel a lot snappier. I haven’t fully nailed the wearing off part yet, it needs to be less repetitive in certain cases.
Cordova…, still there? Good! So I didn’t write Feels Like in native code for a few reasons:
- As I wanted to get this app released. Having to learn something like objective-c would take the fun out of this project, and most likely make it undoable with my limited skill set.
How does it work?
- First Feels Like asks for your location, specifically the latitude and longitude.
- Using the obtained latitude and longitude, it sends an API request to Forecast.io, which in return sends the weather data for your location. This is a lot of data I only used a fraction of. I was tempted to add more functionality, but refrained myself for the purpose of the app.
- When it obtains your location, it doesn’t automatically know the name of your city or neighbourhood. For this I used Google’s reverse geocoding. Sending the same latitude and longitude which returns your city name. When it’s a larger city it returns your neighbourhood.
Pretty simple huh? It took me a lot of time to figure this all out. Learning how to code is like compound interest. Every new project gets easier and you can make more “complicated” apps — faster. With Feels Like I learned a lot about APIs. Which opens the door to all sorts of apps, there is an API for everything. Yes, everything.
Is native code better? Yes, no, it depends.
- Yes, because with Cordova there is a layer that interacts with the native code. This often results in more bugs, loss of performance, and it increases dependencies.
- No, because Cordova actually works pretty well. It’s not for every type of app, but I didn’t ran into any major issues. When there were issues I couldn’t tell who to blame, probably myself. I don’t see how using native code would have brought major advantages to this app.
- As always, it depends. I’m not an expert and there are a lot of factors to be considered when selecting your development tools. If you’re coming from the same technical background as me, your should consider using Cordova (also known as Phonegap) to build your app.
There are several pricing options available: free, ads, in-app purchase,
In an exercise of entrepreneurial thinking (self-delusion), what if the app becomes wildly popular? It would boost my ego, but also cost me money. The Forecast.io weather API is not free, it costs $1 per 10,000 API calls. This might not seem like much, but it doesn’t scale well economically.
I also don’t sell any other products or services at the moment. There is only one product in my product spiderweb. So it wouldn’t lead to any additional income.
There is a (psychological) difference between spending a lot of unpaid hours on something and a money losing pricing model. Besides, it’s a well designed app that works as advertised.
Since design plays a large part in it’s appeal and value proposition. This wasn’t really an option. Plus I don’t like ads, but who does? Even though we apparently all click on them and buy a ton of stuff we don’t need.
In large the only way developers make money nowadays. Your paid app sits between all the free options in the App Store. People don’t read the description and only take a few seconds to make a decision between the available top-something apps. That’s a tough sell.
I could split up the functionality of the app, where the forecast section would be an in-app purchase. This wouldn’t entirely solve the problem of the API costing money. But those purchases should easily offset the cost of the free installs. Plus it only would be an issue if my self-delusion scenario plays out.
However, developing a well made in-app experience is a ton of work. It might even be more work than the app itself. Given the fact I just wanted to release my first app and get one person to buy it. I decided to go with the paid option. In the future I might try a free version with an in-app purchase.
The old-fashioned option. I went with the Tier 1 pricing option, which is $0.99. The same amount that’s lost somewhere between the cushions of your couch. It’s light on features, and to keep the barrier to purchase low, this felt like the right price.
The paid pricing model is not exactly ideal in the App Store. This however changes in the context of you reading this blog post or a friend showing you Feels Like. The same amount is suddenly not much of an issue anymore. I’m hoping this will be the main way people discover and buy the app.
Apple does a good job providing a guide on how to submit your app to the store. There are also a lot of articles available with tips. Here are mine:
- Check the App Store for apps similar to yours and use their description as inspiration. How do you think those descriptions were written?
- App Annie is a great resource for researching keywords. Review the top keywords used in similar apps.
- Only the first 25 characters of your app title are visible in the search/list view, make them count.
- Use all 5 available screenshots, the first two are visible in the search/list view. In the first version my first two shots were that of the main view. I later changed this to show both the main and forecast view.
- Have a landing page. You don’t want to solely rely on the (broken) App Store discovery.
My app uses SSL because the connection to the weather and Google APIs are encrypted. Despite the fact I’m based in the Netherlands, the general rule is when an app uses cryptography (SSL) it needs a US export license. What counts is the distribution platform. In this case the App Store, which is US based.
But wait! There are exemptions to this requirement. Making it even harder to follow.
I do not store or transmit any personal data. I figured it was worthwhile to see if I my app could do without such a license. My reasoning comes down to this: The app uses encryption to support it’s main function, displaying weather data. During which no personal or sensitive data is transferred or stored.
When I submitted the app I stated it uses encryption, but falls under the exemption. Is this the correct answer? I’ve submitted the app and a small update and both were approved without an issue. Yes, till proven otherwise.
So I created an app in a crowded category, using Cordova, and making it paid. Oh boy!
Getting Feels Like in the App Store has been a personal victory. As an added bonus, this is also my first blog post. Something I’ve been wanting and yet so reluctant to do for a long time. I’m also happy to report that more than one person bought the app (wasn’t my mom).
Say hello on Twitter.