Mac App Store

One of my biggest gripes with the App Store is not being able to contact customers who leave a review directly.

A tweet by @fafner (developer of the App MindNode) today, August 13th 2014 in which he asked if developers read reviews on the App Store, made me think about this some more.

The one thing I really miss about selling Apps on my own, outside of the App Store, is the contact you have with your customers.
If there was a problem with one of my Apps, they had to contact me directly, since there was no other way. And we could take things from there, have an ongoing stream of communication.

With the App Store, customers are inclined to leave a review of my App with feature requests, bug reports or more general criticism rather than contact me directly. Even though I make it very easy to write me through my website and the Apps themselves.

While I really appreciate every review, there’s nothing more frustrating than getting a review about, say, a request of a feature that, unknown to the reviewer, has already been implemented and not being able to tell them about it (replying to the review with another review of your own app is possible, but there’s little to no chance the customer will ever read it, plus you’d have to rate the App to do so and that opens up an entirely different can of worms (in short: don’t do it)).
Or even worse, you get a bug report and you can’t contact them for more information in order to reproduce it.

What I currently do when this happens is fire up google and search for the reviewer’s nickname – a more than often lengthy procedure. When a Twitter, Facebook, YouTube, tumblr (and so on) account finally comes up, I use that to contact them, well aware it might not even be them – it has happened before that I contacted someone and they were the completely wrong person. It’s embarrassing, but they usually understand and think nothing of it.

It takes a lot of time and nerves that’s only worth it if you have the right person in the end. Otherwise, that time could have been so much better spent.
Additionally, you’re never entirely sure if they check their messages on YouTube, for example.

I understand why the App Store doesn’t allow for direct contact from the developer to the customer. First and foremost, it’s a privacy issue and that’s more important now than it ever was.
Threaded comments on the App Store seem unappealing to me as well plus it could escalate quickly if the customer or developer gets upset for some reason, so threads would have to be curated somehow. Also, other people could chime in in what was meant to be a two-way communication. Unfavorable as well.

Nevertheless, a solution on Apple’s part would be favorable. Actually, I’ve filed bug reports (radars) with Apple on how they could improve this.

They are based on the premise that not the developer initiates contact, but the customer does (and why wouldn’t they want to – they bought the App, they want it to work).

One (rdar://13367865) is to pop up a “Contact Developer” button when a user selects two or less stars for a review on the App Store. It might also be based on keywords (crap, useless, sh*t come to mind ;))
So the user selects one star and before they can click send, another button is shown directly next to it asking the reviewer to contact the developer. Problem solved.

The other one (rdar://13379347) is for crashes. You know how, when an Apple App crashes, you get a text area to supply some more information and send that to Apple?
This could also be done for third-party Apps.
The developer could supply their support email in the Info.plist (a collection of metadata for the App, like version, copyright info, etc) in the App’s bundle.
When the crash happens, you get a crash report window. Additionally to the buttons “Reopen” and “Cancel”, there could be a “Contact Developer” button, if the email has been supplied in the plist. You click it and it opens up a new mail message with the crash report already attached, leaving the possibility for more info (or it is done in-window like the Apple App Crash dialog).

Developers do get crash reports through Apple’s iTunes Connect, but that’s all they get. There’s no contact information attached (again because of privacy issues, of course).

It surprises me that not more work has been done in that area on the App Store.

—-
My name is Matt, and I’m the developer of Eternal Storms Software. If you’d like to comment, you can catch me on twitter here: [twitter-follow screen_name=’eternalstorms’ show_count=’yes’] or by eMail.

Read more

As I am now back working on flickery after a short hiatus – sometimes you need a little distance from a project to be able to reflect on it and maybe get a new perspective on some things, I figured I’d talk about the process as I am working on it, not after, in a so-called “post-mortem”, as my memory is now fresh and “in medias res”.

Before going into about what’s coming though, allow me to go back to see what’s been.

A New Beginning

Starting from scratch is usually admitting to having screwed up before. In flickery’s case, I wouldn’t say I screwed up completely. I am, however going to say that I could have done some things better. In some parts, a lot better.

Creation Date of flickery 1

I started developing flickery 1.0 in early 2008. That’s a long time ago. I’ve become (I hope) a better programmer with a deeper understanding of how things work and are supposed to work. I have (a lot) more experience in Cocoa and a better understanding of UX and UI. I don’t let myself get away with things that work ok but could be better that easily anymore.
This is a good time to start from scratch.

Why start from scratch?

flickery 1 crashlog

They say the way your desk looks, your mind looks. If you apply that to the code base of flickery 1.x, you’d commit me. It is not a pretty sight.
It’s really hard to look at, it’s difficult to follow and understand… it’s a fine mess, to be honest.

So one part of the reason why I started from scratch is that I didn’t see the forest for the trees (the app for the code) anymore.

Additionally, things have changed a lot in OS X since 2008. Which makes version 2.0 a good point to get rid of all the legacy code (individual code paths for OS X Leopard and every iteration that came after) and create clean code for OS X Mavericks and newer. (Mavericks is a no-brainer, it’s a free upgrade, everyone should go and get it.)

There’s blocks, ARC and Objective-C 2.0, just to name few. Going back to flickery 1.0’s code and re-working all the parts might very well have taken just as long (if not longer) as starting anew. It was totally worth it.

New Back-End

ESSflickr classes in flickery 2

Absolutely essential for flickery is it’s communication with flickr’s API. Incidentally, in flickery 1.x, that was the #1 cause of crashes and bugs.
I’m not going to tell you how I did it back then; it’s just too embarrassing.

This time around, I’m not making the same mistakes again (all the while hoping I’m not making any new ones).

Let’s just say, in the old backend, I handed NSDictionaries et.al. back and forth. I didn’t use any XML or JSON parsing, I did it all with NSString’s rangeOfString, etc., not always checking if a range existed before working with it. As I said – embarrassing.

So the first thing I did was switch from getting XML from flickr’s API to JSON and not parsing it myself, but letting the system do it. That’s a huge load off my mind right there.

Secondly, I’m done with handing NSDictionaries, NSArrays, etc., around. The new back-end returns proper objects that contain the necessary info in an easily accessible and understandable way.

There are a few Objective-C wrappers for flickr’s API out there, but I didn’t like any of them. They let you do this (pseudo-code)

NSDictionary *responseDict = [SomeFlickrWrapper executeMethod:@“flickr.photos.search” withParameters:someDictionary];

Aside from also handling OAuth and signing methods, etc., this is all they let you do. So you have to remember the methods, the parameters – it’s really not a wrapper, it’s an access point to the API.

What makes my back-end different is this:

- (ESSflickrGallery *)createGalleryWithTitle:(NSString *)title
description:(NSString *)description
primaryPhoto:(ESSflickrPhoto *)photo
error:(ESSflickrError **)alert;

You call the method and the back-end does all the parameter and method stuff for you. It’s much neater. In this example, you can also see the use of custom classes instead of dictionaries. ESSflickrGallery, ESSflickrPhoto and ESSflickrError are all wrappers for responses from the API, neatly packed up in an easily accessible class.

I guess I could have used one of the available back-ends as a back-end for my back-end, but I figured, if I’m going through the trouble of matching all available flickr-API-methods, I might as well do the OAuth and signing stuff myself as well.

This new back-end doesn’t only make things easier to develop, read and understand, it also improves the app’s stability and performance (mostly because it’s easier to develop, read and understand 😉 ).

As you can imagine, this has taken up the most time up until now. Now comes the fun part of using it to create the next version of the app.

I hope you’ll enjoy this upcoming series of posts about the development of flickery 2.0 and some of the design decisions behind it.

Upcoming in Part 2

In part 2, I’ll talk about uploading to flickr with flickery 2.0. Lots of suggestions will make it into the new version 😉

Thank you for reading. Enjoy your day!

My name is Matt, and I’m the developer of Eternal Storms Software. You can follow me on twitter here.

Read more

Briefly Icon

Proudly Introducing: Briefly

Briefly is my brand new app for Mac (and soon, iOS) that I’ve been working on since October 2011 (yes, that long!) and I’m so happy I’m finally able to release it.

It’s my first content-creation-app (as in, you produce something with this app). All my other apps are utilities or apps that help you get things done in a quicker or easier fashion, but this one actually lets you create something cool 🙂

3 final

What is Briefly?

Still Motion videos are a fun and neat way to show hundreds of photos within a short amount of time. Say, you want to show all your vacation or holiday photos, or photos from a hiking trip you took but don’t want to sort any of them out. With still motion videos, you can show them all.

Briefly lets you create those videos with just a few clicks. Add your photos (from your hard drive, flickr and/or Instagram), an optional soundtrack and let Briefly do the rest.
It will create your video (up to 1080p – Briefly can also choose the best resolution automatically to reduce or completely eliminate black borders around your photos), fade out the audio if it is longer than the video at the end and let you publish it on popular video sharing sites like YouTube and Vimeo, as well as Facebook and flickr (yes, Briefly is the reason I wrote ESSVideoShare (blog post about that here)).

Pricing and Availability

Briefly is available exclusively on the Mac App Store for currently $4,99 (35% off). The iOS version will be released later this year on iOS 7.
As is tradition, a free, 15-day trial is available for download here (direct download here, 4,7MB, zip).

 

Thank you for reading – I hope you enjoy Briefly and my other apps 🙂

Warm regards,
Matt

[twitter-follow screen_name=’eternalstorms’ show_count=’yes’]

 

Read more