How to make a failure as massive as losing your entire backup sound like a feature.
This is way too casual, it even makes it sound like I can just postpone this action and doesn’t clearly indicate that my entire backup is gone/corrupted.
Sorry about the ginormous/blurry image, this theme apparently likes to upscale.
A Few Words on the App Store
There are two articles on major publications covering Apple’s release of new guidelines this morning that quote me/Read It Later (one on the BBC and one on AP).
As both articles mention Read It Later’s recent rejection and my response to it, it does imply that I have a negative view towards the app store. (No fault to the writers of these articles, they only have so much space).
I wanted to make it clear that despite Read It Later and the App Review Team’s up and down past, I still hold both them and the iOS platform in the highest regard.
There is simply no other platform I enjoy developing on more than iOS. Hands down, not even a close second. I owe the app store the very fact that Read It Later supports my livelihood. I’m not sure of any other distribution channel that makes it so easy for me to push a product out to a worldwide audience.
It seems that I’m not the only one that feels this way as there are over 250,000 applications in the App Store today. And despite a few hiccups here and there, if you consider how large a number that is to process, the review team have done a damn fine job.
The release of these guidelines, and all of the other improvements the app store have brought to developers this year shows that Apple is absolutely doing the best they can to listen to us and help us succeed.
The only continual qualm I have is simply the difficulty in reaching anyone at app review. The guidelines mention that it’s possible to appeal to an app review board but make no mention of how to do that. I’ve also found a lot of emails to appreview@apple.com tend to go answered or seem canned in response. I realize the problem has got to be simply handling the sheer volume of emails and I’m confident they are working on a way to help improve developer communication. Today was a big step in that direction.
Apple Accepting iPad Apps Before We Have iPads
Of all the possible scenarios we (developers) considered for exactly how Apple planned to roll out iPad apps with the release of the iPad, this was the one I dreaded the most.
Apple is now accepting iPad applications to the review process. If you submit before March 27th, you may be included in the grand opening of the iPad App Store.
The only problem? No one has an iPad yet and won’t until April 3rd.
Anyone who has developed on the iPhone SDK knows that how an app runs on the SDK simulator can be night/day vs how it runs on the actual device. Even if it runs flawlessly on the simulator, I’ve never had an instance where the first time I ran a new app on the device it worked to my liking. There are bugs and crashes that didn’t occur on the simulator, there are slowdowns in areas that you thought were fast, and usability changes you didn’t expect.
So we are now faced with a risky decision: go for fame and fortune, submit an app and cross your fingers that it actually works or wait, miss the hoopla, and submit something you KNOW works.
The iPad: It wasn’t created for us.
I’ve had some time to think about today’s release from Apple, the iPad. I’m finding that the more I think about it, the more disappointed I am. But I know why: The iPad was not created for us (and by us I mean the tech crowd).
Take a look at today’s release. Remove all of the changes to the software and the new iWork/iBook products. If you look solely at the hardware and the device itself, there is nothing revolutionary here. There are no revolutionary new input methods, no new integrated additions (like the compass was to the 3GS and the camera to the Nano) and nothing new in form factor (aside from size).
Now look at the software. While the default apps like Mail, Safari, Photos, and Calendar got a refresh, the OS itself is fundamentally the same. The home screen simply has more space in-between the icons and a background image. In fact, even though you have a bigger screen, you still have the same number of icons per page. There is no multitasking, no OS-wide gestures, and no major APIs opened to developers.
The problem is the tech community expected to see iPhone OS 4.0 today. We expected to see something we hadn’t seen before.
All Apple did today was release the same product they already have, only bigger.
And you know what? It’s going to work.
The iPad is targeted towards all of the users who simply need a device to browse the web, check email, watch videos, go on Facebook, and play a little Farmville. And as Apple knows, this market segment is a LOT bigger than the ‘I need multi-tasking and Minority Report style input’ crowd. I bet that for the majority of people in Yerba Buena Center today, the iPad will not be their mainstay machine. Most of them will buy it, play with it, or develop on it, but most of our computing will be done on laptops and desktops.
The iPhone and iPod Touch have been incredibly successful. If Apple released a new device today that required a steep learning curve with revolutionary input controls and a new OS unlike anything we’ve seen before, your mother would not care. Your non-tech-savvy friends would not use it. What Apple is doing is simply taking something that works very well and making it reach a little farther.
So what I’m really disappointed about is how much I got sucked into the hype cycle this round. I’m actually really excited to read, watch, play, and develop on this device. The iPad is a going to be a great device, it’s just not the technological savior we were looking for. Still, as I look back at all of the really amazing things we all hoped the iPad would be, I realize that these ideas are now out there. It may or may not come from Apple, but now it’s just a matter of time.
In Defense of the App Store Review Process
Trust me, I know how badly the App Store’s review process can burn you (*Ahem*). In fact, while I’m on the verge of trying to push out Read It Later 2.0 as the busier holiday season approaches, I’m expecting even more frustration. Since Joe Hewitt quit the iPhone platform, a strong discussion has emerged and a lot of good ideas have been surfaced. However, one bad idea that both Apple and I know will never happen is: ditching the review process all together. Over the last few weeks, people have talked a lot about how the review process is bad for the open web. What I think is interesting about this concept is that the one company I believe is probably the most open of all, Mozilla, has a review process for extensions. All of those free, open extensions you have in your browser? Those go through a far more rigorous review process, have their actual source code looked over, and sit in a line generally longer than the one at Apple. Yet, even though this has been happening for years, I would bet no one has heard of any controversies there. I know this because of my time building add-ons but also because around the time of Firefox’s 3.0 release, I was an AMO Editor (extension reviewer). (Technically, I still am, but have simply not had the time to volunteer recently.) The review process is absolutely necessary. Mozilla’s reviews stop a LOT of junk from getting through to the end user. When you browse the AMO directory, you can be assured that every add-on in there is useful to some purpose and more importantly, it’s safe. It’s not going to steal personal data, it’s not going to install additional programs or do anything not clearly described in the description. Mozilla’s process, though longer and more in depth, differs from Apple’s in only a few ways. Yet, these make all the difference between controversy and satisfied silence.
1. Experimental Add-ons
Anyone can submit an add-on to AMO (Mozilla’s add-on directory), it will appear immediately and be available for download. However, this add-on is flagged as ‘experimental’ and when the user views/tries to install it, it warns them of the potential consequences of using untested software. After the add-on has been submitted it can be nominated for public status. There are a number of criteria your add-on must meet in order to be considered. Overall your add-on has to be useful to a wide portion of users, well tested, and has been received favorably from those who have tried the experimental version. Once it’s been nominated, it enters the review queue for an AMO editor to look over and eventually reject/approve it. This means that anyone can get into the directory immediately and start having people try their add-on. Once it’s flushed out further, they can push it through to the more public, much more lucrative (download wise) public side. If it’s an add-on that is only useful to a small number of users, it will stay as experimental and won’t clutter up the main AMO directory.2. Responsiveness
If you send an email to the AMO editors, you can almost always expect a response within a day. I am still on the email list for the editors address and from time to time check in, but I always see the editors responding quickly and generally with helpful information to answer the developers question. Often there is thoughtful conversation between the editors trying to determine the proper response before replying. This is the most important factor in a successful review system. A developer should be able to get any and all questions answered in satisfactory way as quickly as possible. In the way that Apple works, it’s generally pretty difficult to illicit much response from their blackbox. In the past year I’ve sent several emails over to Apple’s side and was often met with silence or in one case a month long delay before a response. This is unacceptable. I will say however, the most recent email I sent to the review team was replied to within 17 minutes. Though the response was short/vague it may mean things have certainly improved since earlier this year.3. Quick Modifications to Rejections
When an add-on is rejected, you receive an email with the reason why and the name of the reviewer. Generally, if the reason for rejection was something that can be fixed relatively quickly, you can email that reviewer back, say you resubmitted the fix and they’ll take another look at it. You won’t have to restart the lengthy wait to be reviewed for something that took you 10 minutes to correct. This is one of the loudest complaints you’ll hear from iPhone developers. If you wait in line for 2 weeks and then ultimately get rejected for something as minor as an icon, it’s incredibly frustrating to have to start all the way back at the beginning of the queue. The 2 week long wait will seem a lot less unbearable if you know you can still get approved given a minor oversight (or problem with policy).…
Mozilla’s system is far from perfect. It also suffers from one of Apple’s biggest problem in that updates to existing add-ons can take a while to get through the queue. However, the responsiveness offered by AMO’s team, means that if you are rejected for something arguable or minor, that you can still get through just after a few emails and a few changes to your code. Apple’s current process is running on ground that cannot stand for much longer. The number of apps is growing rapidly, and unless they hire hundreds of reviewers, it’s unlikely that all of these applications are getting thorough testing. From what we, as developers, have seen is that the review generally lasts a minute or two. From stat tracking to server logs, a lot of developers can see that the reviewer doesn’t even use all of the functions within the app. If this is the case, then the usefulness/stability of the apps appearing in the store are a lot less credible. They have over 100,000 apps in the store, but let’s be honest, a huge number of those are crap. It would be far more useful to the end user to have an app store that had less apps, but higher quality than vice versa. By implementing some sort of intermediary (like Mozilla’s experimental stage), they could offer developers a place to stand on their platform while being able to dedicate more time to those in the main app review process. More time means, better reviews, more responsiveness, and less of a wait time. The App Store review process certainly could use some improvement, but we need to accept that it’s there for good and push harder for smarter changes to improve the review process, rather than waste our time trying to abolish it.iPhone Developers: Prepare Featured Artwork Ahead of Time
If you are an iPhone developer, I’d highly recommend preparing Featured Artwork files ahead of time. If Apple contacted you and wanted to feature your app, would you want anything to stand in the way of that happening? I received a brief email from Apple in early in August requesting artwork for a ‘potential marketing opportunity’. The opportunity turned out to be Read It Later being featured in the Apple App Store. The email came in late on a Tuesday and had requested artwork files for first thing Thursday morning. In reality, this gave me about a day to put everything together and send it. However, during that time I was scrambling to get some other work finished before I left for a trip at the end of the week. There was no way I was going to miss the chance for whatever this opportunity was so I ended up having to forfeit some other important tasks in order to make room for this. It would have been much better if I had this work ready to go ahead of time. In fact, details about having these files are in the ‘developer guide’. The guide is linked to from the bottom of the iTunesConnect window and the details of the featured artwork are buried near the end of the PDF. Admittedly, I had never seen it, and from the developers I spoke with, a lot of others haven’t either. I wanted to share my experience so in case other developers were not aware of this they could be better prepared than I was. Though it meant I had to put off some other work that week to put the files together, the result of being featured was definitely worth it.
The Requested Artwork
They request two artwork files. The Apple designers will actually take bits/pieces from these and rearrange them as they see fit based on the image they are trying to create. (More on that below)
Title Treatment - This is a 600 x 600 image of your logo/title. The background should be transparent and it should exclude tag-lines if the text will not be legible at a small scale.
An example of the Title graphic for Read It Later is shown to the side.
Background Treatment - This is a 900 x 530 layered PSD. What you put in this file is fairly open. Apple states: “The background image, texture, color or gradient should correspond to the application or compliment the title treatment. It may include elements of the application itself, but should not be or include screenshots.”
The approach I took was to provide them with a gradient background in one layer and then a main graphic that could accompany the logo.
My Submitted Artwork
Just as an example (you wouldn’t send this together), here is a close up of the combined artwork:
Apple’s Design
As I mentioned, Apple will take the artwork you send them and put it together in a way they see fit. You should try to keep all the graphical elements in separate layers in Photoshop to make this easier for them. If you have some graphic elements that must be laid out in a specific way, I’d suggest merging the layers so the designers do not break them apart as they will not consult you prior to the graphics being made. Here are the three images that I saw during the time it was featured. As you can see, they significantly rearranged the graphics I sent them. (I think they turned out nice, just making the point that this may happen).On the featured tab of the App Store App:
Big promo on the main App Store page in iTunes:
Mini promo on the main App Store page in iTunes:
