[Sparkle] Sparkle Integration Questions - Customized Applications

[Dean Shavit]

On Jan 27, 2008, at 7:13 PM, David Symonds wrote:

> On Jan 28, 2008 11:50 AM, Dean Shavit <acn-lists- 
> dean at macworkshops.com> wrote:
>> You're completely misunderstanding how the application works, but
>> that's OK. Whether it goes against Apple's guideline's is of little
>> concern to me. BTW, under Leopard, it just pops up a trust warning,
>> it doesn't break anything. If Apple furnished a way to do what we're
>> doing, under their guidelines, I'd follow them, but they don't.
>
> I'd consider "just pops up a trust warning" to be breakage. That's the
> whole mess that Microsoft gave ActiveX users, to the point where
> Windows users don't bother reading those security dialogs any more and
> just click "OK" instinctively.

I am just trying to accomplish a task / solve a problem here, not  
argue the design of our application and its associated service with a  
purist.

>
> I don't need to understand how your application works, because
> application bundles are not meant to be changed by the application.

Well, if you took the time to find out, you'd realize that the  
application doesn't change its bundle at all. As a matter of fact,  
I'm trying to accomplish just the opposite, to get certain parts of  
the bundle to remain the *same* as they were prior to the update.

> That's a bad design, and almost every other application manages to
> avoid needing to do that. Apple *already* provides several ways for
> application customisation via various places in ~/Library, etc.; why
> can't you use any of those?

Because it can't be distributed that way. For each subscriber to our  
service, we create a custom application - that's part of the appeal.  
Once created it never changes itself. Updates are a challenge,  
because our subscribers want the apps to update themselves  
automatically. If we didn't have custom versions for each subscriber,  
we'd have no problem, but that's not possible. Even if we were to  
update the app "in place" it would still be a new app, and would pop  
up the warning at first run.

I have three options here:

1) Forget about Sparkle, and use my own update system
2) Find a way to make Sparkle work, and cache the personalization  
during the update process, then put it back into the app. Pkgs are  
appealing because of the preflight and postflight scripts which can  
do just that

And the last method, which I haven't tried yet. but which I'm sure  
you'd approve of, is to create an appcast for each customized  
version, which is would require updating / altering our backend  
server process, which is not out of the question.

I appreciate your input and understand your concerns. I will post the  
selected solution to the list and hope you'll approve, but honestly  
our customers' approval takes priority.

>
>
> Dave.
> _______________________________________________
> Sparkle mailing list
> Sparkle at lists.andymatuschak.org
> http://lists.andymatuschak.org/listinfo.cgi/sparkle-andymatuschak.org