I seriously doubt that it is. It's probably good for games and "most" programs, but I cannot see Apple making it robust for other software. If they had a robust standard and approved 3rd party installers, that would make more sense.-Renegade
It works for linux distros, doesn't it?
On Windows, I'm pretty annoyed at the various installers that are around - I really don't care for fancy looks for installers, I'd like something lean_and_mean with a sensible, clean interface. On Windows we get the full range from gradient-colored full-screen win9x looking yuck, OK looking installers that don't let you specify install location entirely as you wish, over-the-top crap (game installers... no, I don't want a custom-skinned app showing images or videos, I just want the damn thing to finish ASAP so I can play the thing!), to horribly
overcomplex crap (SQL Server 2008, I'm looking at you!). Give me something standardized and clean. Sure, some degree of configurability is needed, and finding the sweet spot is going to be hard... but program installation should definitely not look very different from app to app. Heck, for stuff that doesn't need component selection, make it a one-click experience.
Configuration can be done after installation if defaults aren't good enough. For bonus points: support automated installation of a whole bundle of applications, and an option for component selection and initial configuration from user-supplied XML files.
Microsoft has tried steamlining the
experience somewhat through the use of MSI... but people are still writing annoying custom installers on top of that, and for some reason MSI installs always seem to be ungodly slow. Sure, I don't want a failed installation to leave junk behind, but
ugh.
"kext" = Kernel EXTention. Then why are they running BSD? Dunno. It just seems like this is one of those areas that limits or excludes all low-level system utilities. I think a kext to replaced Finder would be wonderful, given how unstable/nightmarish Finder is; Finder makes Windows Explorer seem like Heaven (it's that bad).-Renegade
Perhaps I've misunderstood what kexts are, but I thought they're - more or less - equivalent to a Windows driver: code that's going to run ring0 have have full system privileges. You
really don't need that for normal apps, and I can't see why you'd need one to replace Finder - a normal ring3 app O_o
Sure, some system level utilities
might need drivers, but it's going to be very few. Root privileges is a completely different matter.
The always running nonsense like Java and Adobe Reader are certainly annoying, but I seriously doubt that Apple can provide a robust solution to meet the needs out there. Developers will end up hacking stuff up. If Apple provided a robust set of functionality that could be reasonably used, this wouldn't be a problem. They don't. Apple developer tools are entirely substandard.-Renegade
The linux repositories can handle it, so why shouldn't Apple be able to? There might be stuff that has to be changed, but imho the
idea of centralizing updates is nice... applications might have to be allowed to either set an update interval, or poll themselves, but please rid us of the countless background processes and per-app steps for applying updates.
2.25 is sensible, even if I'm not sure I entirely like it.
-f0dder
2.25 Apps that do not run on the currently shipping OS will be rejected
Not everyone updates to the latest OS, and there are specialized issues for each one. So why this? It doesn't make sense. In a perfect world, sure.-Renegade
Requiring that an apps runs on the latest OS doesn't prevent it from running on previous OSes, unless Apple is doing something very fishy... and I assume the AppStore will be OS X only, so we can exclude trying to support both System 9 and OS X
Sure, it does mean developers will have to test their stuff on latest-and-greatest - but IMHO that's not really a bad requirement. People tend to get pissed off if they upgrade their OS and it breaks their apps.
2.26 Apps that are set to auto-launch or to have other code automatically run at startup or login without user consent will be rejected
I choked a bit on this one. Then I thought about it again, and thought no - this needs to be there. The reason being that it eliminates all software that uses an agent. This effectively eliminates all enterprise software. It's simply a blanket that's too broad. When you install certain kinds of software, this is implicit. Adding a consent question for the user relies on Apple's installer being robust, and simply asks the question again. For a lot of software though, this should rule them out. But it should not cover agent software, which it does.-Renegade
If I'm running an app where I don't expect agent software to run, I'd
like being prompted about it. If I'm expecting agent software to run, I wouldn't mind ticking off a checkbox and ignoring an EULA. (Hopefully, instead of EULAs it could be a short description of
what needs to run... perhaps backed by an EULA to keep the vultures happy).
2.27 Apps that request escalation to root privileges or use setuid attributes will be rejected
Exactly. This precludes low-level system utilities, like backup software.-Renegade
Yep. But I'm still not 100% sure whether it's an acceptable requirement or not... if the AppStore is going to be the one-and-only source of applications, it's definitely bad. If it's only targetting "normal" apps, it's definitely a legitimate requirement. I'd probable prefer something inbetween, like marking root-requring apps with a big fat warning and requiring the user to tick a checkbox during install.
2.29 Apps that do not use the appropriate Mac OS X APIs for modifying user data stored by other apps (e.g bookmarks, Address Book or Calendar entries) will be rejected
I waffled on this one as well. The standardized ways are usually the best, but Apple doesn't make certain things possible. e.g. It was only recently that Apple opened up its video and graphics API enough to allow Adobe access to hardware acceleration needed for Flash.-Renegade
What does the graphics API have to do with "user data stored by other apps"?
Apple doesn't have a track record for being open or making things easy, so I can't see this as a good thing. What it really says is:
2.29 Apps that modify user data stored by other apps will be rejected unless they stick to our rigid, limiting ways of doing things
Now, for the Addressbook or Calendar, this makes sense. But for a blanket statement across all software, which it is, doesn't make sense.
This precludes the concept of software suites. You can no longer have a suite of software that interoperates with different components of the suite.-Renegade
OK, perhaps it is too broad... while I doubt it would be used against app suites, it
would make application interop between vendors harder. OTOH, the rule says
modify, not access, so you should still be able to
import data from other apps.
What I'd want is "use the standard locations and APIs, and don't clobber other app's data, you fool!".
2.30 Apps that do not comply with the Mac OS X File System documentation will be rejected
Again, this is one that I waffle on.
But I still think it's a bad idea. Here's a concrete example...
Mac OS X is simply very bad with external USB storage. It cannot maintain a connection to a device, much less read from them at acceptable levels. The only way to fix this would be to have a low-level fix, which would require access to system resources, and hence, system areas of the computer, which 2.30 excludes. It could/would also require exceptions for 2.15, 2.18, 2.21, 2.24, 2.25, 2.26 and/or 2.27.-Renegade
I don't see how 2.30 has anything to do with flaky USB - unless "File System documentation" means something completely different in Apple-land, it would mean (the mac equivalent of) "stuff binaries in /usr/bin, user data in /home/
user, don't spread your crap all over the filesystem".
A fix for handling USB storage badly would mean fixing kernel code, whether it be sloppy architecture or a bad driver. Not something a third-party developer should attempt hacking together as a kext...
The biggest problem is that they are wide-sweeping generalizations that preclude entire genres of legitimate software. They're throwing the baby out with the bath water.-Renegade
That they're very broad
is problematic - from the list I would have assumed it's just an overview, with details for each point being available?
Basically, I see that list as a weapon for Apple to club developers with, and not a way to protect people from malicious software.-Renegade
And I wouldn't be surprised at all if that's what they're going to do... so yes, in the context of Apple being Apple and the broadness of the rules, the points I've commented on
are... problematic. But, at least if narrowed in scope (and perhaps if applied by somebody not Apple
), I still don't think the
requirements are bad.
Recent Posts
)