Posts tagged “layers

Layers for iPad

I started working on Layers for iPad the morning apple released the iPad SDK. I’d been looking forward to the release of the iPad for months, and it made sense to make a dedicated version of the app. I’d always had a difficult time drawing on the iPhone’s small 3″ screen. The iPad seemed like a perfect tool for professional artists–a digital sketch book you could carry anywhere.

The iPad’s larger form factor also raised new interaction questions. It was too big to shake, so the “wrist flick”-triggered menus in the original Layers app were out. It had more room for contextual information-toolbars wouldn’t significantly limit the size of the canvas viewport. The iPad also created new opportunities for community. It’s large screen was so good for showing off art that it seemed natural to allow people to post paintings and browse and comment on others work within the app. From the earliest phase of design, the focus was on building a community around the art people created on the iPad.

I spent about three weeks designing an interface for the iPad app, prototyping and fleshing out different screens of the app in Fireworks. Since I knew I would be doing the entire app myself, I didn’t bother creating storyboards using the individual interface mockups.

I like to write code during the design phase when I work on personal projects: a few hours of design, a few hours of code, repeat. It helps to step away from the designs every few hours. I started moving code from the iPhone version of Layers over to the iPad on day one, and a couple big issues became obvious in the first few weeks:

1. The display / memory ratio on the iPad makes it hard to keep display-quality images in memory. The iPhone version of Layers kept six 512×512 OpenGL textures in memory, but the iPad version isn’t able to keep six 1024×1024 images in memory. Fail!

2. Saving the image for each layer took more time (roughly 4x more, since there were 4x as many pixels) and caused the app to be terminated early when sent to the background.

3. Some procedures in Layers, like undoing a “Shift Layer” operation, took too much memory when the images were scaled up.

Unfortunately, I didn’t have early access to iPad hardware, so I didn’t know that #1 and #3 would be an issue until the app was actually live on the store. I got a ton of emails the week the iPad went on sale, and I skipped an entire week of class to fix the problems. The solution was a much smarter method of memory management that allows layers and parts of the undo stack to be paged to disk when the app receives memory warnings. It brought some major speed improvements to the iPad version, and I’ve since been rolled it back into the iPhone version.

Layers for iPad consists of 22,000 lines of Objective-C code, about 10,000 of which are shared with the iPhone version. The community component of the app is built in PHP and mySQL, and uses HTML5 and advanced Safari CSS 3 markup to create a convincing and “native” experience within the app. My experience building the community website was very positive. CSS 3 support on the iPad is great, I think web views are the best way to deliver native-looking and richly customized interfaces. You can even specify your own fonts. It’s beautifully fast. Had I chosen to deliver content via XML and render it all in custom UIViews, there’s no way I could have completed the app in three months.

In the first six months after its release, Layers for iPad was downloaded about 10,500 times. The Layers Gallery, the community built around content generated in the app, hosts thousands of paintings. The app was featured on the front page of the App Store during the week of April 28th, and was reviewed by TUAW and MacWorld twice! It was featured in Incase’s 2010 advertising campaign and billed as the favorite painting app of Ron Radziner. The Layers for iPad website has also received recognition for its clean, refined design on OneExtraPixel”, Designer Daily and Web Design Tuts+

After Layers was released for iPad, I worked with MEDLMobile in San Francisco to develop the app “Drawing Step by Step with Walter Foster” using the Layers painting engine to emulate realistic pens and pencils. During it’s first week on the store, that app was ranked #1 in Productivity.

App Store Piracy: Worse than you think.

Two weeks ago, a minor update to Layers hit the App Store. The update included several important bug fixes and a few features, but one of the most major changes was the addition of a piracy tracking system. Each time the app is used on a jailbroken device, it phones home with a few (anonymized) metrics so that I can track the spread of pirated copies. Software on the Layers server gathers the data and prints out some cool statistics.

Technically cool, that is. Not really “cool” at all. I’ve sold around 1,500 copies of Layers this week and in the same 7 day period, more than 1,780 copies have been pirated. It’s flattering, to some extent; people obviously enjoy the app. However, it’s also evidence to a much larger problem that I feel Apple continues to overlook. The DRM used in iPhone apps hasn’t been changed in ages, and an app on a jailbroken device can be automatically cracked using another iPhone app in a matter of seconds. No command line tools. No hand-editing files. You double click the app’s icon and it cracks it. Done.

For “expensive” apps like Layers, piracy is an especially significant problem. The latest version of Layers runs about 22,000 lines of code, and my community and target market are small. Everyone needs to chip in so I can recoup the cost of development and rationalize extra time spent improving the app. The App Store’s layout and “Top 100″ formatting encourage 99¢ apps with limited utility, so it’s difficult to market a $4.99 drawing app to begin with. (I’ve been lucky enough to be a Staff Favorite on the App Store) Piracy rates above 100% really don’t help.

So what do you do? I feel it’s absolutely necessary to weed out the pirates. I wouldn’t mind providing illegitimate users with a time-limited or feature-limited version of the app. The problem is, current methods of screening for pirated copies are binary-dependent and patchable. In about a week, Layers will start displaying notices to pirates asking them to upgrade their “demo” copies of the app to a full version or “buy me a beer.” I hope that a few people will appreciate the app enough after using the pirated copy to consider paying. Even a 5% pirated-to-paid conversion rate would be an extra 15 sales a day.

In the future, I’d like to see Apple implement a secure model for confirming that users are licensed to use an app. A secure receipts model is built in to the In-App Purchase system, and I don’t see why it wouldn’t work for the app as a whole. The app would establish a secure connection to an iTunes server, exchange product identifiers and account details, and verify that a product had in fact been purchased. I don’t think Apple will implement anything in the near future, because it would require admitting that piracy was, in fact, an issue. We can dream, though.

A few other developers I’ve talked to have suggested creating a repository of device identifiers that have been nabbed during phone-home routines. It seems like a good idea, but I understand there’s some hesitation to start calling people pirates left and right. Apps would need to pre-emptively contact the repository, and a simple change to the UNIX hosts file could break the system.

So for now, It looks like I’ll be dreaming of an extra 1,700 sales a week.

EXIF Orientation Flags and the iPhone Camera

Layers just came out this past Monday, and it has this great feature that allows you to add a layer to a drawing from your iPhone’s photo library. Simple enough – right? Apple provides the UIImagePicker API, we call a couple functions and get an image back. For most purposes, that would work great! Write some code, test, commit, done. The problem is, the picker interface allows the user to adjust the scale/positioning of the image, and the cropped image is always returned at 320x320px (or less)…