I have a Cocoa application for which I've changed the name. I'm using the excellent Sparkle Framework (http://sparkle-project.org) to provide updates to my users.
Unfortunately, it appears that Sparkle doesn't support application name changes out of the box. I'm hoping there is some hack so that I can provide users who already have the app with an update to the newly named version.
I'm not sure this is possible using only the vanilla Sparkle framework. The reasoning is that the file name of the application can differ from the CFBundleName defined in Info.plist. Sparkle needs to ensure it is updating the correct file system structure, no matter what it may be named.
Consider the following scenario:
User downloads and installs Adium.app whose CFBundleName is Adium.
User renames it to Instant Messenger.app.
Sparkle downloads and installs an update.
After the update, the file name of the newly updated app is still Instant Messenger.app and the CFBundleName is still Adium.
You can either hope that the fact that your application name has changed in the menu bar will prompt the user to rename it themselves, or your can pull some trickery at application startup to quit the application, rename it, and re-launch it if certain criteria are satisfied. I don't recommend the latter though, users do not like applications deciding to move themselves around without permission.
Related
4 Performance: Hardware Compatibility
Performance - 2.4.5
Your app uses still one or more entitlements which do not have matching functionality within the app. Apps should have only the minimum set of entitlements necessary for the app to function properly. Please remove all entitlements that are not needed by your app and submit an updated binary for review, including the following:
com.apple.security.files.downloads.read-write
It is not appropriate to predetermine the path that the user may have their files located.
Apple has indicated it is not in their judgement that your application requires reading or writing in the Downloads folder without user specification.
Disabling the com.apple.security.files.downloads.read-write will still allow users to save and open files located in their Downloads folder through standard interfaces (NSOpenPanel, NSSavePanel).
Note that it will disable your application from saving and opening arbitrary files in the Downloads folder without first being selected by the user.
I have an existing OSX app that supports OSX 10.5 onwards. I want to publish it to the AppStore and therefore I need to sandbox the app. I guess sandbox app should be supporing 10.7 onwards.
The app uses a folder in the username directory to create temp files etc
It also copies a sql db file which already has empty tables to the same temp folder and upates records as the app is used.
Furthermore if there is a crash it picks up logs from the crashlog folder of osx and requests user to submit them to developer.
Question
with a sanbox app, where do I store temp files ?
Where should I place the db file which can be read/witten to + new App update should be able to find exsting db file.
Should the custom code for crash reporter be kept or be made redundant ?
Thanks
where do I store temp files ?
In the directory recommended by NSTemporaryDirectory(). (This applies to both sandboxed and non-sandboxed applications.)
Where should I place the db file which can be read/witten to
In your application's Application Support directory. Use NSSearchPathForDirectoriesInDomains() to find it, then append your application's name. Again, this is the same whether you're sandboxed or not.
new App update should be able to find exsting db file.
Not possible. You can ask the user to locate the existing file with a NSOpenPanel, but you can't open it yourself, because it'd be outside your sandbox.
Should the custom code for crash reporter be kept or be made redundant ?
You'll need to remove it, because it won't work under sandboxing — crash reports are not stored to your sandbox. You will receive crash reports for your application through iTunes Connect.
Alternatively, you may want to look into a third-party crash reporting service like PLCrashReporter.
There is a mechanism to migrate the data of an existing App into the sandbox: Migrating an App to a Sandbox on developer.apple.com
This is done once the newly sandboxed app is launched the first time. If you can determine where the database was stored, you can migrate it into the sandbox.
Some time ago, we distributed a toolbox to our users via the MATLAB App Packager, to make it easier to provide future updates, without users having to handle search paths. Now, we wish to distribute an updated version. Usually, re-packaging the toolbox should make a new .mlappinstall file, which asks the user to upgrade. Instead, MATLAB now considers the new version of the app as a unique new app, and installs it again rather than upgrading. Thus, the user will then have the app twice in the Apps pane, one in an outdated version, and one in the new version.
We have been unable to find an explanation for this in the MATLAB documentation nor online. When we install the updated app (so that both versions are present in the Apps pane), further changing it will upgrade it as expected, so unfortunately, we cannot provide a minimal working example, as we cannot reproduce the issue.
The question is this: How does MATLAB establish app uniqueness? The app name and author fields are identical to the original values, and the version number is incremented, so why might MATLAB not recognize that the app is already installed?
When you had that discontinuity, were you re-packaging using the original .prj file by clicking on it in the file browser in Matlab, or did you run "Package App" again and fill in the same properties?
I think the thing that determines the unique identity of the app is a GUID that is generated behind the scenes by the "Package App" wizard. If you open an existing .prj in the Matlab GUI, it re-uses that GUID. If you run "Package App" again you'll get a fresh GUID regardless of what you put in for the various developer-visible app properties.
You can dig around in the .prj and .mlappinstall files to see this yourself. (I couldn't find it documented anywhere either; I just poked around the files and did some trial and error.) The .prj is just XML, and the .mlappinstall file is a zip file with an "Open Packaging Convention" layout. In the .prj, there's a param.guid element containing the GUID. In the .mlappinstall, its in metadata/appProperties.xml in a GUID element.
If you end up with the same problem again, make sure to re-package using the existing .prj file. Or if you don't have it, once you create your new .prj file, dig the old GUID out of the metadata/appProperties.xml from the old .mlappinstall file and copy it in to your new .prj file and I think it'll behave as the "same" app. This will even let you change the name and contact info for your app, and it'll still install on top of older versions.
I am trying to get my app submitted to the mac app store and I am having a bit of a design problem. Our app is an authoring tool and comes bundled with many projects created with the tool. Before the time of the app store, we would ship our app as an .img file which contianed a project directory and our app. Since I am only going to be submitting the .app file to the app store
with my app I am wondering where I should but the projects directory.
Initially I tried to put the projects directory inside of the bundle but this will not work because it is possible for the user to make changes to projects which might add new files to the project directory and this would make the sandboxing unhappy and mark the app as invalid.
What is the correct place to store such resources? I assume they should go inside the container? If so, what would be an elagent way to deploy this projects directory? Since we do not have installers in Apple land what would be the best place to deploy this projects directory? Do I just need to check on app launch if the projects are present and if not copy them from the bundle? This seems wrong.
Do I just need to check on app launch of the projects are present and if not copy them from the bundle?
Actually, this sounds right to me. As you said, the user cannot change/add any files in the app bundle. If you have resources there that the user needs to interact with, I would copy them to the ~/Library/Application Support/MyApp/ folder when they are needed. The user can then interact with the files from that location. (When sandboxed they go into a different but related location.)
I don't really know what your app does, but it would also seem like a possibly useful feature to "reset" the project files/folders back to a starting state. So copying the files in this way would allow for that kind of behavior as well.
I have an application to be distributed.
Pretty much everything is self-contained within one bundle so I could just put the bundle in a DMG for the first version-- however this won't work for upgrades, so I figured I'd best work out the process ahead of time.
I've been looking at PackageMaker and it seems straightforward enough. However I have a couple of very specific requirements which may cause problems, and it wasn't apparent from reading the PM docs as to whether this is even possible:
First of all, I want the installer to automatically choose between installing two different versions of the app, depending upon whether a previous version of the application has previously been installed.
Secondly, I don't want to just overwrite the previous application's bundle, I just want the installer to overwrite files within it and add new ones -- in other words, I want certain files within the application bundle to remain from the previous version.
Is this something I could achieve with PackageMaker, or should I look for a different approach?
You can do a lot with an installer package, for example run a shell script which in turn allows you to do everything.
I get the feeling that you're doing it not the Mac way. It's uncommon to store data in the application bundle, normally such stuff goes to ~/Library/Application Support/. I presume that those two different applications are quite similar, why not just set a preference?
Personally, I feel that today a .zip is the best way to distribute your apps. It gets automatically decompressed and shows up with your application icon in the downloads stack. (Only if you get it from the internet, of course.)
For updating look at the sparkle framework. The forst install is just copy the application bundle from the internet and te user then just asks to do update and does not have to leave your application to do anything