OS/Vendor Agnostic – The perfect app store needs to work consistently across Windows, Mac, and Linux, and the only way to establish impartiality is to make sure none of the big vendors *own* the store. That said, in order to really take off it would probably need support from some of the major cross platform vendors like Adobe.

Platform Integration – The app store cannot be web only, it has to come with an installable store that manages your applications and lets you browse for new apps to purchase. On the flip side, web purchasing should also be enabled and publishers should be able to embed a framed version of the store in their website to make transactions more fluid.

Buy once, run anywhere – Publishers should be able to set options on whether applications are purchased once for all platforms or require small payments for additional platforms beyond the first one. Ideally you wouldn’t have to pay more for a different platform, but enforcing that rule may discourage publishers from putting in the time to port code.

Multi system – A single login should be usable on up to 5 systems.

Multi user accounts – Families should be able to easily add kids to their account and purchase software for them. Companies should be able to add and remove employees from a company account and assign software to different users. No need for separate company logins, everyone can just use their personal accounts.

Simple receipt system – Apple Mac Store pretty much nailed it on this one. Users don’t have to be logged in like Steam in order to run an app. The way it works is every application is responsible for finding and validating a digitally signed receipt when their app starts. Receipts are generated from app name, app version, and system id, and digital signed. Receipts can easily be downloaded when logging in to a new computer and easily voided when no longer valid.

Simple update system – Apple nailed this one as well, provide simple notifications that updates are available for certain apps, and then handle the process of installing that update.

Application upgrades – Publishers should be able to set options for users to get discounts on major upgrades if they own a previous version. Users should be able to enter serial numbers for existing applications to prove ownership of previous copies.

Cloud Storage – Apps can use up to 50mb of cloud storage per user, paid apps can choose to use a percentage of proceeds to pay for unlimited space for their users.

Developer Tools – Developers need strong guidance on how to package their apps and test them before going live. They should be able to download sample receipts for their app and test the installation process through the store itself before going live.

Freedom of Language – There should be no restriction on languages or technologies (think java) that are allowable in the store. Dependencies lists can be built over time into the store to help facilitate getting users the correct packages for certain apps to run.

I’m sure there’s a few other things I haven’t thought of yet, what would you add?

Today one of those ideas has come to fruition and I’m happy to announce it’s launch in the new Mac App Store. Space Gremlin is an app I wrote over the course of Christmas to visualize disk usage on a hard drive to help find and delete “gremlins” taking up too much space. It features a top down view of a disks folder structure and the relational sizes between other objects. It’s easy to drill in to folders or slice up the view to focus on important areas. While there are other apps out there on the Mac platform that address this concept, I’ve never found those other visualizations very usable or readable.

I’m hoping other people out there find Space Gremlin as usable as I do, so I’ve added it to the new Mac App Store to handle the distribution end. Since this is the launch and I’m still new to the whole Mac App ecosystem, I’m setting a launch price of only $3.99 but it will probably settle at a higher price soon after. I’ve also decided to go exclusive to the Mac App Store to avoid setting up my own purchasing and validation system.

Give it a try and let me know what you think. Big thanks to all the fellow developers and designers at EffectiveUI who helped me test this app. If you’re interested there is also a free demo available on the website http://www.spacegremlinapp.com

So why are all of the app store developers in this position? Apples current documentation on how to validate receipts is fairly complex, but the sample code and Apple own instructions ask developers to validate against data that is entirely external to the binary itself. Worse yet, it instructs developers to validate against plain text data easily editable with any text editor.

If you are an app store developer and you are using apples default security logic, you need to review these validation steps in your code

• Verify that the receipt bundle identifier matches the value for CFBundleIdentifier in the Info.plist file. If they do not match, verification fails.
• Verify that the version identifier string in the receipt matches the value for CFBundleShortVersionString in the Info.plist file. If they do not match, verification fails.

And change them to be more in line with this

• Verify that the receipt bundle identifier matches the value for CFBundleIdentifier that you hard code into your application.
• Verify that the version identifier string in the receipt matches the value for CFBundleShortVersionString hard coded into your application. If they do not match, verification fails.

At the end of the day, if your app is popular enough it’s going to end up on a pirated site, but for the time being, by following the instructions above, you can avoid having your app easily cracked with TextEdit. For those interested, Angry Birds only implemented 2 of Apples suggested validation steps, so the pastebin instructions will only work for Angry Birds, you need to do a little bit more for apps that handle all 5 validation steps.

Update, if you are using roddi’s receipt checking code from github, here are the offending lines you need to change.

BOOL validateReceiptAtPath(NSString * path)
{
	...
	bundleVersion = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleShortVersionString"];
	bundleIdentifer = [[NSBundle mainBundle] bundleIdentifier];
	...
}

I made a relatively complex png file for testing, the source file is a 230 kb Fireworks file, which is pretty close to some of the assets we have in our projects. A quick 24bit png export from fireworks produces a 6 kb png file with no visual fidelity loss. When the project is compiled to the device, the source image is compressed by xcode down to 19 kb, while the exported version actually increases in size to 7 kb. So far this supports the theory that manual compression can be up to 3 times better then letting xcode handle it for you.

Original Files in Xcode Project

Files compressed for iOS device build.

Additionally it seems that I suffered no visual loss by letting xcode recompress these png files, and decompression times for both pngs on the device took roughly 20 milliseconds each.

Honestly I think you could read these results either way, lazy developers may choose to just use source files in xcode and suffer a 3x penalty on images compression, for those that like to control the compression exactly on their files, you’ll be better off.

3.10 Images

To draw images onto the canvas, the drawImage method can be used.
This method can be invoked with three different sets of arguments:

 drawImage(image, dx, dy)
 drawImage(image, dx, dy, dw, dh)
 drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh)


Each of those three can take either an HTMLImageElement, an HTMLCanvasElement, or an HTMLVideoElement for the image argument.

The api lets you take the contents of specific HTML elements and draw them into a canvas, and the 3rd element in that list is just begging to be abused. Copying video into a canvas element means opening up the ability to manipulate or process video frames at runtime. Two concepts instantly came to mind that seemed like fun to try and figure out, here they are below.

Blowing apart fragments of video

Click around the video frame to blow up that part of the video, the exploded pieces will continue to play the video inside them. After a while they retract back to their original place. One feature I didn’t have time to figure out was adding depth to the explosion, so pieces that are closest to ground zero fly up into the air as they sail outward. With full shadow effects this could look really cool.

3D Video

This demo in particular runs really well inside webkit based browsers, but not so much in Firefox. Firefox doesn’t appear to have any hardware acceleration for Ogg decoding so I had to drop the video size in half in order to run at acceptable framerates. Even still, Firefox chokes pretty badly on my Macbook Pro.

*Update* – I’ve changed the ogg video to be 640 x 360, prepare to see firefox weep

Lessons learned

There’s a couple hints I found out along the way that are good to know if you want to play around with drawing video. First, you need a bit of hackish code to get this to work effeciently and it flows like this.

[Video playing] -> [Draw Video onto Canvas 1] -> [Draw fragments of Canvas 1 onto Canvas 2]

Don’t ask me why, but copying pixel data out of a video tag is expensive, so expensive that drawing it into a temporary canvas, and then drawing pieces of that temp canvas onto a final canvas is faster then just referencing the video tag repeatedly within the same loop. That’s why you’ll see 2 Canvases in the source code for the demos. I’m sure there’s a technical reason for this duplication process, but it’s a lazy reason.

Secondly, don’t try copying individual pixels around. You can still see the remnants of my first code attempt inside the explosion demo with getPixel() and setPixel(). This turned out to be horribly slow and completely unnecessary. Canvas.drawImage() + matrix transforms on the canvas space is far more efficient then handcrafted pixel pushing. On the other hand, pixel manipulation allows you to do things like runtime chroma keying, get ready for a new wave of “clippy” style videos with full transparency popping over websites to help you out.

Lastly, I’m learning very quickly that not all browsers are created equal when it comes to performance, it’s a crapshoot when it comes to heavy video+image manipulation. Safari and Chrome work well with h.264, Firefox slogs along with Ogg Theora, and Opera is somewhere in the middle.

My session will be running on Tuesday at 1:30 PM and again on Wednesday at 5:00 PM, hope to see you all there.

Update: I forgot to mention during my presentation, but the samples within the zip archive may contain memory leaks for the sake of code brevity. If you copy and paste the code samples into your own projects, you might need to make sure you add cleanup code to the end of it.

First up an example of what we’re able to accomplish with this effect.

You can magnify any UIView as well as the children of that view, images, text and 2d vectors are captured and magnified appropriately. There are couple critical pieces of this code to pay attention to.

First up, when a touch has been recorded long enough to kick off the magnifier effect, we create a new magnifier view that is the exact size of the view we want to magnify. This is important due to the way we’re going to be copying a bitmap of the original view. Once we know the view exists we call setNeedsDisplay on it which triggers drawRect inside of it.

if(loop == nil){
	loop = [[MagnifierView alloc] initWithFrame:self.bounds];
	loop.viewref = self;
	[self addSubview:loop];
}
UITouch *touch = [touches anyObject];
loop.touchPoint = [touch locationInView:self];
[loop setNeedsDisplay];

Next, when drawRect gets called inside the magnifier view we want to make a copy of the original view first. The reason the magnifier view is teh same size as the original view is because we are rendering the full context of the original view into our new context before grabbing a bitmap of it. If the magnifying view were smaller, the rendered bitmap would also be smaller. We want to cache the final bitmap so we’re not redrawing the original view every time the user moves their finger around the view. We’ll destroy that cached view and the magnifying glass when the user lets up off the screen.

- (void)drawRect:(CGRect)rect {
	if(cachedImage == nil){
		UIGraphicsBeginImageContext(self.bounds.size);
		[self.viewref.layer renderInContext:UIGraphicsGetCurrentContext()];
		cachedImage = [UIGraphicsGetImageFromCurrentImageContext() retain];
		UIGraphicsEndImageContext();
	}

Following that we need to generate a masked view for the magnified view to sit in, since the loop is a circle we have to mask out the corners and antialias the outer perimeter. This is accomplished using 2 images, the magnifying glass itself and a mask image with appropriate grayscale levels for masking.

CGImageRef imageRef = [cachedImage CGImage];
CGImageRef maskRef = [[UIImage imageNamed:@"loopmask.png"] CGImage];
CGImageRef overlay = [[UIImage imageNamed:@"loop.png"] CGImage];
CGImageRef mask = CGImageMaskCreate(CGImageGetWidth(maskRef),
					CGImageGetHeight(maskRef),
					CGImageGetBitsPerComponent(maskRef),
					CGImageGetBitsPerPixel(maskRef),
                                        CGImageGetBytesPerRow(maskRef),
					CGImageGetDataProvider(maskRef),
					NULL,
					true);
//Create Mask
CGImageRef subImage = CGImageCreateWithImageInRect(imageRef, CGRectMake(touchPoint.x-18, touchPoint.y-18, 36, 36));
CGImageRef xMaskedImage = CGImageCreateWithMask(subImage, mask);

Lastly, we’ll draw the magnifying glass and magnfied bitmap copy of our orginal view underneath the mask and we’re done. Since the iPhone uses a different coordinate system then other languages, we have to remember to flip the view upside down before drawing it.

CGContextRef context = UIGraphicsGetCurrentContext();
CGAffineTransform xform = CGAffineTransformMake(
					1.0,  0.0,
					0.0, -1.0,
					0.0,  0.0);
CGContextConcatCTM(context, xform);
CGRect area = CGRectMake(touchPoint.x-42, -touchPoint.y, 85, 85);
CGRect area2 = CGRectMake(touchPoint.x-40, -touchPoint.y+2, 80, 80);
CGContextDrawImage(context, area2, xMaskedImage);
CGContextDrawImage(context, area, overlay);

And that’s it, now we have a modular magnifying glass that can plug in to any UIView with minimal effort. If you’re looking for a way to add interactivity underneath the magnifying glass, like moving the cursor within a textfield, that’s gonna require a bit more custom code on the control you’re dealing with, and this example doesn’t really address that.

Download example: XCode magnifier example for iPhone.