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
Related
My Mac app copies files the user drags in. The app is sandboxed. I've got a bug now, which I can reliably reproduce in Xcode, but which I can't track down the source of.
When I add a certain number of files, the app suddenly stops being able to access the later ones. All the source files come one level down from the same parent directory, and all of the folders in between have the same permissions, verified with ls -l. The app retains an app-scoped bookmark to Destination Directory, which is accessed before creating .directoryName and beginning the file copy.
I get the error:
Error Domain=NSCocoaErrorDomain Code=513 "“Filename.ext” couldn’t be copied because you don’t have permission to access “.directoryName”." UserInfo=0x6080000eaf80 {NSSourceFilePathErrorKey=/Users/Username/Parent Directory/Subdir/Filename.ext, NSUserStringVariant=(
Copy
), NSDestinationFilePath=/Users/Username/Desktop/Destination Directory/.directoryName/Filename.ext, NSFilePath=/Users/Username/Parent Directory/Subdir/Filename.ext, NSUnderlyingError=0x6080004567a0 "The operation couldn’t be completed. Operation not permitted"}
I have done the following while debugging:
Tried adding Subdir/Filename.ext on its own after quitting and relaunching, which worked
Verified (with lsof and Activity Monitor) that I'm not leaking file handles (which I know has caused similar problems for me in the past)
Verified with symbolic breakpoints that every call to -[NSURL startAccessingSecurityScopedResource] to is balanced with a call to -[NSURL stopAccessingSecurityScopedResource] (and their CF equivalents)
Determined that Filename.ext, and the other files that fail, succeed when added without the others
The same behavior occurs for Debug and Release builds, in and out of the debugger
I tried running as root, but my app won't run that way. When running in the debugger, I get an EXC_BAD_INSTRUCTION exception, and running it with sudo on the command line produces a crash (probably the same one)
The behavior seems to indicate some sort of resource leak, but it's not anything I've yet been able to detect. Any ideas what else might be causing this?
Update
I'm not ready to declare an answer, but I started to get these permission errors in a different part of my code, after a user has dropped files into the app. I noticed that a little ways up the logs, I'd see messages like the following:
Consume sandbox extension for itemIdentifier (1) from pasteboard failed!
Tracking down this error led me to a question someone else asked: Sandboxed Mac app exhausting security scoped URL resources
Unfortunately, the accepted answer says (paraphrasing) "tough noogies". It seems that Cocoa and the sandboxing mechanism themselves are leaking the security-scope tokens (though I can't verify with symbolic breakpoints and know of no other way to check). After a certain (unknown) number of file operations on sandboxed files, you'll start getting this error, and the only solution is to quit and relaunch.
I wish there was at least some way to prompt the user to relaunch when it gets close, but I'm not sure of any way to measure how many of these handles are in use. Or, even better, if I could manually clean up after I finish handling the dropped files, but I'm not sure how that would work, since I need to use the NSFilenamesPboardType pasteboard type to get multiple files' paths. I tried creating NSURLs from these and stopping security scope access, but that had no effect.
Update 2
I submitted a DTS ticket for this, as it's affecting users and there is no clear workaround. I'll update the question (and maybe give an answer?) as I find out more.
Response from Apple's DTS team
Apparently, this is a known issue, with no available workaround. I submitted a Radar: rdar://20652066, if you'd like to dupe it.
This was fixed in an El Capitan (10.11) release (possibly the first, but I'm not sure). When I built my app against the updated SDK, the behavior returned to normal.
My app is for the iPhone only .And it is working fine on all devices but when submitted the app it get rejected by apple by saying .......
On 1st time submission
We found your app crashed on launch so we were unable to review it.
Please revise your app and test it on a device to ensure it will launch without crashing, and that it runs as expected, before resubmitting.
this the crash report link please
this is the crash report
crash report
on second submission it get rejected they says
Thank you for your resubmission. However, we were still unable to review your app, as it crashed on launch. We have attached detailed crash logs to help troubleshoot this issue.
Specifically, upon review we found the application will shortly crash after launch.
they send crash report
on second time submission
on second time submission
I didn't get where i am doing wrong ,please check this ,Thanks in advance
I also try Bhavin step to find the crash location but terminal show's me like that
I found the solution. We can just directly drag and drop the crash-report on the device log.
Then it will convert the crash report into readable format.
STEPS:
Attach your device to mac.
Open Xcode
Goto window from menu bar
Click on devices like this
Now, drag and drop your crash report you received from apple. It will symbolicate it and show you in readable format. If the file extension is .txt, change it to ".crash".
Follow these steps :
Get the .ipa file that you submitted to the app store.
Rename the extention .ipa with .zip , extract it. You'll get a Payload Folder which contains .app file.
Create a folder with this .app file and crash log file.
Now, open terminal application and go to the folder created in above step (using cd command).
Run this magic line :
atos -arch armv7 -o YourAppName.app/YourAppName MEMORY_LOCATION_OF_CRASH
Where, MEMORY_LOCATION_OF_CRASH = location where your app crashed as
per the report.
It'll give you the exact line, method name which resulted in crash.
If you test your app and it works fine but Apple keeps rejecting it then you need to test it on release mode not debug mode as follows:
Edit scheme > Run > Build configuration > release
Hope this helps someone because I came across this issue and it took me too long to sort it out!
I am using gulp with livereload, less, and others on a remote server. I have successfully used gulp before many times, and have never experienced this scenario.
I am using WinSCP to save/edit files (I double click the file, and it opens in Sublime Text ... I save it, WinSCP automatically uploads it back to the server ).
However, when doing it this way gulp-less fails almost all the time. I have two core CSS files that are compiled - one is Bootstrap and one is my own - they should both be compiled with their own gulp tasks upon modification - but Bootstrap fails every time, and the other file fails about half of the time.
When I say fails, here's what I mean - with Bootstrap I always get the same error:
variable #grid-columns is undefined in file ....grid.less line no. 48
This happens even if I define #grid-columns as the first-heading in my main Bootstrap "import" file.
The other one fails in that livereload reloads the compiled CSS at some point prior to the Less file being compiled. This should be impossible, but it happens somehow.
However, when from the SSH command prompt, I type touch myfile.less or touch anybootstrapfile.less, everything works perfectly.
Obviously this is very annoying, but its livable. I think there must be some way to fix it though. Any ideas on what in the world could make this happen and what (if anything) I could do to fix it?
Chances are that, when WinSCP uploads the file after you save it in the internal editor, it sets a timestamp of uploaded file to older than it was before.
This might be particularly true, if you are using the FTP protocol, or Windows Vista or older.
For details, refer to WinSCP FAQ:
Why are the changes, I upload to webserver, not visible in the web browser?
Alright. With the help of Martin, who I now realize is the developer of WinScp, I have solved this. I had been working with the gulp.wait plugin and inserting a pause before the final reload - and it wasn't working.
Because... that wasn't where the problem was. The problem was happening at the time of upload; in that the file was getting 'touched' to soon (or there was something with the timestamp that ended up causing the functional equivelant).
So I moved the wait process to just before the less process was called like so:
gulp.src(src)
.pipe(plumber({
errorHandler:onError
})
.pipe(wait(500))
.pipe(less())
//etc
I'm gonna experiment, 500ms is probably longer than needed..but not too long to be painful. This solved the problem instantly.
Thanks Martin!
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'm writing app like System Activity in Mac. I used modified darwin.h and darwin.c from this topic.
But it seems that it shows correct info only for certain fields (and some time ago it showed all correct info but only for current process - this app), for everything else it shows correct only pid, process name, group/owner. Everything else like cpu/mem/disk usage is nulled. I think it may be something with sandbox or security. Tried to move application to /Applications and setting root/wheel 755 but it's not work, still zeroed values.
Here's my output : click
Code changed in darwin.c : click, written after a lot of commented printf lines
Also there is a free apps approved in AppStore like SystemInfo (com.lymbilesoft.systeminfoliteforiphone) that shows detailed info about disk and processes, so how do it work? Tried nm-ing it's binary but did not find something useful.
Can someone please help me with it?
I'm not sure if this is the only problem, but it certainly is possible that your app needs to run as root for this to work correctly.
However, simply installing the app in /Applications, doing chown root.wheel, and chmod 755 will not cause it to run as root. It will still run as user mobile.
In order to get the app to run as root, see this answer
I've used this technique successfully, and if you have a jailbroken phone, you can navigate to /Applications/Cydia.app and see that this launch script is how Cydia does this, too.
I use ps aux from the Terminal/Command Line. That gives me all the stuff I need, regarding your concerns.