Business

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, MacNNc|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.

Read more

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

sandboxPhoto credit: livingindryden.org

I’m very excited about the new operating system and the APIs it holds for developers.

One new feature that is going to be very popular amongst users and holds real benefits for them is the App Sandbox.

What is App Sandbox?

Entitlements

Basically, the App Sandbox needs developers to specify what kind of access to user data an application they create needs.

You basically start with no privileges (so called “entitlements”) at all and work your way up for what your app needs. 
Does it have open or save panels? You need an entitlements for that.
Does it need access to the network? More entitlements.
Does it need to access iCal or Address Book? Even more entitlements.

Apple states there are currently 15 entitlements, but the list may change in the future.

Containers

For data saved by applications, like preferences files, Core Data storage, “Shoebox” data, basically everything except Documents the user saves or are autosaved by OS X Lion, each application gets its own Container in /Users/yourname/Library/Containers/, like /Users/matthias/Library/Containers/at.EternalStorms.ScreenFloat/

An application that has no entitlements for file system access can not access anything beyond that folder without the user’s consent (a user can give their consent with selecting files in open or save panels or by drag’n’dropping items onto or out of the sandboxed application).

Deny, deny, deny!

Anything an application requests it doesn’t have the proper entitlement for gets denied by a process called sandboxd, the sandbox daemon. It manages the sandboxed applications and their access to things they are or aren’t entitled to.

This is what your Console looks like when something gets denied:

27.07.11 16:56:14,480 sandboxd: ([2460]) screencapture(2460) deny file-read-data /usr/sbin/screencapture

XPC

XPC helps take the sandbox paradigm even further, making apps even more secure. Instead of having one executable that does it all (access the web, access iCal data, access Address Book data, write stuff to disk, read stuff from disk), a developer splits these tasks up and basically creates for each of these operations a executable with just enough entitlements to do its work.

So if you have an application that can access your Address Book and the web, there’s nothing from stopping the app, had it been compromised, from sending that data to a server.

However, if you have two different executables, one with just the Address Book entitlement and another with just network access, it’s not that easy anymore for intruders to do their dirty business.

XPC lets these two executables talk to one another, inside their shared sandbox.

What is App Sandbox good for?

Something that has been said a thousand times in the WWDC sessions to make abundantly clear what App Sandbox is good for:

It’s a last line of defense against evil-doers.

If an application has been compromised, it can’t do anything beyond its entitlements. That’s a very good thing.

So what does it all mean for users and developers?

Users

For users, it’s a great thing to have in terms of security and privacy of your data and I think every user should be excited about it. I know I am. It’s a great solution to a problem that has been dragging on too long, and Apple stood up and took a shot at it, and I think they did very well. For the most part.

In terms of what app developers will be able to make for those users, well, that’s another story which I’ll explain next.

Developers

In general, for most cases, developers won’t have any trouble with the App Sandbox. Version 1.2 of ScreenFloat – which is currently in Review for the App Store – already is a client of the sandbox and I ran into no trouble with adopting the entitlements, what so ever. It does what it does, just like before, but now, it’s safer, and I’m very excited about that.

What worries me, however, and, judging from what I’ve read on Apple’s developer forums, worries quite a lot of other developers as well, are the so-called temporary entitlements.

Temporary entitlements are for certain cases where it’s not really safe to do something, but Apple hasn’t figured out a safe way to let the app do it yet, so they made an entitlement for it. A temporary one.

Let’s take, for example, iTunes. There are a lot of applications out there that can “remote control” iTunes with global hotkeys.
In the background, the application is sending out an Apple Script, or doing its work over the Scripting Bridge, or are sending Apple Events directly (Apple Scripts and Scripting Bridge work with Apple Events in the end, but it’s at a higher abstraction level API wise for developers like me, who have no idea how to create Apple Events in the first place).

For this case, Apple has created a temporary entitlement. Alright, so it works.

What bothers developers however is the term “temporary”. What _is_ temporary, exactly? Will there be a replacement once the temporary entitlements vanish?

Let’s look at a perfect example for this:

GimmeSomeTune and the App Sandbox

Some of you might have read it on Facebook, others may have on twitter, for those of you who haven’t, here’s what happened:

I’ve halted development on GimmeSomeTune because of the temporary entitlements, more so because of the questions I asked above that have yet to be answered by Apple.

But let’s take it one step at a time:

GimmeSomeTune gets notifications with userInfo payload objects from iTunes. That’s no problem yet, since iTunes is yet to be sandboxed. But once it is, it can only send notifications without userInfo payload objects, and that object contains all the necessary information, like Title of Song, Album, Artist, etc.

So GimmeSomeTune, in its current form, could work for some time, until Apple decides to sandbox iTunes. Boom! Rien ne va plus.

GimmeSomeTune downloads artwork and lyrics and sends them to iTunes through the Scripting Bridge. The Scripting Bridge is essentially sending Apple Events to the app you target, in my case, iTunes.

The sandbox allows for Apple Events to be received by an application (without entitlements), but can not send any, without the temporary entitlement. When the entitlement is no longer valid, the main functionality of GimmeSomeTune breaks. Boom! Rien ne va plus.

So what it comes down to is this:

GimmeSomeTune would work right now in its current state, with temporary entitlements and hoping that Apple will never sandbox iTunes so it will continue to send notifications with userInfo payloads (which is doubtful, since iTunes is your digital hub and all, so they’ll be sure to sandbox it at some point, I guess).

But what happens if iTunes was sandboxed?
GimmeSomeTune would break, it would not know what song is playing in iTunes and hence wouldn’t download information and send it to iTunes, rendering the application useless.

And what if the temporary entitlements go away without a proper replacement API?
Again, GimmeSomeTune would break and it couldn’t send downloaded data to iTunes anymore, again rendering the application useless.

Why not just release it and hope for the best?

Sure, I could release GimmeSomeTune with temporary entitlements and hope they stay around forever or that there’ll be a replacement API for them.

But I have to consider what happens if they don’t (which is, in my opinion, 100% certain) – angry users, having paid for software that doesn’t do its job.

I am not willing to take that chance. I will wait to see what Apple comes up with.
And if there is a replacement for temporary entitlements in the works, and when I’m certain GimmeSomeTune will work with it, without the fear of having the application break at some random point in the future due to functionality that is ripped out from under it, only then can I release GimmeSomeTune with confidence and the knowledge that its users will be able to actually use the app.

And I believe this is the right choice.

Sandbox at its finest

Would you like an example of what kind of apps are completely unsupported in the sandbox environment?

Applications that change developer-signed files inside of app bundles that are a) developer-signed and b) running in the sandbox environment.

May I present the worst case Scenario: PresentYourApps

Some of you may know this little app of mine. PresentYourApps lets you hide the menu bar and / or dock for applications you specify, making more screen real estate available. Or at least, it _let_ you.

On OS X Lion, it works some of the time, but I highly discourage you from using it on that system, and I will take down the download link in the next couple of hours.

I discourage you, because it breaks apps you use it on.

I got an e-Mail from a user who tried it on Preview.app on Lion, and after he restarted Preview.app, it crashed on launch. Luckily, PresentYourApps keeps backups of the file it edits, so the user could make Preview.app work again, but it was scary.

Well, PresentYourApps has been long overdue and begging for an update, but because of these circumstances, I decided to discontinue working on it all together and removing it from my website, since it will do more harm than good on Lion systems.

 

If you have any thoughts regarding all of this, or GimmeSomeTune especially, please be sure to leave a comment or contact me in any other way!

Thank you kindly for reading,
Take care,
Matthias

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

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

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

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

Read more

ScreenFloat

It gives me huge pleasure to announce the immediate availability of ScreenFloat – an app to increase your productivity on your Mac!

What Is ScreenFloat

ScreenFloat lets you create screenshots that float above all other windows. This way, you do not need to resize or move windows around just to keep a piece of information visible on your display.

 

It also lets you store information for later use with the built-in Shots Browser, which lets you categorize and manage shots you’ve taken with the use of tags, smart categories and categories (which are basically smart folders or ordinary folders).

How to use ScreenFloat

ScreenFloat gives you customizable keyboard shortcuts to do its stuff.

 

By default, cmd-shift-2 will let you create a floating shot and cmd-shift-1 opens the Shots Browser. Creating a floating shot works the same way as creating a selective screenshot (which is cmd-shift-4 by Mac OS X’s default).

What else is there to say about ScreenFloat

It comes with a system service. Which means, when you select text in any Cocoa application (like Safari orTextEdit), you can invoke ScreenFloat’s service to create a floating shot from that. This also has a customizable keyboard shortcut for the user’s convenience. ScreenFloat resides either in your Dock (by default) or in your menu bar.

Availability and Pricing

ScreenFloat is available exclusively on the Mac App Store, a demo is available through the website. You can get it for just €5.99/$7.99! For updates on ScreenFloat, you can follow @screenfloatapp or @eternalstorms on twitter!

 

Let me know what you think in the comments or by eMail!

Thank you and take care, Matthias

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

Read more