Public Relations

March 17, 2015

When to Send a Press Release – Are Embargoes Useful?

That’s a question I’ve been asking myself ever since I started releasing software to the public.

Googling “When to send a press release”, I get articles talking about on what specific weekday to send it or at what time of day.
Or “send a press release when you have something newsworthy”.

Although that is good advice – never send anything not newsworthy, you’ll just alienate people – that’s not the subject of this blog post.

What I mean by ‘When’ is: should I send a press release a couple of days before I release an app or on the same day?
And yes, it is an “either – or” kind of situation. I’ve been told by journalists I asked if it’s cool to follow up a week after (or send the press release again) – definitely don’t do that.

Non-Embargoed Press Releases

To issue press releases the same day I release the app itself always felt natural to me. I’ve been doing it for as long as I’ve released software.
No advance notice, no follow up – just “send it and forget it”. I want to get the news out when it’s fresh and hot and when it’s available for everyone to download.

Control Is An Illusion

Front and foremost, it gives me this feeling of ‘control’. When sending out a press release the day of, I feel like I’m on the mind of the journalist and like they’re more inclined to write about my app since it is “fresh off the press” and just happened. And there might be some truth to that as I’ve seen good results with that approach. But you never have any control to speak of. That’s an illusion.

Secondly, there’s the App Store Review process. It takes time. So once the review is done and the app has been approved, I’m usually very eager to get the app out the door as soon as possible and not have to wait around a couple of days more to be able to send out press releases ahead of time.
I also don’t want to send out a press release while the app is still in review – that’s got ‘catastrophe’ written all over it.
If you send out a press release with an embargo only to have your app rejected some time later, you’ll have to issue a redaction and that’s just hideously tedious. It’s a one-way-ticket onto the journalist’s blacklist.
Even though there are apps for checking the average review times for the iOS and Mac App Stores, it’s just too uncertain in my opinion.

Forget me not

It’s not fun to spend hours writing a decent press release, send it out early to members of the media just to find out they forgot about it come the actual date of the app release. This is probably not much of an issue with bigger news sites and blogs that have systems in place for embargoed press releases, but smaller blogs run by independent reviewers might do all this by hand, so things might slip their minds.

Sending press releases with an embargo also has the risk of of the news leaking.
You send out your news with an embargo of one week, but that doesn’t mean that every member of the media is going to respect that – they might publish early to break the news first (a problem I assume only bigger companies face who’s news appeals to a broader audience than mine, a small indie developer’s press release; but nonetheless, it’s still something to be wary of).
I hear that embargoes aren’t legally binding, so be wary of that as well.

Embargoed Press Releases

With everything you’ve read by now, you might think sending a press release beforehand might not be a good idea. And you’re right, a lot of it speaks against it (although it depends heavily on each individual case).

But there is one thing about it that appeals to me more and more the longer I ponder it – with a press release you send early, you give your potential reviewers time.

Time for Preparation

Imagine being a journalist, getting a couple dozen press releases each day (or more) and some of them are to be released on the same day. There’s simply no way you could check out all those apps and publish on the same day. Pressed for time, a journalist might be inclined to just post the entire or edited press release, publish late or not post about it at all. But a full review is out of the question, that’s for sure.

If you issue that press release a week early, though, you’re helping out not only the journalists you’re addressing, but also yourself.
You give the greatest gift there is: time.

Time to check out your app in detail, less in a hurry to get to the next press release, because they do pile up, I’m sure.
Time to use the app for a few days, should they decide to cover it and get a deeper look at how the app works and feels.
Time to experience details about the app that make it stand out over its competitors.
Time to get more details about the app, e.g. check out the app’s Press Kit; ask you for more details if something isn’t clear or if they have any questions in general.

I believe that is invaluable for all parties involved.

Testing Embargoed Press Releases

To put this to a test, for the release of Transloader 2.1, I sent out the press release one week ahead of the release and the result has been way better than I thought. As I wrote before, I sent out PR with the bad aftertaste of thinking it would be forgotten on the actual day of the release.

But that was not the case. Quite the contrary, actually.

After sending out an embargoed PR, I pretty soon received requests for promo codes to an extent I have not experienced before. That might be attributed to the extended time frame they had for reviews, given the embargo. I imagine journalists don’t bother asking for promo codes if they don’t have the time to really look at the app anyway.

The embargo itself worked very well, not one site posted early. I used the following wording (in bold print) right before the press release body

Embargo: Please do not publish before March 10th, 2015

I think I will take out the “Embargo:” part, though, it sounds kind of demanding.

Among others, MacNN, c|net and the german site MacGadget posted favorable reviews of Transloader and @MacTrast called it their iOS App of the Day.

All in all, it went very well and I’m very satisfied with how it turned out.

Conclusion

I will be moving to embargoed press releases from now on. The benefits of giving journalists some time to check out your app by far outweighs the disadvantages listed above and I think it engaged journalists more.

And that’s what press releases are all about.

—-

My name is Matt, 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.

March 10, 2015

Transloader 2.1 Released – Action Extension, Today Widget, Push Notifications

Transloader 2.1 Icon

I’m happy to announce today the immediate availability of Transloader 2.1, a significant and important update to the app that lets you start downloads on your Mac remotely from your iPhone or iPad.

Transloader Explanation

I’ve also prepared an App Preview Video for the occasion:

[youtube https://www.youtube.com/watch?v=3VAKEpWVArc]

Easier and more straight forward to use

Transloader 2.1 features an Action Extension so you can add links directly from a website you’re browsing – here a short video of the Action Extension in, well, action 😉

[youtube https://www.youtube.com/watch?v=DPuCp9HO5So]

The update also comes with a Today Widget, which offers you a quick look at the state of your downloads right from within Notification Center.

Transloader's Notification Center Today Widget

Improved Feedback

Transloader 2.1 on the Mac will send your iOS devices push notifications when downloads finish or fail so you are always in the know about the state of your downloads.
The Mac app also got a UI overhaul and now fits in perfectly with OS X Yosemite.

On Sale – 65% off!

As part of Two Dollar Tuesday, Transloader is on sale today (March 10zh, 2015) for just $1.99 instead of $5.99 – over 65% off. Head on over and check out the other cool apps as well 😉

System Requirements

For full functionality, iOS 8 or newer and OS X Yosemite or newer are required. An iCloud account is necessary for Transloader to work.

Automator to the Rescue

I had the idea of using Automatorto create the screenshot and send it to Yoink. After experimenting around a little bit, I sent Bogdan a very rudimentary workflow (that could, if saved as an OS X Service, also be launched with a keyboard shortcut) and he immediately turned it into something awesome.

The Automator Workflow

This is the script of the workflow Bogdan came up with:

You can download the Automator Workflow here (~59KB) (tested on OS X Yosemite 10.10.1).

Setting up the Service

Download the Automator Workflow
Unzip it and double-click on the resulting screencapture.workflow file
In the dialog, select Install (except if you’d like to edit the script, then click on Open with Automator)
It will be installed in your ~/Library/Services/ folder:
To confirm installation, in Finder, click on Finder in your menu bar, select Services and find Capture Screenshot to Yoink in the list:
In your ~/Documents/ folder, create a folder titled Yoink (where captured screenshots will reside)

You have now successfully installed the Service to capture screenshots to Yoink. What you can do now is create a keyboard shortcut for it so you can more easily access this

Create a Keyboard Shortcut

Launch System Preferences
Click on Keyboard -> Shortcuts -> Services
Find Capture Screenshot to Yoink in the list, under General:
Click on add shortcut and enter the shortcut you’d like to use to activate the service.

That’s It

That’s all there is to it. Now you can create screenshots that are then immediately available in Yoink for you to drag around.

If you find it useful, be sure to let me know on twitter (@eternalstorms) or by eMail – I’d appreciate the feedback!

Take care!

Update (October 14, 2015)

I got a bit of feedback on this – especially feedback from Pietro S. and Jeremy M. pushed me to update this post with a bit more information.

To make the Automator Script capture the entire display instead of just a selected portion, replace the line ‘ do shell script “screencapture -i ” & filePath ‘ with ‘do shell script “screencapture “ & filePath ‘ (removing the -i option to cause the selection)
Jeremy was so kind to provide an updated Automator Workflow that appended a date and timestamp to the screenshot’s filename; add two actions before the actual script (“Get Value of Variable”) with the variables Date and Timestamp and import them into the script – as in this screenshot:
To use this Automator Workflow with the standard keyboard shortcut command-shift-4, you first have to deactivate the standard action in System Preferences -> Keyboard -> Shortcuts -> Screen Shots, or assign it a different keyboard shortcut:

A ‘thank you’ goes to Jeremy and Pietro for the updated workflows.

December 18, 2014

Using Yoink from the Terminal on OS X

Yoink for Mac Usage Tip #5

The following explains how to send files to Yoink from the Terminal, or a shell script.
For more Usage Tips like this, click here.

Here’s a quick tip for those of you who spend their days in OS X’s Terminal and want to use Yoink with it more easily. This is something that customers request quite a lot, so here it is for future reference 😉

terminal to yoink To send a file from Terminal.app to Yoink, you can use this command:

open -a Yoink /path/to/the/file

You can simplify this by creating what is called an alias command:

alias yoink=“open -a Yoink”

This way, all you have to type in Terminal.app is this:

yoink /path/to/the/file

This is a temporary alias and will work for the current Terminal session. If you’d like to make the alias permanent, please do the following (taken from this MacLife post)

To make the alias permanent, you will need to edit a file called “.bash_profile” by running the following command:

nano ~/.bash_profile

This will open nano (a command line text editor). Use the arrow keys to place the cursor at the bottom of the file, and type in the aliases that you wish to use, one per line, just as you did when creating temporary aliases. When you are done, press Control + O (Write Out) to save the file. Press Command + X to exit nano and go back to the command line.

When you quit and re-open the Terminal application, your aliases will work without having to re-create them each time.

I hope you find it useful – let me know if you have any questions or comments 🙂

Take care!
—-
My name is Matt, 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.