It appears there are some changes in El Capitan that affect code signing if you are using Sparkle. Read the full info at http://furbo.org/2015/07/23/code-signing-in-el-capitan/.
Guess Sam has to add the new --strict option too.
That will make him love Yosemite even more
the TL;DR; version is that the new codesign rules seem to choke on frameworks that have Symlinks to non-existant files. (I’ve always said that I think symlinks inside Frameworks are a dumb idea: They were originally created so you can have multiple versions of a Framework (a useful, if not terribly common feature) but then Apple tells you not to use Versioned frameworks. Also, symlinks don’t survive on non-HFS filesystems…
Sure why not, I’m only half way through designing a whole new engine…
Not sure that’s possible… Although I have to state that Apple are taking El Capitan bugs very seriously this time (unlike Yosemite). We’ve already seen a whole bunch fixed, thus allowing me to breath a little easier… but not too easy!
[quote=202450:@Sam Rowlands]@Michel Bujardet That will make him love Yosemite even more
Not sure that’s possible… Although I have to state that Apple are taking El Capitan bugs very seriously this time (unlike Yosemite). We’ve already seen a whole bunch fixed, thus allowing me to breath a little easier… but not too easy![/quote]
Good to read. Maybe given the real success they enjoy with their line of computers as compared to the Wintel PC sales slow down, and also with the arrival of a Windows 10 that takes bug reports very seriously, they started to realize that it was time to stop treating OS X developers as second class citizens.
On the other hand, if code signing on OS X was easy, there would be no room for your magic, and App Wrapper would not exist. Blessed be Ohanaware and its miracles
Any highlights for the new engine? Things we need (want) to know?
Nothing yet as it’s only in the design stages.
So it will make us a sandwich while it automatically figures out what’s wrong with the next unexpected change from Apple?
The whole new engine is designed upon how I currently understand the way in which Apple wants things signed… Even with all their documentation there is are unspoken rules which are only found through trial and error.
About code singing and OSX10.11
I have some users reporting my apps show the alert that states you are opening the app for the first time, never goes away after the first run. It shows up every time.
Some say rebooting and launching the app fixes this, sometimes it doesn’t and keeps showing the message dialog.
I cannot reproduce this here … but because several users reported this, it is strange.
Maybe I need to codesign my apps under OSX10.11 to get this issue fixed?
Do you deliver apps on a DMG? It’s very common for inexperienced users to open the DMG and then launch the app from within the DMG (rather than drag-copying it to /Applications). This could cause the behavior they are reporting.
It could be a permissions issue or a disk related issue as it means that the Quarantine bit is not being cleared.
Yes, I always use DMG. I will ask if the users launched it from the DMG. That could be very well the case.
I was explaining to a first time Mac user today, that when installing apps, they can come a DMG or a zip file or an installer. Coming from Windows, he’s used to apps coming as an installer, you double click and they get installed in the correct place.
Before the days of Sandboxing we developed some tech that we called “Install Easy” and it would detect if the application was in the Applications folder or not, if not it would ask the user if they’d like it moved into the Applications folder or not. We received some high praise for this feature alone, but alas with Sandboxing it’s simply not possible any more
It’s one of the advantages from the App Store, is that when you ‘Get’ an app from the App Store, they’re installed into the correct place for the user.
In app.open, you could check if your application has been opened from within the DMG and “warn” the user about
(if the path to the application is “/Volumes/NameofYourDMG/”) .
[quote=203035:@Detlef Kahner]In app.open, you could check if your application has been opened from within the DMG and “warn” the user about
(if the path to the application is “/Volumes/NameofYourDMG/”) .[/quote]
Thats is a great idea ! Thanks for the tip
Except for when the user has downloaded multiple copies over time (DMGName 2, 3, 4 …) or has renamed the DMG. For that, a flag that indicates a removable volume would be better.
I know that Christian’s MBS suite offers this in his FolderItem extensions and I suspect that the MacOSLib stuff probably has something, as well.
I’m not sure that multiple downloads of a DMG will cause a problem.
Also, I’m pretty sure (without checking) that the path: /Volumes/NameofYourDMG/ is not what you’re looking for. The name of the volume stored in the DMG will be the name you’re looking for.
Also, if the same volume has been opened multiple times (and they’re still open) then you will have a similar problem of “-n” being added to the volume name - where n = 1 to …
You can simply check if the app is in Applications…