What I Learned From My First Watchkit App

Until Then AppI decided to test the Apple Watch waters by adding WatchKit support to my app Time Until. Time Until is a simple app that let’s you track how long it is until an event happens. You can track how long it is until Christmas or your spouses birthday, for instance. I thought it would be a good test app to learn the basics of WatchKit and the app submission process.


I decided to price the app at $2.99. If it were a more complex app, I would have started at $4.99. I don’t think anyone has a good idea of how well apps that have the WatchKit extension will do. I could see a nice bump in sales or nothing. I’m sure whatever I do, I’ll feel like I left money on the table.

What I Learned

  • The WatchKit extension does not share the same NSUserDefaults as the base app. You will have to make a shared NSUserDefaults group. You do this in ‘App Groups’ in the capabilities section of you target. Xcode will automatically create the group and handle the entitlements. Here’s a nice stack overflow response I found.
  • You don’t have to have a ‘Glance Interface’ if your app doesn’t need it. Time Until just needs a table view with a refresh button, so I only implemented the ‘Home Interface’ view controller. At first I thought I would have to have a glance interface too, so it was nice to find documentation that I didn’t need that.
  • When you add the WatchKit extension, you will probably have a few classes or third party frameworks you want to share. Just like all different targets, you have to link them in the build phases tab of the WatchKit extension for the class to be available to your WatchKit extension.
  • If your icon has much detail, you are going to want to create a simpler version for the WatchKit extension. It will also use a different asset catalog. See the link below for more details.
  • You will need a screenshot for iTunes Connect. You can save screenshots the same way as you do in the regular simulator. Command-S

iOS Simulator Screen Shot - Apple Watch Mar 31, 2015, 9.50.00 PMApple has a nice landing page for preparing your app for submission. I ran into your typical Xcode validation errors regarding icon sizes, etc. Other than those frustrations, adding the extension was mostly painless and didn’t take much time.

Why I Don’t Use App Review Services

Getting users to review your apps is hard. We all know how important it is to score some early reviews to boost your ranking and make it look like at least someone is using your app. So what are your options?

Ask Your Friends

This is probably the most obvious one. Beg your friends and family to download your app. Take them out to dinner. Buy them coffee. Buy them a beer. If you have five friends in the world, you can make this happen.

Annoy Users With Rating Requests

As you can tell by the headline, I’m not a fan of this one. I have used this approach off and on over the years and it always makes me feel icky. I don’t like disrupting the user experience. If you are going to do this, try something more interesting. Check out what Brian Mueller has done with the Carrot Weather rating request. It doesn’t get in the way but gives those inclined to leave a review an easy option.


Carrot Weather

Buy Reviews

Yuck. Don’t do this.

Review Exchange Sites

What these sites do is allow you to earn reviews from other developers by reviewing their apps.

I have personal experience with one of these sites. I gave honest reviews of apps and received reviews in return. Some of the reviews were good, such as a 4 star with details that showed the other dev actually tried the app. Others were not so good, such as a 5 star “Great game!!!” review of my app that wasn’t a game. The hardest part for me was the sheer number of terrible re-skins I had to deal with. It seemed like about 90% of the apps I was asked to review were in this category. I was getting plenty of reviews and I thought it was a great service to at least kick start my reviews after launch or an update.

One day last June, after using the service for a month or so, all my reviews disappeared and most of the reviews I had received through the service were gone. I talked to Apple about it and they had cleaned house and deleted what they felt were fake reviews, blacklisting Apple IDs along the way. Talk about scary. I was lucky they didn’t suspend my developer account. To this day I am still unable to review other apps through my dev account login.

I do not personally think these services are against the rules or shouldn’t be allowed. Apple thinks differently. As far as Apple goes, paid reviews are against the guidelines and they categorize developers reviewing other developers for each others benefit as paid reviews.

I would discourage anyone from using these services. All it takes is for Apple to clean house and you could be blacklisted or worse.

I believe the best way to get reviews is to make a good app that users like enough to feel compelled to review. I did that with my app, Quit That. Read about it’s success here.

When To Outsource

In 2013, I had an app that became popular enough where an Android version was needed and in late 2013, I finally committed to shipping one. As a programmer, I didn’t think it would be that difficult to put something together for Android. It’s a relatively simple app and it was easy to find a few project templates that I could adapt. I wasn’t looking to become an Android developer, just competent enough to get out this app. At the time, Eclipse was the IDE of choice, so I downloaded and installed. I tried playing around with it, figuring out how it all works, trying the simulator, and going through a few tutorials. The more I worked with it, the more I disliked it. It just didn’t fit me at all. I just couldn’t find a way to like anything about developing for Android.

What I Realized

After banging my head against Android off and on for a few weeks, I came to a realization. Why should I keep fighting this when there are other alternatives. I had enough on my plate with other iOS projects. Android was sucking all my energy and stressing me out. The only way to avoid certain misery was if someone else built the app.

Managing Expectations & Budget

I decided to outsource the project. I ended up on freelancer.com. It still amazes me how many developers outside of the US are bidding on every project, no matter the budget. Many are bidding ridiculously low prices just to get the experience or because a dollar goes much further in other parts of the world. I was comfortable losing $500 on the project. Worst case scenario for me was spending $500 and not having an app to show for it. I could live with that.

What I Learned

The first beta version the developer I hired sent me was terrible. It was completely unusable. I thought I was in trouble. But after a few iterations, I ended up with a nice functional app that was very similar to my iOS version.
What I learned…

  • Make sure it is understood that you will own all the source code. Make this clear from the original job post and when working with the developer.

  • One way to check the source code is to have them set up a repository on Github.

  • Have multiple milestones and release funds as they are met. If you release funds before you have the completed code, you are taking a big risk, regardless of your previous relationship with the developer.

  • Many times there will be a language barrier. When deciding on which bid to accept, make sure that you can communicate with the bidder, they understand what you want, and are prompt in their responses. It’s ok if the English isn’t perfect, but it should be understandable. If they don’t get back to you for a couple days in the bid process, drop them from consideration.

  • Expect delays. Things will not go as planned. You may even have to cut your losses and re-list the project.

  • If your project involves a database, only give the developer as much of the database as they would need to test. It wouldn’t be any fun to see your exact app competing with you on the Android store.

  • Pay attention to the frameworks used by the developer. Look them up and see if there are any privacy issues, etc.

  • Describe what will be required of the project in as much detail as you can when you post the job. If you forget to say you want a tablet version, do you think the developer is just going to make the tablet version for free?

  • It’s important to continue to say what needs to be said with every iteration. If a table view scrolls a little jerky, demand that it is smooth. If an image resizes incorrectly on rotation, point it out as a problem. You literally will get as good of an app as you demand. Remember, the developer is just trying to get it done and move to the next job. They aren’t invested in the project like you.

  • Never accept substandard work and just think you will fix it yourself. You will just be creating a pile of work that you will regret every minute of.

  • You will have to know your way around an Android IDE a little. You’ll have some labels you want to change, etc.

The Results

In the end I was happy with my outsourcing experience and would do it again. I came in about $45 under budget and learned quite a bit. I would have no qualms outsourcing a portion of an iOS app. I found freelancer.com to be easy to work with and didn’t have any problems of note with payment or communication. The developer I selected was based in India and I would recommend them if you are in a similar situation.

Devs Are Not Tax Experts

For the 2014 tax year, I have an unusually high tax bill. It’s a tax bill I wasn’t prepared for. Like many independent developers, I have income from various areas. It’s hard to make a living just making apps, so I diversify. For 2014, our family had the following income.

  • iOS sales
  • I sold a few of my apps
  • My wife now has a full time job (didn’t work full time in 2013)
  • She also had income as an independent contractor and taught a college course (neither was taxed)
  • I had an increase in pay at my regular day job

Making more money as a family in 2014 versus 2013 is definitely a good thing. So, I knew we had more income and would be paying more in taxes. What I had not anticipated was moving to a higher tax bracket.

Sometimes we can get so caught up coding, releasing, marketing, and planning that we don’t pay attention to the boring stuff. I’ve always done my own taxes. I’m pretty sure this will be the last year of that. I’m not a tax expert. I don’t want to be a tax expert. I think the money to hire someone that is would be money well spent.

App Store Integrity: A Fresh Perspective

Many apps on the store frustrate me. I don’t consider being hammered with ads and constantly dismissing nag screens to be a good user experience. Why do apps do this? You already know the answer. Because it works. If your app is popular and users have to see ads or make purchases to get anywhere, you are going to generate revenue. But at what cost? We are all trying to make some money on the store, so it’s tempting to just go with the flow.

Can You Generate Revenue Without Compromising Your Integrity?

I struggle with this every day. I think it’s mostly a user experience issue for me. I understand how advertising works and I’m not trying to vilify the ads. I don’t think apps shouldn’t have ads. I just don’t like the tactics that have come to be acceptable. I don’t mind in-app purchase nag screens in my apps, but I know to get more conversions, I need to present them more often. I need to nag much more. But what about the user experience? You could argue, and make some good points, that since this is what users expect, you actually are giving them the user experience that they want or deserve.

Am I different than my users in that I don’t like nag screens and ads? The answer is definitely yes, I am different from my users. I think most of my fellow developers are too. We care about our apps. We reward the developers of other good apps with purchases. It’s easy for us to forget how different we actually are from most of our users. But that doesn’t mean we should accept the norm when it comes to ads and in-app purchase practices.

The Crossy Road Way

Is there a way to have a free app that generates revenue and allows you to sleep at night? The developers of Crossy Road took a fresh perspective. I really admire how they were able to take a fun, addictive game and monetize it without ruining the experience. For example, you can play Crossy Road all day and never see an ad, nag screen, or review request. When Crossy Road first hit it big, the guys on ATP were discussing their monetization strategy and how they were probably leaving a lot of money on the table. They weren’t saying this was a bad thing, just pointing it out. Crossy Road may have left some money on the table, but based on their revenue, they’ve done very well. More importantly, they have respect for the way they present in-app purchases and ads. You can optionally watch an ad after you die every so many times. The app also may show you an in-app purchase that is available after you die. Instead of being a pop up ad, it’s just part of the regular screen. It’s a nice way of getting it in front of the user, but it doesn’t force the user to dismiss it to get where they should already have been.

courtesy of iMore

courtesy of iMore

Crossy Road also allows you to try out a character for limited time. The characters are unique and make interesting sounds. If you try one out and you like it, you are going to more inclined to buy it through in-app purchase, or watch videos to have a chance to ‘earn’ the character. I love the idea of allowing all the features of your app to be used for a limited time when first downloaded. Letting the user see what they would be paying for adds credibility.

My five year old son doesn’t care about how far he goes on Crossy Road. That seems to be the point of the game to me, but all he cares about is getting coins so he can get new characters. He jumps in front of a train as soon as he gets 100 coins to quickly cash them in for a new character. He is happy to watch the video ads every chance he gets. But, he never brings the iPad to me, wanting me to fix it after he has been redirected to the app store because of strategically placed cancel or buy buttons. The app keeps it simple and doesn’t try to fool you.

My Takeaways on App Store Integrity

  • Treat your users with respect, even if you don’t think they care.
  • Consider a paid app if you can make it work (then you can just drop all the BS and give the user a great app without restriction).
  • Look for ways to make ads available without killing the design of your app or getting in the users way.
  • Think of creative ways to generate revenue. Don’t just look at what all the other apps are doing to squeeze every cent out of users.
  • App store integrity is important. Don’t compromise your values for a quick buck.
  • You can probably always learn something from an Australian company named Hipster Whale.

Using Hazel to Manage App Screenshots

Hazel App


I’ve been frustrated trying to manage app screenshots for years. I typically just dump all of them in a folder and go through when I need them. I decided to make Hazel rules to at least sort them into folders by device. It’s saved me some frustration, so I thought I would share how I did it.

As a side note, Hazel is an indispensable tool that is worth buying. I use it for countless file automation tasks. There is a free 14 day trial, so at least give it a try if you haven’t before.


In the folder you save your screenshots to, create a folder for each device.

Hazel ScreenShot Rule


Then set Hazel up to handle the files.


these are the rules on the main folder


Set the rule to make sure the filetype is png and the correct pixel height and/or width.



I’ve only been using with the simulator so far, but I don’t see any reason it wouldn’t work with device screenshots that you dump in the folder. All you have to do is save your screenshots from the simulator and when you are all done, all your screenshots will be organized by device for easy upload to iTunes Connect or to import into Photoshop or Sketch.

Here’s Apples documentation regarding device screenshot sizes. Scroll down to see screenshot requirements for iTunes Connect, which is what the device and simulator will save.

9 iOS Development Podcasts You Should Be Listening To

I actually listen to almost every episode of all of these iOS development podcasts. Having a 1 1/2 hour commute each way makes it easy. I play everything at 1.75 speed and use the cool Smart Speed feature of Overcast to make it happen. These aren’t the only podcasts I listen to (Free Adnan! maybe…), but they are the ones focused on iOS development.

In no particular order…


Appmasters PodcastAppmasters

I love Steve’s energy and he has a way of getting some great guests. More of a marketing podcast than some of the others. It also hits on the journey, both triumphs and struggles, of getting an app to market and beyond. It focuses on all things mobile, so you get both Android and iOS.


Core Intuition PodcastCore Intuition

Daniel Jalkut and Manton Reece have been Mac developers for a while and it’s nice to listen to a podcast with that kind of experience behind it. They rarely interview anyone and mostly just talk about their thoughts on the iOS and Mac ecosystem, often hitting the hot topics of the week.


The App Guy PodcastThe App Guy

Just one listen and you can tell that Paul loves doing his podcast. He, along with Steve from Appmasters, probably put out more quality podcasts than anyone. Paul keeps finding great guests and digging in to their app story. He has a great segment where he asks the guests for an app idea, often fleshing out something that will get your mind thinking of something you could do.


Developing Perspective PodcastDeveloping Perspective

David Smith must not sleep. But when he does, he probably still cranks out at least one app update. His podcast is never over 15 minutes long, so if you are looking for a quick podcast to get your feet wet, give it a try. Full of great info from a seasoned developer.



iPhreaks PodcastiPhreaks

This is one I just started listening to and have been enjoying. It’s more of a panel podcast where they pick a topic and discuss.




iOhYes PodcastiOhYes

A good podcast that is probably the most technical on the list. They may devote an entire episode to SceneKit or WatchKit. A good listen to really dig in to a particular framework.




Get Up & Code PodcastGet Up and Code

I love listening to how people are working exercise and nutrition into the common sedentary lifestyle of developers. John brings a lot of energy and the podcast gives you ways to either get in better shape. Whether you are in shape or not, you can benefit from the ideas that come up on the show.


Entreprogrammers PodcastEntreprogrammers

This is a fly on the wall type of podcast. If you are more focused on coding and not building a business, this may not be the podcast for you. They talk a lot about how to promote products, email lists, and general business stuff. It’s not for everyone, but if you are trying to grow your development career, you can’t miss this one. It’s like sitting in on a mastermind groups weekly meetup. I have yet to listen to an episode that I didn’t get at least a couple of nuggets of wisdom I hadn’t thought of.

Release Notes Podcast

Release Notes

Of all the iOS development podcasts, this may be my favorite. I absolutely love the real talk about trying to make a living on the app store. Their motto is “Everything but the code” and that is as best a description as I can come up with. They hit the highs, lows, and everything in between in talking about the app store, making and selling apps.


If you are looking for a more exhaustive list of iOS development podcasts, which includes other types of programming podcasts, check out John Sonmez’s list.


Development Cycle Length: How Long is Too Long?

Matt Hall - Crossy Road Development Cycle

Matt Hall – Crossy Road

I was listening to the AppMasters podcast with Steve Young that featured Matt Hall, one of the developers of Crossy Road. There was a little nugget in the podcast that wasn’t really expanded on, but I felt really hits on the pulse of the App Store in it’s current form. Matt stated that the development time for Crossy Road was about eight weeks with three core team members. Why is this significant? How long should a development cycle be for your average iOS developer?

Let’s Compare

On the flip side of the Crossy Road development cycle length is Monument Valley. Monument Valley was in development for 55 weeks and is estimated to cost around $852,000 with eight core team members. Both apps have been a huge success. On January 13th, 2015 the Guardian reported Crossy Road had made over $1 million from ads alone since November 2014 or about $350,000 a month. Monument Valley, according to Tech Crunch, has made over $5.8 million since April 2014, or about $680,000 a month. Both took different approaches regarding development length. The Crossy Road team didn’t want to take the chance on spending a year in development for something that may or may not stick. Monument Valley had a larger team and more money to spend, mitigating their risk. Both teams took on risk, but in different measurable ways.

Minimum Viable Product

Shipping the minimum viable product minimizes your risk by getting your app in the store without investing in too many features or dragging out development. That doesn’t mean you don’t polish your app or ship before it’s ready. It just means you can’t spend your time adding a bunch of features when you don’t even know if your app will have any success. It is increasingly easy for a well done app to be lost in the App Store shuffle. If you don’t nail the marketing AND have a great app, it’s very difficult to sustain any kind of success.

As you are working on your app, you’ll be thinking of all the features that you need to have. In my experience, you can throw out at least half of them for the first release, probably more. Work hard on polishing the core functionality. Think of the problem your app solves and focus on that. If a feature isn’t needed for the app to solve the problem, save it for a future release or drop it altogether. Apple likes simple. Users like simple. If your app solves the initial problem and finds any success, users will lead you down the feature path. Paying attention to features actually needed shortens the development cycle and minimizes the risk that you may be spending all your time on something that isn’t a viable product.

Do You Really Need That Feature?

Overcast - Development CycleMarco Arment has talked extensively about his podcast app Overcast on the ATP podcast. When it was first released, the big knock I heard everywhere was that it didn’t support streaming. A podcast app that doesn’t support streaming? Seemed odd. Not supporting streaming out of the gate had to do with how he was implementing his groundbreaking Smart Speed feature along with limitations of the streaming framework. Marco had revealed earlier that he knew this was a must sought after feature that he planned on implementing. At some point along the way, however, he came to realize that streaming wasn’t actually as in demand as it appeared. Most of his support emails were less about streaming and more about being able to save podcasts you’ve already listened to. So Marco has shifted gears and now has no timetable or commitment to offer streaming. I think it’s a good study in assuming a feature is crucial for survival when it actually isn’t. I remember thinking when I first downloaded Overcast that I wouldn’t end up using it because of the lack of streaming. After a week or so, I realized I didn’t miss the feature and have been a happy Overcast user ever since. Not only did Marco leave this seemingly obvious feature out of version 1.0, he has learned it’s actually not in as much demand as originally thought.


Should Developers Worry About iOS Piracy?

Monument Valley - iOS PiracyMonument Valley bucked the freemium model last year and was highly successful. They made news recently by discussing their download numbers. It seems the headlines focused on this: Only 40% of iOS downloads were paid. Does that mean that 60% of downloads were pirated? That’s what the headlines would make you think, but I found it difficult to believe that was the case.

The company later clarified by stating “a portion of those are people who have both a phone and a tablet”.

That is significant. When you consider how many devices the typical Apple household has, most of the 60% are probably not pirated. I don’t even play Minecraft and I have probably installed it at least four times on different devices for my kids and my own phone. Grabbing the 40% number for iOS piracy is just another one of those headlines that attracts eyeballs but has little substance behind it.

Build & Analyze iOS PiracyIndie developers of paid apps can spend way too much time trying to figure out how to stop iOS piracy. I remember a couple years ago I was worried about piracy on one of my paid apps. It was a $3.99 app and a good revenue producer. I spent a significant amount of time researching app piracy and everything involved. Like most of us, I had pirated plenty of software in my younger days, so I knew how common it was. Then I heard an episode of Build & Analyze with Marco Arment where he discussed the reasons he, for the most part, ignores piracy. His post here sums it up nicely.

“Or you could just ignore the pirates, since hardly anyone jailbreaks their phone and they’ll never pay for anything anyway, and spend that time making the app better to attract more paying customers.”

This is pretty much what I was thinking as I was researching this problem. It sucks to think that someone is stealing your software, but it’s not worth your time to risk hurting your current users with anti-piracy measures. Instead, spend your time coding, marketing, and coming up with great app ideas.

Should I Localize My App?

It seems everyone is pushing localization. Apple frequently reminds you in iTunes Connect that you’re missing out if you aren’t localized. There are tons of services, such as Smooth Localize, that specialize in affordable localization. I have apps that are localized and apps that aren’t.

But is it worth it to localize? You do open your app up to new markets. You also open yourself up to what can add up to a lot of extra work.

Localization Options

When we talk about localization, you can lump it into two options. First, you can localize your description, title, and keywords in iTunes Connect. This is the easiest and least expensive option. When you hear app marketing specialists talking about localization, this is often what they mean. This helps with app discovery in other countries. The problem with this option is that the user may expect they are getting a fully localized app, but find out differently when they actually download. This can lead to bad reviews and a general lack of revenue. I did this with one of my apps and did not receive any negative feedback. It didn’t feel right to me, though.

A full localization includes all the marketing material, iTunes Connect data, and the entire app. It’s not too difficult to do, but it can take a lot of time. Keep in mind, though, it’s like many Xcode related tasks. I recently spent a full hour updating a lightly localized app because Interface Builder wanted to fight with my localization string files.

Testing Your Localized App

Testing a localized app can be a pain. Some phrases take up more space in certain languages and cause truncation. Also, even if you use a reputable service, you are never sure if the message you are trying to get across, marketing or app text, is exactly how you want. One trick I have found is to make different schemes in Xcode for each language so that when you build and run, it automatically runs the app in the desired language. This is more efficient than manually changing the language on the device or simulator. Apple has a nice guide on this here.

Screenshots Are Not Your Friend

I quit localizing my app Who’s Calling mostly because creating tons of new screenshots for every update was more time consuming than the extra downloads are worth. I had built in all the localization, but I just didn’t want to hassle with all the work for every update. Imagine when the app preview video will need to be localized. Fun. Also, if you have more than one app, imagine doing all that work for each app for each update. More fun.

Customer Service

It’s easy to forget that when you localize an app, customers from other countries will now email you support questions. As someone who only speaks English, this is a problem. Talking to someone through google translate is not a productive way to communicate. If you do this, you’ll mostly end up with disgruntled customers and bad reviews.

The Numbers

When I look at my app Who’s Calling, 90% of it’s revenue is from English speaking countries. When I localized, I didn’t see many extra downloads for the eight or nine languages I targeted. I spent a ton of time customizing the app, including contact images for different languages, with not much return. In the end it wasn’t worth it. However, I did learn how to fully localize and that is worth something is my growth as an app developer. I try to have that mindset with everything I try. Hey, that bombed, but I added the experience to my app toolbox.

My Advice

If you are working on an app, I would launch the first version in your native language unless you have a compelling reason to localize in other languages. See how the launch goes and monitor you downloads in other countries. You can add localization to an app at any time (though an update) so you aren’t forgoing localization in the future. If it’s your first app, definitely skip the localization. You have enough on your plate just getting the core features down.

When you do localize, try a couple of the most popular languages first instead of adding ten in one update. You can also consider only localizing the iTunes Connect data at first, but be prepared for the drawbacks I mentioned above. For us in the US, localizing in Spanish should be the place to start.