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.