Well, sure for small software developer, its fairly painless and you can work through the issues. But If you have many machines under your control in an IT department, you can’t just upgrade on a whim because of possible compatibility issues with existing software systems. That isn’t much of a choice, stick with the old O/S and live without the security updates or upgrade on Apple’s schedule.
Users always have the choice not to upgrade. And some do not upgrade for their own reasons.
On the developer side, however, I believe the choice is to go with whatever system will be on standard machines. If Mac comes with Mavericks, I have no other choice than to make sure my software works with Mavericks. Because customers are entitled to see software that works at the first click. Otherwise it means frustrated users, calls for support, requests for refund, and a whole lot of messy situations I rather do without.
As for Apple not supporting older versions, it makes sense. Why devote resources for a dwindling market ?
The Windows XP example being the exception that confirms the rule, because Vista was such a mess it could not be seriously used in the corporate world. Mavericks is far from being a mess, IMO
Sure when you have a handful its easy to do
When I worked in the corporate world we had many thousands in our province / state - and tons more world wide
So we were VERY selective in upgrading
I think there’s some credence to the idea that Apple made Mavericks free to update to to push adoption of it faster than might normally happen with a paid update
10.6 still had about 20 - 25% share of OS X installs and I think Apple wants to push those off the edge sooner rather than later and NOT have 10.6/10.7 turn into their XP
I’ll buy into that, but not providing security updates for Mountain Lion? Assuming the article is spot on and it’s true, seems like a disservice to me after plopping down $2300 on my MBP/Retina less than a year ago and Apple is now telling me I have a choice, to move to Mavericks and hope my apps and Dev tools work without big problems or live without security updates.
I am not a lawyer, but I am not so sure Apple can legally drop entirely all support for ML. The notion of fiduciary duty probably applies to ML when purchased with a machine, and if Mavericks cannot satisfy as a full replacement there is room for litigation. Chances are the excellent Apple lawyers have prepared for that eventuality ; all now rests in the level of compatibility between Mavericks and ML. If there are areas where ML cannot be replaced, there probably will still be some level of maintenance available.
Judging from what happened with previous releases, though, ZD-Net maybe quite right, and we should not expect much for ML anymore.
A little extra info: I have been using “FileStorm” as an installer for some years.
After refactoring my app to unpack the support files on first run, an installer wasn’t strictly required any more, but I stuck with it.
It appears that code signed installers created before Mavericks are causing install hassles for my Mavericks customers.
FileStorm installers create an app in a DMG which does the unpacking and placement.
And subcomponents of THAT (‘install tool’) are not code signed.
I didn’t spot this because my mac is set to turn off the nuisance about only allowing installs from the App Store etc.
So I’m about to switch to something like DropDMG instead.
Having tried and failed to code sign the component of Filestorm’s installer, I realised that all I needed to do was remove the installer app completely, and use FileStorm to build the internet ready DMG that it has been producing , (but using the ‘drag this app to the applications Alias’ method that is common elsewhere).
So I didn’t have to invest in another tool. (for now).
If any other FileStorm users are out there, happy to assist if needed.
I personally avoided the DMG method after getting too many complaints from users who could’t grasp the concept… So we went with a ZIP file and a smart-app (which would move it’self to the apps folder if the user wished).
Since Sandboxing that’s done, and so is auto updating… Which ironically brings me full circle to DMG… Where I should be able to download it and open it from my app, and perhaps now most people really understand how it works!
Sorry to bump this but is there any way to code sign a Xojo app successfully on Mavericks from the command line? I’m sure App Wrapper is great, but I don’t want to add another app/step to the build process that needs to be managed.
Currently in 10.8 I have one line for code signing Xojo apps:
codesign -f -s Cert Name AppName.app
Using this on Mavericks doesn’t work with gatekeeper, though it throws no errors.
If you don’t want App Wrapper, App Wrapper Mini generates Xojo Build Scripts so that it’s applied when you run or build your application.
Other than that you’re either going to have to write code sign functions to code sign all executable code in the bundle, before you code sign the bundle, alternatively you can use the --deep option. It is Apple’s temporary solution and does have limitations, basically it will work fine unless you have helper apps or custom plugins (in which case your easiest bet is to use App Wrapper).
While I’m the developer of App Wrapper, so it’s easy for me to spew how great it is, is does do a lot more than just code signing. A lot of people have said that this following table really helps them to understand the tool’s functions. http://www.ohanaware.com/appwrapper/mini.php#comp
But I do also understand that there are people out there who would prefer to use alternative solutions.
Thanks for the response, Sam. Can app wrapper be integrated into my automated build setup? I’m currently using DropDMG and some apple scripts via a few command line prompts and it works great. Didn’t see anything about command line integration/build automation when looking through the App Wrapper page.
App Wrapper can indeed, it does support being called from a Xojo Script and has a function to generate the script code for you. It’s slightly different in that aspect as Mini is purely build script based, where as App Wrapper just uses a script to pass the app to it’s main executable.
There a 15-Day trial of App Wrapper, so you can give it a test drive first, I’ve created a help topic on how to embed App Wrapper into a Xojo workflow.
I just looked at the description of App Wrapper Mini and never would have guessed apart from you saying it on here that it works by generating Xojo Build Scripts. In fact I think my colleague wasn’t interested in App wrapper for the same reason as Tom, namely that it didn’t integrate into his build process. I’ll let him know about App Wrapper Mini and have him have a look at it.
It might be interesting to make it a bit more clear on the site description that App Wrapper Mini generates a Xojo Build Script and therefore integrates perfectly into peoples build processes.