Skip to main content

I am really confused on this one. I have deployed 5 apps from the Mac App store. All are free. I used composer snapshots to package all of them. But only 2 of them work properly. The other three fail to launch, instead bringing up the "sign in with your Apple ID" dialog. Since they are all free apps, and they were all packaged the same way, I can't figure out why this is happening. Can anyone shed some light on this issue?

Did you open the 3 that don't work prior to packaging them?



I read somewhere that if you do, then you'd need the account that opened them to authenticate. Or maybe it's the reverse. Sorry for being so vague.


Only first party Apple apps can be packaged. All third party apps, including free ones will have this issue regardless of how it is packaged, pushed, or opened/not opened prior to packaging.



I hope someone can prove me wrong on this though :-)


We download/package/push stuff from the Apple App Store all the time. You should only get prompted when it's time to update the apps. I could be wrong, if there are any App Store third party apps that do call in on first launch, but I'd think they're not following Apple guidelines?


Don,



Even with third party apps you're able to package/push without issue? Our big sticking point is AutoCAD LT.


Yep, all the drag-install style stuff, including Apple App Store applications from Apple or third parties.



We are packaging with PackageMaker (sorry JAMF but until you provide us with an easy way to add HW/SW checks...well...), we add logic to check HW/SW requirements (proceed if met, else exit), find/kill the process if it's running, then install and exit. Works like a charm. :)



Users get prompted if an update is released, if what you're pushing isn't the current version, users would get prompted. I can't guarantee every app would work, who knows what these third party vendors do, but we haven't had any problems...that is, unless we push an application that isn't current...



Don


I can confirm that 2 of the apps work fine, and they are 3rd party, and all the apps are current.


Dammit!!! I've been jinxed!!!



Lookie here...I recently upgraded to a rMBP and just today I saw the first instance of this issue:



external image link



I wonder if the developer(s) might have the option to do this kind of enforcement?



Don


Last week I tried using the same method that has always worked for Apple apps. I downloaded from the App Store, then dragged/dropped in Composer and deployed via Casper Remote for the 3rd party apps "7toX for Final Cut Pro" and "Xto7 for Final Cut Pro". Those two apps are prompting for the Apple ID and password on end user systems.



(When time permits, I'll try again on another device with a clean OS with the primary IT Apple ID to re-download the apps.)



This is to confirm that I am seeing this issue too!


We distribute directly from the App Store downloaded installer, which is a bit complicated. This may be vast overkill but we haven't had any trouble with it. Note that you can only redistribute apps from the App Store that don't check their receipt, which is most free apps.




  1. Start and pause the download immediately.


  2. With Terminal, find the temporary com.apple.appstore directory under /var/folders. Something like "find /var/folders -name com.apple.appstore 2>/dev/null" - if you're not root you'll get some permission errors here so redirect stderr to null.


  3. Under that you'll find a directory with some large number, and a few files inside that - flyingIcon, mzm.junk.pkg, preflight.pfpkg, and receipt. the mzm.junk.pkg is the actual app. Now if you resume downloading it will get deleted after installation, but if you make a hardlink to the file, the hardlink will stay around. For example, ln /var/folders/1v/6c9xr5zn6nz92c_vnj3jv17m0000gn/C/com.apple.appstore/12345678/mzm.exgoawfi.pkg ~/Desktop/


  4. Resume the download and let it finish.


  5. It would seem like you can use this linked mzm pkg directly, but it won't work. Instead, we expand it to get to the pkg inside, and then flatten that.




pkgutil --expand mzm.exgoawfi.pkg appstore.pkg
pkgutil --flatten appstore.pkg/whatever.pkg whatever.pkg




  1. You can now use the whatever.pkg with makepkginfo. We sometimes unpack the Payload file from inside the expanded pkg (e.g. appstore.pkg/whatever.pkg/Payload) using pax, and then feed that as -f's to makepkginfo.



Found this online in the macenterpise google group, could try to get your apps this way and deploy the package... been working for me


or



http://www.youtube.com/watch?v=mTgp642FB6c


Does anyone happen to have any new input on this issue? I just let it be for a while because it was starting to get under my skin, but I do need to figure it out eventually.


@nextyoyoma Doubtful you're going to be able to get around the issue where updates to the application will require the credentials for the Apple ID used when the application was downloaded from the Apple App Store.



PS, Snapshots is not the right method...



Don


Been hoping it would be possible to package free and paid apps. As soon as our users get 10.8+ they are going to want it working.



For now my excuse is "app system requirements is 10.74...sorry"



For 10.6.8 users that's enough to fob them off for now.



Apples commitment for the enterprise on this one needs to improve.



It IS possible to hack them, (see previous post) but that is completly against the license agreement.



This really is a pain in the arse, especially as we have management pushing for keynote and we have to source and buy iwork09 boxed copies off Amazon!


@tkimpton Yea I'm opposed to hacking the app (going into it and deleting anything). Following Apple guidelines and using Self Service, along with using PackageMaker to add the proper logic to the PKG is working fine for us on the Apple App Store side.



PS, I would LOVE to see Composer mature, so we can get logic menus (HW/SW check, etc.).



Don


@donmontalvo



Have yoy got any urls, guides to how you are doing them at the moment with package maker?



Don't get me wron, I'm sure Macenterprise method works, just my boss isn't going to be too chuffed when it comes to training colleagues that are... Erm... Not that familiar with terminal ;)


@tkimpton Check your email. :)


@rpotvin do you have the link? I can't see this on macenterprise


any clarity on step 6?



looking at this it doesn't make sense to me :(




  1. You can now use the whatever.pkg with makepkginfo. We sometimes unpack the Payload file from inside the expanded pkg (e.g. appstore.pkg/whatever.pkg/Payload) using pax, and then feed that as -f's to makepkginfo.


Old post, bring this up... @Don can you send me the mail you send to @tkimpton as well?



Thanks,
Maik


Any updates on how we push out apps without blasted apple id prompts. I dont quite get the macenterprise method


Anyone got any news on this?


If the third-party vendor is checking the _MASReceipt to make sure his/her app is not being pirated, your best/only approach is to contact the vendor for direct volume purchases of his/her app.



This is not an Apple problem.


And if its Apples Keynote?



Ive tried contacting them and reason with them to no avail.



Im interested in the approach highlighted on the macenterprise list, i just cant follow the instructions.


For Keynote, you need to be using the DVD version, or this: http://www.apple.com/mac/volume-licensing/



The discussion you are referring to was talking about ways of capturing the App Store installation package for use with Munki. If you ignore the Munki part, you might be able to do the same thing to capture the package for use with Casper. I'm not at all convinced this will fix your issue, however.


Thanks greg i will check it out :)


Reply