Lately I’ve been on a kick…instead of wishing for software to work the way I want, I’m just gonna build it the way I want instead.
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
Crude instructions have started showing up online with ways to circumvent Apples Mac App store receipt validation. By simply copying receipt and info.plist data from a free app and pasting it into a paid app, you can run apps copied from friends computers or bittorrent. I myself have a copy of a paid app (not angry birds, but one with stronger protection) running on my system that was purchased by a friend. This is a massive failure in the implementation of Apples receipt system.
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 was having a discussion with a coworker about png compression for the iphone and wanted to resolve the issue of whether we should bundle Fireworks source assets in xcode for quick editing and recompiling, or if we should export compressed versions to use for the bundling phase. I know the iPhone does it’s own compression and byte reordering on pngs, but I wasn’t sure how much compression was done, so here’s the answer.
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.