I just had my first title submission rejection from the App Store. The reason given? The small bundle icon does not match your large icon.

OK, so at first I was pretty irate, they both contain the same elements and it seemed pretty obvious. But after cooling down, I have to admit that objectively it is possible some customers would be confused … I still think the reviewer is being pretty nit-picky here, but I also know that end users can be very easily confused.

What do you think?

Fortress Luna App icon

Original Fortress Luna App Store image

We’re going to redo the app store image to match the icon, since the original image has too much detail to be reduced to an icon.

Conclusion: While it might seem that you only need a passing resemblance between the two, if you don’t want your app rejected over a trivial matter, take my advice and make sure there is no way someone can’t tell that the two images refer to the same app!

Begin RANT

OK, so the title is a little sensational … but this decision is going to cost me money, so I am understandably upset. It’s also a decision that seems to have no merit, and if rumor is correct was simply more of the NeXT clan forcing out any traditional Mac OS X functionality out of ?spite? … I don’t know why, but many of these decisions seem to be “NeXT is correct, Mac OS was wrong” vs. rationally motivated.

What has happened

For some unknown, apparently arbitrary reason, 10.6 no longer obey’s a file’s creator code. What this means is that it is no longer possible to attach a document to specific applications from code! I’ve tested creating documents in hexedit, bbedit, etc. and the documents created refuse to open in the creating program when double-clicked. It appears that they now belong to some ‘default’ program (textedit in bbedit’s case).

Is Apple trying to put all other software makers out of business?

I mean, if an end user creates a document in MyWordProcessor but it opens in TextEdit all of the time, which app are they going to keep using? This seems like a really sneaky way to pull of the same “integrate the web browser into the OS” crap that Microsoft did with Explorer. (OK, it probably isn’t, but it sure feels that way to a developer who now has to deal with, and pay for the handling of, hundreds of support issues.)

Seriously, this is incredibly broken!

The inability of programs to create documents that can be re-opened in the creating program by double-clicking on the document icons is a serious problem for both end users and developers. I’ve tried explaining this to various HexEdit users, but they only understand that it no longer works.

Beyond the document creation issue, the loss of this functionality removes a very valuable component from the Mac OS X filesystem. Creator codes, along with their associated data types, offer are _extremely_ valuable in Mac OS X and are one of the really great ways in which Mac OS X sets itself apart from Windows, linux, unix, etc.

Please, let us know what we can do to get Apple management to see the consequences of this decision so that they can restore a very marketable and valuable feature to Mac OS X.

Summary

Without this ability, I am finding that I am very annoyed, to the point of almost hating to use the Mac OS X finder, as so many things like opening documents works the way it used to. How irritating would Apple’s management find it if they had to go through three steps to open every document they worked on instead of simply being able to double click on them?

What Can We Do?

I am not sure we can do anything, but at the very least everyone who reads this needs to file a bug report and submit feedback against 10.6 via the official Apple channels:

Official Apple Feedback Form
Official Apple Bug Reporting Form

If anyone else has suggestions on ways to get Apple management’s attention on this, speak up!

End RANT

Memory Is Not Free!

While newer desktop machines are able to use hardware and/or Virtual Memory (VM) to somewhat take care of memory fragmentation, it is not always effective. While it differs with architecture and OS, VM is limited to somewhere between 2 and 4 GB unless your application is 64bit compliant. So, in general, yes, that means that you can run out of memory (no matter what your college instructor says). I have seen this happen often with Windows programs, most of which never check the return of a new or malloc and always assume memory is available.

On hardware like the iPhone (or pretty much any video game console) VM is either none existent or not functional enough to provide any real benefit to 3rd party applications. So just because you are working on newer hardware, don’t assume that you do not have to worry about heap fragmentation! Most programmers do not realize how badly they reduce the usable amount of RAM available to their application and simply can not understand why they can’t allocate 100K when there is 2.5 MB “available“.

Handles Rule!

Personally, I really like using handles in all of my applications and games, and use a custom handle based memory manager for this purpose in many cases, especially on “gaming devices” like the iPhone. Not only does it help with heap fragmentation, via movable memory blocks, it also has extensive debugging capabilities built in (corruption checks, leak detection, fragmentation reports, etc). My handle based memory manager is based on the Mac OS Classic memory manager, and features most of the same functionality along with some of the same limitations. The biggest “limitation” is the set amount of available memory. However, I personally see this as an advantage, because no matter what system you use you do have a limited amount of memory! Especially on gaming devices, so by being able to set that limit and have the memory manager tell you how you are using that limited amount of memory I can develop apps on a Mac OS X or Windows platform and retain the limitations of the destination device. And, even if the target is Mac OS X or Windows (or any other “modern vm” capable OS), I want to know how I am using memory. For instance, just because I have 16GB of RAM on my Mac/Win machine (I actually do have that much RAM), it does not mean everyone does. Everyone also does not have 2TB of HD space available for VM. And, in the end, if I have to use VM for my application, am I really providing the end user the best experience? I don’t think so!

By using handles I am able to provide all of the same functionality of new/malloc while at the same time offering improved performance (up to 1000% faster on mobile devices, where standard memory managers often suck hard), provide the application the ability to better manage it’s memory pools, avoid fragmentation of available memory, provide the application an easy way to use multiple memory pools, and get very detailed debugging information on memory usage.

Files Benefit too!

Instead of straight file use, or a .zip archive pak system, I use a Resource Manager equivalent as well, since using a bunch of files on these devices can literally kill performance. (ie, 5 minute load times to to 1/2 minute simply by bundling all files into a resource file on a Nokia N95 – opening and closing files can be extremely slow on non-desktop hardware). Now I don’t actually use file forks, but one or more typical “data” files that use a storage system similar (but not identical) to the Apple resource format.

The benefit to this is that data can be compressed on disk, reducing storage size and (often greatly) decreasing load times, providing the ability to override existing “default” data simply by dropping in a new file (similar to the way Quake .pak files work), etc.

But in terms of memory, the resource manager provides another benefit, in that all data is provided via handles, which means there is a way to provide cheap and easy caching (ie, if a data resource is already loaded, no need to load it again, just return the existing reference), and significantly less heap fragmentation via the use of handles for relocatable data and by putting resource data in “high” memory, while all “pointer” (ie, malloc/new style allocations) are in “low” memory.