I'm writing a modification for Arduino that turns an Arduino board into a game controller.
In order to add my board-specific files to the programming environment, right now, the user needs to open up the Arduino.app package, and then add a few different files into a various folders in the Arduino.app package. It is hardly user friendly. How can I make an installer which automatically moves my files into the appropriate locations within Arduino.app, or is that impossible?
You can download PackageMaker (available here, in the Auxiliary Tools for Xcode download).
You will then be able to make a .pkg that the user will be able to install simply by double clicking. You can also make a script that will check if Arduino is already installed and stop the installation if it's not. You get the idea.
Normally, especially in today's code-signed MacOS app approach (where any modifications to the app or its resources/files would break the app & make it not-launchable), I would say "you're out of luck".
But Arduino is one of the rare OPEN SOURCE apps.
You can fetch the source code from this page:
http://arduino.cc/en/Main/Software
And make your modifications to the project and then build a fresh, customized copy for yourself.
I figured out how to do it using the magic of scripting!
You can take a look at my solution here:
http://code.google.com/p/unojoy/source/browse/#hg%2FLeoJoy%2FLeoJoy%20Installer.app%2FContents%2FMacOS
The folder structure it's in makes it show up as an app on OSX, and the two scripts (LeoJoy Installer and LeoJoyInstaller.command) copy the files. There's two scripts there because I wanted to have a console window pop up to show the user progress, and that's the only way I could figure out how to do that. But, if you run this app in the same directory as the Arduino app, it copies files from the installer app into the Arduino.app package, updating the Arduino app so I don't have to distribute a whole separate version of Arduino.
Related
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 began coding Objective C last night and i made my first basic Cocoa app for my Macbook Air.
I have built it and everything, but i can't find the executable app in the project folder?
I am using 5.1
A faster way would be:
In the Project Navigator (if it's not shown: cmd + 1 or View -> Navigators -> ...) expand the folder Products, then right-click on the ".app" and then "Show in Finder"
Look in ~/Library/Developer/Xcode/DerivedData. Then find the folder for your program.
Build data doesn't go in the project because (i) it's logically a separate thing; (ii) therefore you want to keep it in a separate place; and (iii) keeping it in the same place will usually confuse the issue of source control, either your repository or you.
Apple's preferred approach is that you Build -> Archive, which will (unless you've specified otherwise) always be a release build, then export as a .app or publish to the App Store from the Organiser.
That'll keep that version of the build with all symbolication data on your machine until you delete it. So you can send exactly the same build to someone else, definitely decide any crash logs that come back, etc.
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 a small software for MacOS with a simple dmg installer (Open, drag and drop to Application folder, you know). My problem is, that the software writes a small ini file inside the .app package and if I update the software, this file is lost, because the old package is removed before writing the new one.
My question is, if any of you know an elegant solution for this. The user should be able to save the file in any place e. g. desktop and the ini file should be moved into the new package. I don't want to save this file outside the .app package, because this would leave private data on the computer if the user just removes the package.
Thanks in advance!
Saving data into the aplication bundle is no good practice,
for future release, please implement another solution.
To solve the current problem, I can think of two solutions:
Add two files to the .dmg file
The new application.
Backuptool: An simple AppleScript to backup the file would do the job.
Make sure to notify the user to run the backup before replacing the application.
The user might however forget to run the backup, and loose data.
Create an installer
Another option would be to write an installer using PackageMaker.
PackageMaker provides options to run scripts before updating the Application.
Add an pre-installation script that backups the data.
I have make one application Cocoa using XCode. Now I want to make setup file of project. So other user can install this project directly in his system.
In short, the polite way is to build your app with the Release Configuration, put it into a Disk image with Disk Utility or zip it up, then put it on a server and have people download it.
If you want a longer and more detailed answer, read Apple's Software Distribution Guide.