 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / March 2007Installer with XCode?
Hello, Im not very experiencede with Mac. I have a windows app (written withQt/C++) that I want to port to Mac Os X. As far as I can see all the (best?) current programming tools (compiler, linker, make utility etc )for the job are included in XCode, which ships with Os X, right? Are these the recommemded set of tools for OS X programming? Are things like Code Warrior outdated now? Does XCode also come with a (decent) installer (that I can use to deploy my app on a clients computer), or would I have to buy that separately? If the latter, what would you recommend? In the installer Id need to be able to detect the presence of a previous installation (the app itself or some other app from me sharing the same files), and where it was installed, and being able to call my app with certain parameters before uninstall (allowing it to do any necessay clean up). P.S How much of a reduction on hardware would being an "ADC" member entitle one to, if one were to buy a new Mac? Thanks in Advance. Peter > Hello, > [quoted text clipped - 5 lines] > XCode, which ships with Os X, right? Are these the recommemded set of > tools for OS X programming? Are things like Code Warrior outdated now? Yes to all of the above. With a caveat that there may be newer version of the tools freely downloadable from Apple's developer site than are included in any given retail package of the OS. > Does XCode also come with a (decent) installer (that I can use to > deploy my app on a clients computer), or would I have to buy that [quoted text clipped - 4 lines] > parameters before uninstall (allowing it to do any necessay clean > up). The first recommendation is that the overwhelming majority of after-market Mac OS software doesn't need an installer. If you think you do, it's worth stepping back for a few minutes to consider your design. (And if you're planning on doing the quickest possible recompile of your app and making no other changes, please understand that you're likely to see a _lot_ of negative feedback.) If you do determine that you really honest and for true need an installer, there's one included with XCode. While it has a lot of room for improvement, it is up to the tasks you describe above. > P.S > How much of a reduction on hardware would being an "ADC" member > entitle one to, if one were to buy a new Mac? Officially, that information is covered by developer agreements as non-disclosable. But it's not terribly hard to find via Google. Hello Gregory. Thanks for the prompt and helpful answer. > Yes to all of the above. With a caveat that there may be newer version > of the tools freely downloadable from Apple's developer site than are > included in any given retail package of the OS. Does XCode also come with a visual debugger eg for single stepping (+ variable value display), through code (like Visual Studion Ms windows ?) > The first recommendation is that the overwhelming majority of > after-market Mac OS software doesn't need an installer. If you think you > do, it's worth stepping back for a few minutes to consider your design. > (And if you're planning on doing the quickest possible recompile of your > app and making no other changes, please understand that you're likely to > see a _lot_ of negative feedback.) Im not sure I understand. Like I said, I not currently well up on Mac usage (just Unix/ Linux and WIndows). Unix/ Linuxis different, but on Windows for example users usually are very likely to avoid apps that dont come with an installer that takes care of all of the dirty details (creating shortcuts, copying installation files to a destination directory, checking that the insttallation isnt breaking any other app by overwriting existing common libraries, with older versions of same etc), allowing clean, simple uninstallation etc. I personally also want to be able to cleanly and easily update my app (eg with minor bugfixes). This should be a one-click no hassle affair for the user. The installation for the update should be able to determine where the app was installed (on WIndows Id have the app write to the system registry, and the update read from same), and what version is current. It should be able to abort if the app isnt installed yet or is in a later version. The installer for the app itself should be able to start the app after successful installation if the user wishes etc. If a user uses several apps from me, the corresponding installations should check that they never overwrite a common (shared by my apps) library with one thats older etc. The installer should also pack all installations into a single installation file for single step download from my website. These are the kinds of things I mean. Does the installer that comes with XCode (alow one to) do this kind of thing? Im not sure why anything like this should result in negative feedback, and why this kind of thng isnt common/expected on Mac? Maybe you could explain what it is you meant, that I obviously didnt understand. > > How much of a reduction on hardware would being an "ADC" member > > entitle one to, if one were to buy a new Mac? > > Officially, that information is covered by developer agreements as > non-disclosable. But it's not terribly hard to find via Google. Strange. Why should that be a secret? I just need to find out if the resulting reduction is worth the couple of hundred bucks for the membership. Best Wishes Peter > Hello Gregory. > [quoted text clipped - 7 lines] > variable value display), through code (like Visual Studion Ms > windows ?) It does. > > The first recommendation is that the overwhelming majority of > > after-market Mac OS software doesn't need an installer. If you think you [quoted text clipped - 11 lines] > any other app by overwriting existing common libraries, with older > versions of same etc), allowing clean, simple uninstallation etc. As far as installation specifically, on Mac OS users generally expect that installation will consist of at most one step: Drag the application icon or directory from the distribution medium to wherever they want to keep it. They also expect to be able to run apps from the distribution medium. Mac users generally do not expect or appreciate apparently-straightforward applications leaving support files scattered in obscure locations on their machine and many will suspect that an apparently-straightforward app that comes with an installer is planning on doing just that. Part of why I suggested taking a step back is that there are relatively few bits of distributed stuff that legitimately need to be in specific locations, and a user is unlikely to be pleased with software that arbitrarily imposes such a requirement. Here's a page worth reading carefully if you're going to go forward with automated installation: <http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/ Articles/WhereToPutFiles.html> But my warning was broader than simply the installation process. It's about making sure that you get the common command keys right, and the common menu items in their expected locations. It's about making sure that the OK and Cancel buttons in dialogs are placed where Mac users expect them relative to each other (which is the opposite of where Windows users are used to seeing them). Things like that, that are going to have users cursing you if your software doesn't conform to the muscle memory and heuristics they've developed over as much as a quarter century. A good cross-platform toolkit can spackle over the API differences, but the user experience is almost guaranteed to need some rejiggering to be acceptable. > I personally also want to be able to cleanly and easily update my app > (eg with minor bugfixes). This should be a one-click no hassle affair > for the user. Right. They should be able to drag the new version from the distribution medium and replace the old copy. Or they should have the option not to replace (with the understanding, of course, that data files may no longer work with the older version once they've been touched by the new one). > The installation for the update should be able to > determine where the app was installed (on WIndows Id have the app > write to the system registry, and the update read from same), Mac users rearrange their apps sometimes. > and what version is current. It should be able to abort if the app isnt > installed yet or is in a later version. If you do your versioning right, Finder itself is fairly good about warning users if they're about to overwrite a file with an older version. > The installer for the app > itself should be able to start the app after successful installation [quoted text clipped - 6 lines] > These are the kinds of things I mean. Does the installer that comes > with XCode (alow one to) do this kind of thing? Yep. Except for the implied warning about users moving things. The installer doesn't have a clue what the user has done with their disk after the installer finished running. > > > How much of a reduction on hardware would being an "ADC" member > > > entitle one to, if one were to buy a new Mac? [quoted text clipped - 5 lines] > resulting reduction is worth the couple of hundred bucks for the > membership. Apparently it isn't any more. (But, apparently, the discounts are less significant than they used to be. Which is probably why they're less secretive now.) > Hello Gregory. > [quoted text clipped - 7 lines] > variable value display), through code (like Visual Studion Ms > windows ?) Yes. > Im not sure I understand. Like I said, I not currently well up on Mac > usage (just Unix/ Linux and WIndows). Unix/ Linuxis different, but on Largely, Mac OS X _is_ Unix. Isn't Tiger SUSv3? As I said, Xcode is GCC based, which makes it much like Linux and FreeBSD (though they don't have the GUI and Interface Builder). > Windows for example users usually are very likely to avoid apps that > dont come with an installer that takes care of all of the dirty There are GUI installers on Unix (Sun tends to use Java-based installers, funnily enough). Otherwise almost all have some sort of (wildly incompatible) package management system. A bientot Paul > > Hello Gregory. > [quoted text clipped - 26 lines] > A bientot > Paul Coming from the Unix/Linux world myself, I think I understand your confusion friend. Mac users don't typically get "installers" in the same sense that Linux doesn't get installers. Instead what you would normally package as a .deb or .rpm in linux (not techinally an installer, just a package), comes across on the Mac world as a .dmg (disk image, a hold over from the old days of floppies I guess). The easiest way I've been able to think of a .dmg is like you or I would normally think of an iso. Only in the Mac world they they double click the .dmg which "mounts it" and then they drag they application over the to the Applications folder, which handles all the gory details of installation for you. Think of it like distributing your application as an iso (CD Image), only instead of the user burning it to disk, they just mount it whenever they need it. Thats probably the closest correlation you'll find. As an aside I absolutely loathe XCode, it's a real pain to use thus far for me, for instance highlighting multiple lines of code and hitting tab should adjust indent, but in XCode it removes the lines completely. I've found much better success just using Eclipse + CDT, and having it manage make files for me. Eclipse has made the transition to Macland much, much easier. (Note I don't do a whole lot of GUI work, mostly console stuff such as servers and the like) By the way, be careful over at the Apple Developer Connection, seems like everytime I pull sample code, XCode and Eclipse both complain that major sections of code have been deprecated. This appears to be due to some transition from the original Apple "Quickdraw" interface, to some shiny new thing called Quartz which appears to be an OpenGL Accelerated 2D API, but I'm having one hell of a time finding any information on it, such as code samples and the like. FYI thus far I've only gotten Console Apps to compile and run without any warnings about deprecation, I can't even get a window to spawn without the compiler complaining about deprecated code. Hope that helps, and if any better informed Mac developers could correct me on anything I've said I'ld really appreciate it! > As an aside I absolutely loathe XCode, it's a real pain to use thus > far for me, for instance highlighting multiple lines of code and > hitting tab should adjust indent, but in XCode it removes the lines > completely. Preferences->Indentation->Tab indents: change to "Always" A lot of your other complaints could be remedied by close examination of the preferences, but it really would need a "Don't suck so hard" checkbox to be complete. > By the way, be careful over at the Apple Developer Connection, seems > like everytime I pull sample code, XCode and Eclipse both complain [quoted text clipped - 3 lines] > Accelerated 2D API, but I'm having one hell of a time finding any > information on it, such as code samples and the like. Probably because from an API standpoint it's called CoreGraphics. That should help you find docs and sample code. Quartz is more of a marketing name. That said, Quartz/CoreGraphics is not (currently) hardware accelerated and shares very little in common with OpenGL, although you can enable Quartz 2D Extreme in Tiger if you use the Quartz Debug application, and this will pipe Quartz stuff through OpenGL. It's buggy and slow, though. > FYI thus far I've only gotten Console Apps to compile and run without > any warnings about deprecation, I can't even get a window to spawn > without the compiler complaining about deprecated code. In Xcode, File->New Project->Cocoa Application, then go through the remaining panels. When you have your project there, build and run, and there you have a window spawning with no deprecated code. (In fact, you'll only have a single line of significant code at all, but that's beside the point.) Use a Carbon Application instead if you want a pure C app.  SignatureMichael Ash Rogue Amoeba Software Thanks very much for all the helpful replies and comments. Seems like Mac users like to take more responsibility than their Ms Windows counterparts ;-) There are still a couple of situations where Im not sure it wouldnt be a good idea to use a "proper" installer though (rather tha let the user "copy" the app files to the Application directory), or if there are different conventions in the Mac world. For example: Shared Libraries: If I have several related apps which share some common libraries (dlls on windows, and I only want one copy of each on he user's machine) My (un)installers would be able to check that the common files are never overwritten with older versions or removed if another of my apps which uses them is still installed. Small updates: Id like to be able to produce updates for my apps. To keep the download size to a minimum Id like to be able to only include only those files necessary (changed) . The update installer however could check that the other necessary files are all there, and give the user an appropriate message if not (eg if he tries to install an update without already having installed the app itself) Local Settings: Sometimes Id like to be able to write setting to a directory outside the app directory (eg when running my app from a network computer Id like to be able to save user preferences locally). An uninstaller would give my app a chance to clean up here (delete the settings files). Do these seem like valid reasons for shipping an app with an installer on MacOsX, and if so would the installer that ships with XCode be suitable/good for this? > Thanks very much for all the helpful replies and comments. > > Seems like Mac users like to take more responsibility than their Ms > Windows counterparts ;-) It's fluctuated quite a bit for both platforms, but in general I've observed a feedback loop such that Mac users are more likely to complain to developers and expect results, and Mac developers are more likely to react to the complaints of their users. > There are still a couple of situations where Im not sure it wouldnt be > a good idea to use a "proper" installer though (rather tha let the [quoted text clipped - 8 lines] > overwritten with older versions or removed if another of my apps which > uses them is still installed. Shared libraries on the Mac are interesting in that it's possible to have multiple versions of the library code installed concurrently and allow applications to link against whichever version they prefer to use. If you build your shared libraries correctly, unintentional downgrades shouldn't become an issue. <http://developer.apple.com/documentation/DeveloperTools/Conceptual/Dynam icLibraries/index.html> This also bears reading: <http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachO Topics/Articles/loading_code.html> > Small updates: > Id like to be able to produce updates for my apps. To keep the [quoted text clipped - 3 lines] > an appropriate message if not (eg if he tries to install an update > without already having installed the app itself) This is a very atypical experience for most Mac users, and likely to be fragile. Whatever costs you save in smaller bandwidth consumption may well be consumed by time you spend supporting people going through your update process. > Local Settings: > Sometimes Id like to be able to write setting to a directory outside > the app directory (eg when running my app from a network computer Id > like to be able to save user preferences locally). Forget about "I'd like to." You absolutely should. Assuming that your app will be able to write to it's parent directory (or any hard-coded location except /Users/Shared) is an error. User-level preferences belong in ~/Library/Preferences. > An uninstaller > would give my app a chance to clean up here (delete the settings > files). Not reliably. Even running as an admin user, you can't assume that your uninstaller will be able to get at user prefs. And since it's not reliable you can't reasonably tell the user you can do it. The appropriateness of trying to remove prefs during deinstallation is the subject of ongoing debate; prefs files are usually quite small and there's convenience to be had in reinstalling the app at a future date and not being required to go through configuration again. > Do these seem like valid reasons for shipping an app with an installer > on MacOsX, and if so would the installer that ships with XCode be > suitable/good for this? All other issues aside, the fact that you intend to share your own libraries among multiple applications is a pretty good reason, and the stock installer is certain up to that task. In my opinion the other reasons you give are non-issues. > There are still a couple of situations where Im not sure it wouldnt be > a good idea to use a "proper" installer though (rather tha let the [quoted text clipped - 8 lines] > overwritten with older versions or removed if another of my apps which > uses them is still installed. This kind of thing is more typically done as "first-run" setup by the app. When the app starts up it can check for these files, and copy them over if necessary. So the first time the app is run, the files are installed, but no separate installer is needed. Just be careful of file permissions when doing this-- not all user accounts will be able to write into /Library/, but everyone should have a ~/Library/. > Small updates: > Id like to be able to produce updates for my apps. To keep the [quoted text clipped - 3 lines] > an appropriate message if not (eg if he tries to install an update > without already having installed the app itself) A more common approach is some kind of "check for updates" option within the app itself. Again, you get the same functionality without requiring a separate tool to get the job done. > Local Settings: > Sometimes Id like to be able to write setting to a directory outside > the app directory (eg when running my app from a network computer Id > like to be able to save user preferences locally). An uninstaller > would give my app a chance to clean up here (delete the settings > files). In fact you _always_ want to write application settings outside of the app directory. It's considered extremely bad form for a Mac app to attempt to save settings in the same directory where the app lives, and in fact Apple provides APIs for locating and using more appropriate locations (e.g. the user defaults APIs for preferences, and NSSearchPathForDirectoriesInDomains() for most other things). If you're using enough disk space here that a cleanup routine seems appropriate, an uninstall option might be worthwhile. But as above, this is something you would be better off integrating into the application itself rather than building a standalone uninstaller. You could have a menu item, for example, that would uninstall everything and quit the application when done. SignatureTom "Tom" Harrington MondoMouse makes your mouse mightier See http://www.atomicbird.com/mondomouse/ > Thanks very much for all the helpful replies and comments. > [quoted text clipped - 13 lines] > overwritten with older versions or removed if another of my apps which > uses them is still installed. <pedantic>You should not care to what you want, but to what your users want</pedantic>. If the price of having only one copy of a shared library on the disk is the risk that common files are overwritten with older versions or removed, I would rather have you put multiple copies on my disk (unless, of course, your shared code is truly enormous in size) I am not saying that you do not need an installer, but if you want to develop an application that behaves as a good Mac citizen, you should know the trade-offs of your choices well. See <http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/ Tasks/InstallingFrameworks.html#//apple_ref/doc/uid/20002261-97286-BBCIHF EF> > Small updates: > Id like to be able to produce updates for my apps. To keep the [quoted text clipped - 3 lines] > an appropriate message if not (eg if he tries to install an update > without already having installed the app itself) IMO, you should either ship a new version or have your application manage its own upgrades. If an application updates itself, it will not have problems finding out where it is installed. If you ship an upgrade application, it must either search for the application, and that will be lengthy, or it will have to let the user point to the application, which is boring for the user. > Local Settings: > Sometimes Id like to be able to write setting to a directory outside > the app directory (eg when running my app from a network computer Id > like to be able to save user preferences locally). An uninstaller > would give my app a chance to clean up here (delete the settings > files). If you want your program to be popular, you _never_ want to write settings to the app directory. 1) users do not like it; settings belong in ~/Library/Preferences; see <http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConf ig/Articles/UserPreferences.html> 2) users may not be able to write there 3) different users may have different preferences Also, you should not require an unistaller for deleting preferences. 1) most of the time, keeping them around in case the user changes his mind is the right thing to do 2) if you put your preferences where they belong, users that care about it will know where to find and how to delete your preferences (you probably will find different opinions on this, but IMO anybody who cares about having a few kB of stale preferences files should also care about keeping an uninstaller around just in case (s)he wanted to uninstall things later) > Do these seem like valid reasons for shipping an app with an installer > on MacOsX, and if so would the installer that ships with XCode be > suitable/good for this? Some of them may be valid, depending on the details of the application, but I think you should do some more reading before you can make that choice. Reinder Thanks again for all the helpful answers and comments. >> P.S >> How much of a reduction on hardware would being an "ADC" member >> entitle one to, if one were to buy a new Mac? > > Officially, that information is covered by developer agreements as > non-disclosable. But it's not terribly hard to find via Google. That turns out not to be the case. You can browse the ADC discount store here: http://store.apple.com/AppleStore/WebObjects/ADC?qprm=38839 You just can't buy anything from it unless you're a member. However, this is only in the US; discounts overseas are similar but not readily available as far as I know. SignatureMichael Ash Rogue Amoeba Software Hello Michael > http://store.apple.com/AppleStore/WebObjects/ADC?qprm=38839 The link gave me "Sorry... Unable to enter the requested store." Presumably, your browser has stored some cookies or pasword for the page. > Hello Michael > [quoted text clipped - 4 lines] > Presumably, your browser has stored some cookies or pasword for the > page. Interesting, I'd guess it requires a specific referer. Anyway, you can get there from the link just under Ordering Information on this page: http://developer.apple.com/membership/usa.html SignatureMichael Ash Rogue Amoeba Software > As far as I can see all the (best?) current programming tools > (compiler, linker, make utility etc )for the job are included in > XCode, which ships with Os X, right? Yes, with one exception - I'll get to that. :-) > Are these the recommemded set of > tools for OS X programming? Are things like Code Warrior outdated now? CodeWarrior is dead. It's an ex-compiler, no longer living, pining for the fjords, null, kaput, done, it breathes no more. > Does XCode also come with a (decent) installer (that I can use to > deploy my app on a clients computer), or would I have to buy that > separately? If the latter, what would you recommend? Most often, what's recommended is not an installer at all, just a simple drag and drop. > In the installer > Id need to be able to detect the presence of a previous installation > (the app itself or some other app from me sharing the same files), and > where it was installed, and being able to call my app with certain > parameters before uninstall (allowing it to do any necessay clean > up). As I said, what would be most in line with the "Mac experience" would be for newer versions of your app to be able to clean up after older ones. That is, when your app starts up, it could check for outdated preferences or whatever, and if it finds them prompt the user "I found some old cruft, should I clean it up for you?" Having said that... Apple's standard installer can do that. You can hook into the installation process to run scripts at various times - "preflight", "postflight", etc. For creating installer packages, I prefer Iceberg over Apple's Package Maker. That's the one exception I mentioned above. To create a "metapackage" - i.e. an installer package with sub-packages - PM requires you to create the sub- packages as separate documents. Iceberg has a single coherent tree view of the top-level package and any sub-packages. <http://s.sudre.free.fr/Software/Iceberg.html> > How much of a reduction on hardware would being an "ADC" member > entitle one to, if one were to buy a new Mac? No idea. I'm too cheap to buy a paid membership *or* buy a new Mac. :-) sherm-- SignatureWeb Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net > Hello, > [quoted text clipped - 5 lines] > XCode, which ships with Os X, right? Are these the recommemded set of > tools for OS X programming? Are things like Code Warrior outdated now? AFAIK, CodeWarrior is PPC only - no Intel support. Xcode is built around the GNU tools (GCC etc). Intel also provide a paying compiler for the Mac (never used it). > Does XCode also come with a (decent) installer (that I can use to Haven't got that far yet myself. If you're using Qt, then qmake will generate a makefile that will build an app bundle. If you build a statically linked app, then that bundle is all that's required. Otherwise, you'll have to include the Qt dynamic libraries. A bientot Paul |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.