I am not able to validate the archive for my app due to a missing ubiquity entitlement to go along with the iCloudDocuments entitlement (see attached image).
I have configured the iCloud entitlements in the capabilities section in Xcode 6 in standard fashion as shown.
Things I've tried to solve this issue:
1. Deleting and recreating my distribution profile
2. Disabling/Enabling iCloud capability both in Xcode and in the member center
3. Using a custom ubiquity container instead of the default.
4. Disassociating/re-associating the different containers with my app.
5. Restarting Xcode
6. Cleaning the project
I solved this problem. This appears to be the result of a bug in Xcode. Here are the steps I took:
In my Target -> Capabilities tab I used a custom ubiquity container rather than the default. In my case, I simply used the container id that was the default but manually entered it as a custom container id.
Under the entitlements file I added the entitlement Ubiquity Container Identifiers and entered in my container id as item 0.
Under the entitlements file I manually entered in my ubiquity container id as item 0.
Related
Having the latest version 4.1.5 of ICXT for HCL Connections installed on WAS 8.5, I need to change some properties. The installation instructions said that we have a icxt-install.properties for installation, where we can set them. But it seems only possible during installation, not to change values which were already set.
How can I see what values are currently set and how to change them?
Backgrund
It's an ICXT installation without PDF export functionality, because this wasn't needed yet. But this has changed, so I want to enable it and develop some templates for our users. The selftest on https://cnxhost.internal/ic360/ui/selftest.html says
Is wkhtmltopdf installed? no
According to the documentation, I unpacked the binaries to ${CNX_SHARED_DIR}/icxt/pdfexport and restarted the WAS Appserver where ICXT is installed. But it's still not working. I assume that a predecessor admin or dev of mine changed this location, so I'd like to make sure that it points to my desired ${CNX_SHARED_DIR}/icxt/pdfexport path.
The script ${ICXT_INSTALL_DIR}/icxt-prepare.sh creates WebSphere Resource Entries. But just once during the installation. So we couldn't change the properties and re-run the script, as I assumed. To change it, open WebSpheres ISC web console and navigate through Resources > Resource Environment > Resource Environment entries
Now click in ic360
and Custom properties
Now you see a list of all the properties which were set by the installer. If some values were wrong (in my case wkhtmltopdf.command.exec), click on the entry and change the value field.
After conforming with OK and save, we need to restart the Appserver where ICXT is hosted in. If you don't know, look at the WebSphere enterprise applications, open any IC360 app and look in Manage Modules. In my case its CustomApps, which we can restart in Server > WebSphere Applicationserver.
Now reload the self test page and we see the wiki module check working fine:
I have an application which uses FFMPEG and FFPROBE to perform some tasks on a video the user can open with my application.
For non-sandboxed applications everything works fine, but when my app is running in a sandbox FFPROBE doesn't seem to get started.
The Console says the following:
08.06.15 12:27:55,803 secinitd[281]: ffprobe[4049]: registration request failed: (0x11, 0x0) Container object initialization failed.
failed to get bundleid for app "/Users/Alex/.../ffprobe"
The path to ffprobe mentioned in this messages points to the MacOS directory within the app bundle (a Build Phase copies these two binaries into the executable directory).
I've searched a lot and found some hints regarding entitlements. Of course my sandboxed app has its entitlements and when building my application it gets signed (with --deep signing flag). It even passes the technical App Store check for entitlements.
Now I'm stuck and wonder why my application is not able to launch FFPROBE (and FFMPEG).
Does anybody have a clue?
It seems like I've found a solution. I don't know whether all of these steps are necessary, but here is what I've tried and what seems (!) to work:
I added an entitlements file which contains true for the keys com.apple.security.inheritand com.apple.security.app-sandbox
I added a plist file for each used binary and filled the keys CFBundleName and CFBundleIdentifier with suitable values (I don't know whether this step is necessary)
I added a Run Script build phase which executes codesign -f -s "your certificate" --entitlements ./ffmpeg.entitlements ./Build/Intermediates/ArchiveIntermediates/App\ Store/InstallationBuildProductsLocation/Applications/<my app>/Contents/MacOS/ffmpeg
for each binary used.
These steps result in suitable entitlements when trying to submit the app to the Mac App Store and it results in a correct usage of the embedded binaries (at least on my development Mac and the Mac of some colleagues).
I'm trying to have my app auto launch on login following Tim's tutorial: http://blog.timschroeder.net/2012/07/03/the-launch-at-login-sandbox-project/
I followed the instructions to the letter but I'm getting an error when I re-login to my computer as follows:
Jan 10 12:55:01 pc61 com.apple.xpc.launchd[1] (com.myApp.macgap.helper[25725]): Could not resolve CFBundleIdentifier specified by service: -10814: com.myApp.macgap.helper
Jan 10 12:55:01 pc61 com.apple.xpc.launchd[1] (com.myApp.macgap.helper): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
To outline:
I have my main app called "myApp" (ID: com.myApp.macgap )
In that app I have a helper app with ID: com.myApp.macgap.helper
When you launch the main app and go to preferences, you have an option to enable auto login (to fit to the Apple compliance rules)
I log out of my computer, log back in and look at the console to see what's going on (that's how I get the code above)
Another point worth mentioning, is when I do "Show package content" on the app and double click the helper app, it does launch the main app...
It all comes down to how launchd and launchctl work, as already answered, the regular use case often can be solved by reinstalling the app and ensuring the app is inside the applications folder. But there's another case that #byb is talking about, when this happens on your development machine – this can be caused by invalid launchd configuration.
When you run SMLoginItemSetEnabled it registers your bundle identifier along with other information in launchd service. At some point later, when your app changes, gets cleaned, or something else happens to it, which gets picked up by launchd, launchd may disable that particular login item. Apparently, sometimes this doesn't go smoothly, and consecutive calls with SMLoginItemSetEnabled will not work as expected or the agent / helper app simply won't launch.
The first thing to try is simply changing the bundle identifier for your launcher. If this solves the issue, try figuring out what's wrong with the original. Run launchctl print-disabled "user/$(id -u)" to display disabled services and login item associations. If the output contains your troubling bundle identifier – you are in luck.
I didn't find a way of removing disabled services by name using launchctl and had to do it by manually editing configuration files. Because they system-owned, you won't be able to simply click and edit, instead launch Xcode as root and remove the necessary references.
sudo /Applications/Xcode.app/Contents/MacOS/Xcode "/private/var/db/com.apple.xpc.launchd/loginitems.$(id -u).plist"
sudo /Applications/Xcode.app/Contents/MacOS/Xcode "/private/var/db/com.apple.xpc.launchd/disabled.$(id -u).plist"
Restart, run launchctl print-disabled "user/$(id -u)" to confirm removed items are no longer in the list. Try SMLoginItemSetEnabled again, hopefully now it will work as expected.
I had the exact same problem just now, and while looking for a solution found this (unanswered) question.
At least in my case, this desired functionality of the worked fine when I copied the app (exported from Xcode as a dev-id signed .app) to a fresh OS X install/account without all my development stuff on it. Of course it must also be in /Applications, as stated in the tutorial referred to in the question.
I am not sure why this feature of the app did not work on my development machine. Perhaps the problem could be due to some form of conflict with all the other near-identical copies of my app I have on disk (I have an archive of different versions of the app, plus the copies Xcode stores itself), all with the same bundle id of course.
Hope this helps in one way or another!
I had the same problem, removing other copies of app except one in /Applications solved the problem for me. To remove .app files generated by Xcode you can run Product->Clean.
I was struggling with this for hours. I had many apps with auto login but a new one just did not want to work.
Strangely this worked on the development machine:
Build App as normal
Move it to Application directory
Clean Xcode (CMD+k)!!
Enable auto login in the app.
Logout Login
I accidentally noticed that the system started the app (it tries in every 10 sec) when I clean Xcode :)
I can't find the duplicate copy but did find you can remove the service:
In a terminal window:
launchctl remove com.annoying.service
As it was already stated if there are more then one copies of service bundle on the machine launchd cannot resolve which one must be started by bundle identifier.
What I would recommend to you is find all copies of your service and then remove not desired ones.
For this you need to run following Swift code (It works even in Swift Playground):
import Cocoa
let bundleId = "com.your.bundleId"
let paths = LSCopyApplicationURLsForBundleIdentifier(bundleId as CFString, nil)
print("Available service instances by bundle id: \(paths)")
In my case it produces:
Available service instances by bundle id:
Optional(Swift.Unmanaged<__ObjC.CFArray>(_value: <__NSArrayI 0x6000002234a0>(
file:///Applications/MyApp.app/Contents/Library/LoginItems/MyService.app/,
file:///Users/igor/Library/Developer/Xcode/Archives/2017-12-27/MyApp%2027-12-2017,%2016.06.xcarchive/Products/Applications/MyService.app/
)
))
So I easely identified copy to be removed:
file:///Users/igor/Library/Developer/Xcode/Archives/2017-12-27/MyApp%2027-12-2017,%2016.06.xcarchive/Products/Applications/MyService.app/
Hope it help.
Assuming that you followed Tim Schroeder's recipe at: http://blog.timschroeder.net/2012/07/03/the-launch-at-login-sandbox-project/ :
What actually ended up working for me, was, in Xcode, to change my main project's build number from 1 to 2. I also tried a build number of 1000 and that worked fine as well.
In Xcode, select your main project target. Then, select the 'General' tab. If you see your Build is set to 1, change it to 2 and then rebuild, redeploy and see if that resolves the issue for you.
This was probably one of the screwiest bugs I have run into, in a while.
I have been unable to overcome this error in Application Loader. I've quit, restarted, tried different computers - it's like the server is hung up on an op that I never initiated and it won't time out. Has anyone seen it before and beaten it?
Basically, you need to clear out the transport tokens. This can happen if you were to close out of Xcode while in the middle of submitting an app to iTunes Connect.
The token files now appear in the
Library/Caches/com.apple.amp.itmstransporter/UploadTokens/ subfolder of the given user's home directory. Which, honestly, is a better place for them anyway.
Delete any .token files in this directory.
--
If you are unable to find the .token files, this is because they are hidden in Finder. To hide/show hidden files in Finder, use the following Terminal command (TRUE = UNHIDE, FALSE = HIDE):
defaults write com.apple.finder AppleShowAllFiles TRUE;killall Finder
You need to clear out the transport tokens.
Open Terminal on your Mac, and paste:
rm /Users/<username>/Library/Caches/com.apple.amp.itmstransporter/UploadTokens/*.token
That should clear the stuck token. After this, try uploading the build again.
It might be because Xcode crashed as you were uploading your app. Either, all you need to do is delete the token files:
Open Terminal on your Mac, and paste:
rm ~/.itmstransporter/UploadTokens/*.token
That should clear it. If it still doesn't work (at this point you should try re-uploading your app), run that command on Terminal again, or manually go to...
/Users/<username>/.itmstransporter/UploadTokens/
...and delete all the .token files.
Hope that helps!
token was in here
/Users/(user_name)/Library/Caches/com.apple.amp.itmstransporter/UploadTokens/
Appreciated #WrightsCS 's answer It helps me to overcome Application Loader issue.
I would like to highlight one more thing here.
I proceed as per #WrightsCS answer and it resolved Application loader error:
Can not proceed with delivery: an existing transporter instance is currently uploading this package
But I found one more issue after removing all tokens from
/Users//.itmstransporter/UploadTokens/
I went to iTunesConnect and clicked on "My Apps", what I saw a message that "Can not connect... please contact Apple".
Here I don't know why it suddenly stops working!
I submitted the same build which was there on iTunesConnect for submission but it has shown as processing.
After submission of that build, iTunesConnect works fine! Also, I am able to see last uploaded build in a list for submission.
In my case (I am using OSX Catalina), I was not able to find the folder:
Library/Caches/com.apple.amp.itmstransporter/UploadTokens/
Under my user home directory (even when showing hidden files and folders)
but it seems my problem was a bit different and I just closed xCode completely (every xCode window opened) and reopened it again then I archived my project and uploaded it without any issues
maybe this could help someone else fix this issue
You need to clear out the upload tokens that are "stuck". To do this, open the tokens file found in /users//.itmstransporter/UploadTokens/. You should see one line of text at the top that refers to your current upload token. Simply delete this line and save the file. You should now be able to submit your app again.
Cheers
i am using trk for phone debug
it is working properly for Helloworld project
but it is showing error for my project when i start project in phone debug mode
1)Load failed
2)TrkProtocolPlugin:failed to download specified file to target
(please verify that target path is writable)
if any body understand what problem i am facing plz help me out from this problem
Thanks in advance
In your case, I would check:
if the application has correct privileges assigned (along with appropriate certificate)
if ID of the application is not in conflict with some other application on device
if installation package does not contain problematic commands (e.g. copy commands to non-accessible directories)
Can you manually install the application on the phone? That is the first test you must perform before even attempting to use TRK.
Also, can your application start, at least to the point of showing a panic? TRK cannot help you if the applications cannot even load its DLL dependencies due to for example Platform Security capability mismatch. TRK needs a process to attach too in order to do its job ...